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