1$NetBSD: storage,v 1.30 2025/05/19 18:02:53 nia Exp $ 2 3NetBSD Storage Roadmap 4====================== 5 6This is a small roadmap document, and deals with the storage and file 7systems side of the operating system. It discusses elements, projects, 8and goals that are under development or under discussion; and it is 9divided into three categories based on perceived priority. 10 11The following elements, projects, and goals are considered strategic 12priorities for the project: 13 14 1. Improving iscsi 15 2. nfsv4 support 16 3. A better journaling file system solution 17 4. Stabilizing and improving zfs support 18 5. Seamless full-disk encryption 19 6. Finish tls-maxphys 20 21The following elements, projects, and goals are not strategic 22priorities but are still important undertakings worth doing: 23 24 7. lfs64 25 8. Per-process namespaces 26 9. lvm tidyup 27 10. Flash translation layer 28 11. Shingled disk support 29 12. ext3/ext4 support 30 13. Port hammer from Dragonfly 31 14. afs maintenance 32 15. execute-in-place 33 16. extended attributes for acl and capability storage 34 35The following elements, projects, and goals are perhaps less pressing; 36this doesn't mean one shouldn't work on them but the expected payoff 37is perhaps less than for other things: 38 39 17. coda maintenance 40 41 42Explanations 43============ 44 451. Improving iscsi 46------------------ 47 48Both the existing iscsi target and initiator are fairly bad code, and 49neither works terribly well. Fixing this is fairly important as iscsi 50is where it's at for remote block devices. Note that there appears to 51be no compelling reason to move the target to the kernel or otherwise 52make major architectural changes. 53 54 - As of January 2017 nobody is known to be working on this. 55 - There is currently no clear timeframe or release target. 56 - Contact agc for further information. 57 58 592. nfsv4 support 60---------------- 61 62nfsv4 is at this point the de facto standard for FS-level (as opposed 63to block-level) network volumes in production settings. The legacy nfs 64code currently in NetBSD only supports nfsv2 and nfsv3. 65 66The intended plan is to port FreeBSD's nfsv4 code, which also includes 67nfsv2 and nfsv3 support, and eventually transition to it completely, 68dropping our current nfs code. (Which is kind of a mess.) So far the 69only step that has been taken is to import the code from FreeBSD. The 70next step is to update that import (since it was done a while ago now) 71and then work on getting it to configure and compile. 72 73 - As of January 2017 pgoyette has done a bit of prodding of the code 74 recently, but otherwise nobody is working on this, and a volunteer to 75 take charge and move it forward rapidly is urgently needed. 76 - There is no clear timeframe or release target, although having an 77 experimental version ready for -8 would be great. 78 - Contact dholland for further information. 79 80 813. A better journaling file system solution 82------------------------------------------- 83 84WAPBL, the journaling FFS that NetBSD rolled out some time back, has a 85critical problem: it does not address the historic ffs behavior of 86allowing stale on-disk data to leak into user files in crashes. And 87because it runs faster, this happens more often and with more data. 88This situation is both a correctness and a security liability. Fixing 89it has turned out to be difficult. It is not really clear what the 90best option at this point is: 91 92+ Fixing WAPBL (e.g. to flush newly allocated/newly written blocks to 93disk early) has been examined by several people who know the code base 94and judged difficult. Also, some other problems have come to light 95more recently; e.g. PR 50725, and 45676. Still, it might be the best 96way forward. Some performance and stability issues were resolved 97in netbsd-8, and more work is planned. 98 99+ There is another journaling FFS; the Harvard one done by Margo 100Seltzer's group some years back. We have a copy of this, but as it was 101written in BSD/OS circa 1999 it needs a lot of merging, and then will 102undoubtedly also need a certain amount of polishing to be ready for 103production use. It does record-based rather than block-based 104journaling and does not share the stale data problem. 105 106+ We could bring back softupdates (in the softupdates-with-journaling 107form found today in FreeBSD) -- this code is even more complicated 108than the softupdates code we removed back in 2009, and it's not clear 109that it's any more robust either. However, it would solve the stale 110data problem if someone wanted to port it over. It isn't clear that 111this would be any less work than getting the Harvard journaling FFS 112running... or than writing a whole new file system either. 113 114+ We could write a whole new journaling file system. (That is, not 115FFS. Doing a new journaling FFS implementation is probably not 116sensible relative to merging the Harvard journaling FFS.) This is a 117big project. 118 119Right now it is not clear which of these avenues is the best way 120forward. Given the general manpower shortage, it may be that the best 121way is whatever looks best to someone who wants to work on the 122problem. 123 124 - There is no clear timeframe or release target; but given that WAPBL 125 has been disabled by default for new installs in -7 this problem 126 can reasonably be said to have become critical. 127 - jdolecek fixed some WAPBL stability issues, that work is included 128 in netbsd-8, could be possibly enough for making it default for new 129 installs again; there is kern/47030 which seems to be triggered by WAPBL 130 however 131 - There has been some interest in the Harvard journaling FFS but no 132 significant progress. Nobody is known to be working on or particularly 133 interested in porting softupdates-with-journaling. And, while 134 dholland has been mumbling for some time about a plan for a 135 specific new file system to solve this problem, there isn't any 136 realistic prospect of significant progress on that in the 137 foreseeable future, and nobody else is known to have or be working 138 on even that much. 139 - Contact joerg, martin, or jdolecek regarding WAPBL; contact dholland 140 regarding the Harvard journaling FFS. 141 142 1435. Seamless full-disk encryption 144-------------------------------- 145 146(This is only sort of a storage issue.) We have cgd, and it is 147believed to still be cryptographically suitable, at least for the time 148being. However, we don't have any of the following things: 149 150+ An easy way to install a machine with full-disk encryption. It 151should really just be a checkbox item in sysinst, or not much more 152than that. 153 154+ Ideally, also an easy way to turn on full-disk encryption for a 155machine that's already been installed, though this is harder. 156 157+ A good story for booting off a disk that is otherwise encrypted; 158obviously one cannot encrypt the bootblocks, but it isn't clear where 159in boot the encrypted volume should take over, or how to make a best 160effort at protecting the unencrypted elements needed to boot. (At 161least, in the absence of something like UEFI secure boot combined with 162a cryptographic oracle to sign your bootloader image so UEFI will 163accept it.) There's also the question of how one runs cgdconfig(8) and 164where the cgdconfig binary comes from. 165 166+ A reasonable way to handle volume passphrases. MacOS apparently uses 167login passwords for this (or as passphrases for secondary keys, or 168something) and this seems to work well enough apart from the somewhat 169surreal experience of sometimes having to log in twice. However, it 170will complicate the bootup story. 171 172Given the increasing regulatory-level importance of full-disk 173encryption, this is at least a de facto requirement for using NetBSD 174on laptops in many circumstances. 175 176 - As of January 2017 nobody is known to be working on this. 177 - There is no clear timeframe or release target. 178 - Contact dholland for further information. 179 180 1816. Finish tls-maxphys 182--------------------- 183 184The tls-maxphys branch changes MAXPHYS (the maximum size of a single 185I/O request) from a global fixed constant to a value that's probed 186separately for each particular I/O channel based on its 187capabilities. Large values are highly desirable for e.g. feeding large 188disk arrays and SSDs, but do not work with all hardware. 189 190The code is nearly done and just needs more testing and support in 191more drivers. 192 193 - On October 2017 jdolecek re-synced the branch, intention is to wrap 194 this up for future netbsd-9 195 - Contact jdolecek or tls for further information. 196 197 1987. lfs64 199-------- 200 201LFS currently only supports volumes up to 2 TB. As LFS is of interest 202for use on shingled disks (which are larger than 2 TB) and also for 203use on disk arrays (ditto) this is something of a problem. A 64-bit 204version of LFS for large volumes is in the works. 205 206 - dholland was working on this in fall 2015 but time to finish it 207 dried up. 208 - The goal now is to get a few remaining things done in time for 8.0 209 so it will at least be ready for experimental use there. 210 - Responsible: dholland 211 212 2138. Per-process namespaces 214------------------------- 215 216Support for per-process variation of the file system namespace enables 217a number of things; more flexible chroots, for example, and also 218potentially more efficient pkgsrc builds. dholland thought up a 219somewhat hackish but low-footprint way to implement this, and has a 220preliminary implementation, but concluded the scheme was too fragile 221for production. A different approach is probably needed, although the 222existing code could be tidied up and committed if that seems desirable. 223 224 - As of January 2017 nobody is working on this. 225 - Contact: dholland 226 227 2289. lvm tidyup 229-------------- 230 231[agc says someone should look at our lvm stuff; XXX fill this in] 232 233 - As of January 2017 nobody is known to be working on this. 234 - There is no clear timeframe or release target. 235 - Contact agc for further information. 236 237 23810. Flash translation layer 239--------------------------- 240 241SSDs ship with firmware called a "flash translation layer" that 242arbitrates between the block device software expects to see and the 243raw flash chips. FTLs handle wear leveling, lifetime management, and 244also internal caching, striping, and other performance concerns. While 245NetBSD has a file system for raw flash (chfs), it seems that given 246things NetBSD is often used for it ought to come with a flash 247translation layer as well. 248 249Note that this is an area where writing your own is probably a bad 250plan; it is a complicated area with a lot of prior art that's also 251reportedly full of patent mines. There are a couple of open FTL 252implementations that we might be able to import. 253 254 - As of January 2017 nobody is known to be working on this. 255 - There is no clear timeframe or release target. 256 - Contact dholland for further information. 257 258 25911. Shingled disk support 260------------------------- 261 262Shingled disks (or more technically, disks with "shingled magnetic 263recording" or SMR) can only write whole tracks at once. Thus, to 264operate effectively they require translation support similar to the 265flash translation layers found in SSDs. The nature and structure of 266shingle translation layers is still being researched; however, at some 267point we will want to support these things in NetBSD. 268 269 - As of 2016 one of dholland's coworkers was looking at this. 270 - There is no clear timeframe or release target. 271 - Contact dholland for further information. 272 273 27412. ext3/ext4 support 275--------------------- 276 277Currently people are mostly using the kernel implementation of 278ext2 or using filesystems/fuse-ext2 from pkgsrc for later versions. 279 280We would like to be able to read and write Linux ext3fs and ext4fs 281volumes. (We can already read clean ext3fs volumes as they're the same 282as ext2fs, modulo volume features our ext2fs code does not support; 283but we can't write them.) 284 285Ideally someone would write ext3 and/or ext4 code, whether integrated 286with or separate from the ext2 code we already have. It might also 287make sense to port or wrap the Linux ext3 or ext4 code so it can be 288loaded as a GPL'd kernel module; it isn't clear if that would be more 289or less work than doing an implementation. 290 291Note however that implementing ext3 has already defeated several 292people; this is a harder project than it looks. 293 294 - GSoc 2016 brought support for extents, and also ro support for dir 295 hashes; jdolecek also implemented several frequently used ext4 features 296 so most contemporary ext filesystems should be possible to mount 297 read-write 298 - still need rw dir_nhash and xattr (semi-easy), and eventually journaling 299 (hard) 300 - There is no clear timeframe or release target. 301 - jdolecek is working on improving ext3/ext4 support (particularly 302 journaling) 303 304 30513. Port hammer from Dragonfly 306------------------------------ 307 308While the motivation for and role of hammer isn't perhaps super 309persuasive, it would still be good to have it. Porting it from 310Dragonfly is probably not that painful (compared to, say, zfs) but as 311the Dragonfly and NetBSD VFS layers have diverged in different 312directions from the original 4.4BSD, may not be entirely trivial 313either. 314 315 - As of January 2017 nobody is known to be working on this. 316 - There is no clear timeframe or release target. 317 - There probably isn't any particular person to contact; for VFS 318 concerns contact dholland or hannken. 319 320 32114. afs maintenance 322------------------- 323 324AFS needs periodic care and feeding to continue working as NetBSD 325changes, because the kernel-level bits aren't kept in the NetBSD tree 326and don't get updated with other things. This is an ongoing issue that 327always seems to need more manpower than it gets. It might make sense 328to import some of the kernel AFS code, or maybe even just some of the 329glue layer that it uses, in order to keep it more current. 330 331 - jakllsch sometimes works on this. 332 - We would like every release to have working AFS by the time it's 333 released. 334 - Contact jakllsch or gendalia about AFS; for VFS concerns contact 335 dholland or hannken. 336 337 33815. execute-in-place 339-------------------- 340 341It is likely that the future includes non-volatile storage (so-called 342"nvram") that looks like RAM from the perspective of software. Most 343importantly: the storage is memory-mapped rather than looking like a 344disk controller. There are a number of things NetBSD ought to have to 345be ready for this, of which probably the most important is 346"execute-in-place": when an executable is run from such storage, and 347mapped into user memory with mmap, the storage hardware pages should 348be able to appear directly in user memory. Right now they get 349gratuitously copied into RAM, which is slow and wasteful. There are 350also other reasons (e.g. embedded device ROMs) to want execute-in- 351place support. 352 353Note that at the implementation level this is a UVM issue rather than 354strictly a storage issue. 355 356Also note that one does not need access to nvram hardware to work on 357this issue; given the performance profiles touted for nvram 358technologies, a plain RAM disk like md(4) is sufficient both 359structurally and for performance analysis. 360 361 - As of January 2017 nobody is known to be working on this. Some 362 time back, uebayasi wrote some preliminary patches, but they were 363 rejected by the UVM maintainers. 364 - There is no clear timeframe or release target. 365 - Contact dholland for further information. 366 367 36816. use extended attributes for ACL and capability storage 369---------------------------------------------------------- 370 371Currently there is some support for extended attributes in ffs, 372but nothing really uses it. I would be nice if we came up with 373a standard format to store ACL's and capabilities like Linux has. 374The various tools must be modified to understand this and be able 375to copy them if requested. Also tools to manipulate the data will 376need to be written. 377 378 37917. coda maintenance 380-------------------- 381 382Coda only sort of works. [And I think it's behind relative to 383upstream, or something of the sort; XXX fill this in.] Also the code 384appears to have an ugly incestuous relationship with FFS. This should 385really be cleaned up. That or maybe it's time to remove Coda. 386 387 - As of January 2017 nobody is known to be working on this. 388 - There is no clear timeframe or release target. 389 - There isn't anyone in particular to contact. 390 - Circa 2012 christos made it work read-write and split it 391 into modules. Since then christos has not tested it. 392 393 394Alistair Crooks, David Holland 395Fri Nov 20 02:17:53 EST 2015 396Sun May 1 16:50:42 EDT 2016 (some updates) 397Fri Jan 13 00:40:50 EST 2017 (some more updates) 398 399