head 1.30; access; symbols netbsd-11-0-RC5:1.30 netbsd-11-0-RC4:1.30 netbsd-11-0-RC3:1.30 netbsd-11-0-RC2:1.30 netbsd-11-0-RC1:1.30 perseant-exfatfs-base-20250801:1.30 netbsd-11:1.30.0.2 netbsd-11-base:1.30 netbsd-10-1-RELEASE:1.28 perseant-exfatfs-base-20240630:1.28 perseant-exfatfs:1.28.0.4 perseant-exfatfs-base:1.28 netbsd-8-3-RELEASE:1.22 netbsd-9-4-RELEASE:1.27 netbsd-10-0-RELEASE:1.28 netbsd-10-0-RC6:1.28 netbsd-10-0-RC5:1.28 netbsd-10-0-RC4:1.28 netbsd-10-0-RC3:1.28 netbsd-10-0-RC2:1.28 netbsd-10-0-RC1:1.28 netbsd-10:1.28.0.2 netbsd-10-base:1.28 netbsd-9-3-RELEASE:1.27 cjep_sun2x-base1:1.27 cjep_sun2x:1.27.0.8 cjep_sun2x-base:1.27 cjep_staticlib_x-base1:1.27 netbsd-9-2-RELEASE:1.27 cjep_staticlib_x:1.27.0.6 cjep_staticlib_x-base:1.27 netbsd-9-1-RELEASE:1.27 phil-wifi-20200421:1.27 phil-wifi-20200411:1.27 is-mlppp:1.27.0.4 is-mlppp-base:1.27 phil-wifi-20200406:1.27 netbsd-8-2-RELEASE:1.22 netbsd-9-0-RELEASE:1.27 netbsd-9-0-RC2:1.27 netbsd-9-0-RC1:1.27 phil-wifi-20191119:1.27 netbsd-9:1.27.0.2 netbsd-9-base:1.27 phil-wifi-20190609:1.27 netbsd-8-1-RELEASE:1.22 netbsd-8-1-RC1:1.22 pgoyette-compat-merge-20190127:1.23.2.1 pgoyette-compat-20190127:1.26 pgoyette-compat-20190118:1.26 pgoyette-compat-1226:1.26 pgoyette-compat-1126:1.26 pgoyette-compat-1020:1.26 pgoyette-compat-0930:1.26 pgoyette-compat-0906:1.26 netbsd-7-2-RELEASE:1.9 pgoyette-compat-0728:1.26 netbsd-8-0-RELEASE:1.22 phil-wifi:1.26.0.2 phil-wifi-base:1.26 pgoyette-compat-0625:1.26 netbsd-8-0-RC2:1.22 pgoyette-compat-0521:1.26 pgoyette-compat-0502:1.26 pgoyette-compat-0422:1.26 netbsd-8-0-RC1:1.22 pgoyette-compat-0415:1.26 pgoyette-compat-0407:1.23 pgoyette-compat-0330:1.23 pgoyette-compat-0322:1.23 pgoyette-compat-0315:1.23 netbsd-7-1-2-RELEASE:1.9 pgoyette-compat:1.23.0.2 pgoyette-compat-base:1.23 netbsd-7-1-1-RELEASE:1.9 matt-nb8-mediatek:1.22.0.6 matt-nb8-mediatek-base:1.22 netbsd-8:1.22.0.4 netbsd-8-base:1.22 prg-localcount2-base3:1.22 prg-localcount2-base2:1.22 prg-localcount2-base1:1.22 prg-localcount2:1.22.0.2 prg-localcount2-base:1.22 pgoyette-localcount-20170426:1.22 bouyer-socketcan-base1:1.22 pgoyette-localcount-20170320:1.21 netbsd-7-1:1.9.0.26 netbsd-7-1-RELEASE:1.9 netbsd-7-1-RC2:1.9 netbsd-7-nhusb-base-20170116:1.9 bouyer-socketcan:1.21.0.2 bouyer-socketcan-base:1.21 pgoyette-localcount-20170107:1.20 netbsd-7-1-RC1:1.9 pgoyette-localcount-20161104:1.19 netbsd-7-0-2-RELEASE:1.9 localcount-20160914:1.15 netbsd-7-nhusb:1.9.0.24 netbsd-7-nhusb-base:1.9 pgoyette-localcount-20160806:1.15 pgoyette-localcount-20160726:1.15 pgoyette-localcount:1.15.0.2 pgoyette-localcount-base:1.15 netbsd-7-0-1-RELEASE:1.9 netbsd-7-0:1.9.0.22 netbsd-7-0-RELEASE:1.9 netbsd-7-0-RC3:1.9 netbsd-7-0-RC2:1.9 netbsd-7-0-RC1:1.9 netbsd-5-2-3-RELEASE:1.2.2.2 netbsd-5-1-5-RELEASE:1.2.2.2 netbsd-6-0-6-RELEASE:1.9 netbsd-6-1-5-RELEASE:1.9 netbsd-7:1.9.0.20 netbsd-7-base:1.9 yamt-pagecache-base9:1.9 yamt-pagecache-tag8:1.8.6.1 netbsd-6-1-4-RELEASE:1.9 netbsd-6-0-5-RELEASE:1.9 tls-earlyentropy:1.9.0.18 tls-earlyentropy-base:1.9 riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.9 riastradh-drm2-base3:1.9 netbsd-6-1-3-RELEASE:1.9 netbsd-6-0-4-RELEASE:1.9 netbsd-5-2-2-RELEASE:1.2.2.2 netbsd-5-1-4-RELEASE:1.2.2.2 netbsd-6-1-2-RELEASE:1.9 netbsd-6-0-3-RELEASE:1.9 netbsd-5-2-1-RELEASE:1.2.2.2 netbsd-5-1-3-RELEASE:1.2.2.2 netbsd-6-1-1-RELEASE:1.9 riastradh-drm2-base2:1.9 riastradh-drm2-base1:1.9 riastradh-drm2:1.9.0.10 riastradh-drm2-base:1.9 netbsd-6-1:1.9.0.16 netbsd-6-0-2-RELEASE:1.9 netbsd-6-1-RELEASE:1.9 khorben-n900:1.9.0.14 netbsd-6-1-RC4:1.9 netbsd-6-1-RC3:1.9 agc-symver:1.9.0.12 agc-symver-base:1.9 netbsd-6-1-RC2:1.9 netbsd-6-1-RC1:1.9 yamt-pagecache-base8:1.9 netbsd-5-2:1.2.2.2.0.10 netbsd-6-0-1-RELEASE:1.9 yamt-pagecache-base7:1.9 netbsd-5-2-RELEASE:1.2.2.2 netbsd-5-2-RC1:1.2.2.2 matt-nb6-plus-nbase:1.9 yamt-pagecache-base6:1.9 netbsd-6-0:1.9.0.8 netbsd-6-0-RELEASE:1.9 netbsd-6-0-RC2:1.9 tls-maxphys:1.9.0.6 tls-maxphys-base:1.9 matt-nb6-plus:1.9.0.4 matt-nb6-plus-base:1.9 netbsd-6-0-RC1:1.9 yamt-pagecache-base5:1.9 yamt-pagecache-base4:1.9 netbsd-6:1.9.0.2 netbsd-6-base:1.9 netbsd-5-1-2-RELEASE:1.2.2.2 netbsd-5-1-1-RELEASE:1.2.2.2 yamt-pagecache-base3:1.8 yamt-pagecache-base2:1.8 yamt-pagecache:1.8.0.6 yamt-pagecache-base:1.8 cherry-xenmp:1.8.0.4 cherry-xenmp-base:1.8 bouyer-quota2-nbase:1.8 bouyer-quota2:1.8.0.2 bouyer-quota2-base:1.8 matt-mips64-premerge-20101231:1.8 matt-nb5-mips64-premerge-20101231:1.2.2.2 matt-nb5-pq3:1.2.2.2.0.8 matt-nb5-pq3-base:1.2.2.2 netbsd-5-1:1.2.2.2.0.6 netbsd-5-1-RELEASE:1.2.2.2 netbsd-5-1-RC4:1.2.2.2 matt-nb5-mips64-k15:1.2.2.2 netbsd-5-1-RC3:1.2.2.2 netbsd-5-1-RC2:1.2.2.2 netbsd-5-1-RC1:1.2.2.2 netbsd-5-0-2-RELEASE:1.2.2.2 matt-nb5-mips64-premerge-20091211:1.2.2.2 matt-premerge-20091211:1.8 matt-nb5-mips64-u2-k2-k4-k7-k8-k9:1.2.2.2 matt-nb4-mips64-k7-u2a-k9b:1.2.2.2 matt-nb5-mips64-u1-k1-k5:1.2.2.2 matt-nb5-mips64:1.2.2.2.0.4 netbsd-5-0-1-RELEASE:1.2.2.2 jym-xensuspend-nbase:1.4 netbsd-5-0:1.2.2.2.0.2 netbsd-5-0-RELEASE:1.2.2.2 netbsd-5-0-RC4:1.2.2.2 netbsd-5-0-RC3:1.2.2.2 netbsd-5-0-RC2:1.2.2.2 jym-xensuspend:1.4.0.2 jym-xensuspend-base:1.4 netbsd-5-0-RC1:1.2.2.2 netbsd-5:1.2.0.2 netbsd-5-base:1.2 matt-mips64-base2:1.2 wrstuden-revivesa-base-3:1.2 wrstuden-revivesa-base-2:1.2 wrstuden-revivesa-base-1:1.1 yamt-pf42-base4:1.1 yamt-pf42-base3:1.1 hpcarm-cleanup-nbase:1.1 yamt-pf42-baseX:1.1 yamt-pf42-base2:1.1 wrstuden-revivesa:1.1.0.10 wrstuden-revivesa-base:1.1 mjf-devfs2:1.1.0.8 mjf-devfs2-base:1.2 yamt-pf42:1.1.0.6 yamt-pf42-base:1.1 keiichi-mipv6-base:1.1 keiichi-mipv6:1.1.0.4 matt-armv6:1.1.0.2 matt-armv6-nbase:1.1; locks; strict; comment @# @; 1.30 date 2025.05.19.18.02.53; author nia; state Exp; branches; next 1.29; commitid KKoQigwL34GNNxVF; 1.29 date 2024.09.08.09.36.45; author rillig; state Exp; branches; next 1.28; commitid rdsoFf00hj9B9ZoF; 1.28 date 2021.10.21.13.21.53; author andvar; state Exp; branches 1.28.4.1; next 1.27; commitid hSvXH6jxEwLUeGdD; 1.27 date 2019.05.29.02.34.19; author msaitoh; state Exp; branches; next 1.26; commitid qfvSqNnJByqZO2pB; 1.26 date 2018.04.12.19.12.25; author jdolecek; state Exp; branches 1.26.2.1; next 1.25; commitid Hbyl0KtBlqFvAbyA; 1.25 date 2018.04.12.19.11.35; author jdolecek; state Exp; branches; next 1.24; commitid 9pnN13gnG4g5AbyA; 1.24 date 2018.04.12.19.08.02; author jdolecek; state Exp; branches; next 1.23; commitid ygGKvDVMpsGOybyA; 1.23 date 2017.10.31.19.03.32; author jdolecek; state Exp; branches 1.23.2.1; next 1.22; commitid lMG9utGVbekaLedA; 1.22 date 2017.04.19.21.48.58; author jdolecek; state Exp; branches; next 1.21; commitid ven6NRVldBZFXbOz; 1.21 date 2017.01.13.10.14.58; author dholland; state Exp; branches 1.21.2.1; next 1.20; commitid FFkVbzaBlcoIbNBz; 1.20 date 2016.11.10.21.28.15; author jdolecek; state Exp; branches; next 1.19; commitid B3nE3eYx7BddZCtz; 1.19 date 2016.10.28.20.30.37; author jdolecek; state Exp; branches; next 1.18; commitid no4445AfHChs5Xrz; 1.18 date 2016.09.21.20.32.47; author jdolecek; state Exp; branches; next 1.17; commitid zLt21Jh2R5O1icnz; 1.17 date 2016.09.16.15.02.23; author jdolecek; state Exp; branches; next 1.16; commitid uJfbl8OjT1DECwmz; 1.16 date 2016.09.16.14.55.28; author jdolecek; state Exp; branches; next 1.15; commitid 3OAv2odCmhs7Awmz; 1.15 date 2016.05.17.21.03.36; author christos; state Exp; branches 1.15.2.1; next 1.14; commitid nm4vKJOldBoIxS6z; 1.14 date 2016.05.14.21.32.50; author mlelstv; state Exp; branches; next 1.13; commitid xoUZJTXSpxmCNu6z; 1.13 date 2016.05.05.06.17.45; author dholland; state Exp; branches; next 1.12; commitid f9YYVeXhA39I1g5z; 1.12 date 2016.05.01.20.51.36; author dholland; state Exp; branches; next 1.11; commitid lInbcnSGAd9qZO4z; 1.11 date 2015.11.20.08.13.41; author dholland; state Exp; branches; next 1.10; commitid v7yPb7A5MjZe2OJy; 1.10 date 2015.11.20.07.20.21; author dholland; state Exp; branches; next 1.9; commitid 4EvecMj8xr9XJNJy; 1.9 date 2012.01.14.22.06.16; author agc; state Exp; branches; next 1.8; 1.8 date 2009.11.17.21.09.54; author agc; state Exp; branches 1.8.6.1; next 1.7; 1.7 date 2009.10.02.07.43.01; author cegger; state Exp; branches; next 1.6; 1.6 date 2009.10.02.07.17.16; author cegger; state Exp; branches; next 1.5; 1.5 date 2009.09.15.21.07.58; author agc; state Exp; branches; next 1.4; 1.4 date 2009.01.26.05.09.25; author agc; state Exp; branches; next 1.3; 1.3 date 2009.01.26.04.55.59; author agc; state Exp; branches; next 1.2; 1.2 date 2008.08.04.15.39.46; author simonb; state Exp; branches 1.2.2.1; next 1.1; 1.1 date 2008.03.19.20.12.53; author agc; state Exp; branches 1.1.2.1 1.1.4.1 1.1.8.1 1.1.10.1; next ; 1.28.4.1 date 2025.08.02.05.20.42; author perseant; state Exp; branches; next ; commitid 23j6GFaDws3O875G; 1.26.2.1 date 2019.06.10.21.42.38; author christos; state Exp; branches; next ; commitid jtc8rnCzWiEEHGqB; 1.23.2.1 date 2018.04.16.01.57.33; author pgoyette; state Exp; branches; next ; commitid qk3nktk0szmTIByA; 1.21.2.1 date 2017.04.21.16.51.16; author bouyer; state Exp; branches; next ; commitid dUG7nkTKALCadqOz; 1.15.2.1 date 2016.11.04.14.42.40; author pgoyette; state Exp; branches; next 1.15.2.2; commitid 2m1JRwYmpwPkOOsz; 1.15.2.2 date 2017.01.07.08.53.45; author pgoyette; state Exp; branches; next 1.15.2.3; commitid uEL0C1YuiJrlV0Bz; 1.15.2.3 date 2017.03.20.06.52.12; author pgoyette; state Exp; branches; next 1.15.2.4; commitid jjw7cAwgyKq7RfKz; 1.15.2.4 date 2017.04.26.02.52.18; author pgoyette; state Exp; branches; next ; commitid ojV02aOSdzvBqZOz; 1.8.6.1 date 2012.04.17.00.02.56; author yamt; state Exp; branches; next ; 1.2.2.1 date 2009.01.26.05.15.53; author snj; state Exp; branches; next 1.2.2.2; 1.2.2.2 date 2009.01.26.05.17.44; author snj; state Exp; branches; next ; 1.1.2.1 date 2008.03.19.20.12.53; author matt; state dead; branches; next 1.1.2.2; 1.1.2.2 date 2008.03.23.00.23.07; author matt; state Exp; branches; next ; 1.1.4.1 date 2008.03.19.20.12.53; author keiichi; state dead; branches; next 1.1.4.2; 1.1.4.2 date 2008.03.24.07.14.40; author keiichi; state Exp; branches; next ; 1.1.8.1 date 2008.03.19.20.12.53; author mjf; state dead; branches; next 1.1.8.2; 1.1.8.2 date 2008.10.05.20.11.18; author mjf; state Exp; branches; next ; 1.1.10.1 date 2008.09.18.04.40.19; author wrstuden; state Exp; branches; next ; desc @@ 1.30 log @doc: Update roadmaps for 2025. - Support for arm64 is pretty advanced now and not the biggest problem with supporting phone hardware. (yay, progress!) - ZFS was updated to be based on FreeBSD's version, and "works", but more stabilization, optimization, and updating is always needed. - NVME's been supported for several major releases now, but more optimization work is always needed. - Our scheduler is now topology-aware (yay, progress!) - Mention aarch64 support in nvmm. @ text @$NetBSD: storage,v 1.29 2024/09/08 09:36:45 rillig Exp $ NetBSD Storage Roadmap ====================== This is a small roadmap document, and deals with the storage and file systems side of the operating system. It discusses elements, projects, and goals that are under development or under discussion; and it is divided into three categories based on perceived priority. The following elements, projects, and goals are considered strategic priorities for the project: 1. Improving iscsi 2. nfsv4 support 3. A better journaling file system solution 4. Stabilizing and improving zfs support 5. Seamless full-disk encryption 6. Finish tls-maxphys The following elements, projects, and goals are not strategic priorities but are still important undertakings worth doing: 7. lfs64 8. Per-process namespaces 9. lvm tidyup 10. Flash translation layer 11. Shingled disk support 12. ext3/ext4 support 13. Port hammer from Dragonfly 14. afs maintenance 15. execute-in-place 16. extended attributes for acl and capability storage The following elements, projects, and goals are perhaps less pressing; this doesn't mean one shouldn't work on them but the expected payoff is perhaps less than for other things: 17. coda maintenance Explanations ============ 1. Improving iscsi ------------------ Both the existing iscsi target and initiator are fairly bad code, and neither works terribly well. Fixing this is fairly important as iscsi is where it's at for remote block devices. Note that there appears to be no compelling reason to move the target to the kernel or otherwise make major architectural changes. - As of January 2017 nobody is known to be working on this. - There is currently no clear timeframe or release target. - Contact agc for further information. 2. nfsv4 support ---------------- nfsv4 is at this point the de facto standard for FS-level (as opposed to block-level) network volumes in production settings. The legacy nfs code currently in NetBSD only supports nfsv2 and nfsv3. The intended plan is to port FreeBSD's nfsv4 code, which also includes nfsv2 and nfsv3 support, and eventually transition to it completely, dropping our current nfs code. (Which is kind of a mess.) So far the only step that has been taken is to import the code from FreeBSD. The next step is to update that import (since it was done a while ago now) and then work on getting it to configure and compile. - As of January 2017 pgoyette has done a bit of prodding of the code recently, but otherwise nobody is working on this, and a volunteer to take charge and move it forward rapidly is urgently needed. - There is no clear timeframe or release target, although having an experimental version ready for -8 would be great. - Contact dholland for further information. 3. A better journaling file system solution ------------------------------------------- WAPBL, the journaling FFS that NetBSD rolled out some time back, has a critical problem: it does not address the historic ffs behavior of allowing stale on-disk data to leak into user files in crashes. And because it runs faster, this happens more often and with more data. This situation is both a correctness and a security liability. Fixing it has turned out to be difficult. It is not really clear what the best option at this point is: + Fixing WAPBL (e.g. to flush newly allocated/newly written blocks to disk early) has been examined by several people who know the code base and judged difficult. Also, some other problems have come to light more recently; e.g. PR 50725, and 45676. Still, it might be the best way forward. Some performance and stability issues were resolved in netbsd-8, and more work is planned. + There is another journaling FFS; the Harvard one done by Margo Seltzer's group some years back. We have a copy of this, but as it was written in BSD/OS circa 1999 it needs a lot of merging, and then will undoubtedly also need a certain amount of polishing to be ready for production use. It does record-based rather than block-based journaling and does not share the stale data problem. + We could bring back softupdates (in the softupdates-with-journaling form found today in FreeBSD) -- this code is even more complicated than the softupdates code we removed back in 2009, and it's not clear that it's any more robust either. However, it would solve the stale data problem if someone wanted to port it over. It isn't clear that this would be any less work than getting the Harvard journaling FFS running... or than writing a whole new file system either. + We could write a whole new journaling file system. (That is, not FFS. Doing a new journaling FFS implementation is probably not sensible relative to merging the Harvard journaling FFS.) This is a big project. Right now it is not clear which of these avenues is the best way forward. Given the general manpower shortage, it may be that the best way is whatever looks best to someone who wants to work on the problem. - There is no clear timeframe or release target; but given that WAPBL has been disabled by default for new installs in -7 this problem can reasonably be said to have become critical. - jdolecek fixed some WAPBL stability issues, that work is included in netbsd-8, could be possibly enough for making it default for new installs again; there is kern/47030 which seems to be triggered by WAPBL however - There has been some interest in the Harvard journaling FFS but no significant progress. Nobody is known to be working on or particularly interested in porting softupdates-with-journaling. And, while dholland has been mumbling for some time about a plan for a specific new file system to solve this problem, there isn't any realistic prospect of significant progress on that in the foreseeable future, and nobody else is known to have or be working on even that much. - Contact joerg, martin, or jdolecek regarding WAPBL; contact dholland regarding the Harvard journaling FFS. 5. Seamless full-disk encryption -------------------------------- (This is only sort of a storage issue.) We have cgd, and it is believed to still be cryptographically suitable, at least for the time being. However, we don't have any of the following things: + An easy way to install a machine with full-disk encryption. It should really just be a checkbox item in sysinst, or not much more than that. + Ideally, also an easy way to turn on full-disk encryption for a machine that's already been installed, though this is harder. + A good story for booting off a disk that is otherwise encrypted; obviously one cannot encrypt the bootblocks, but it isn't clear where in boot the encrypted volume should take over, or how to make a best effort at protecting the unencrypted elements needed to boot. (At least, in the absence of something like UEFI secure boot combined with a cryptographic oracle to sign your bootloader image so UEFI will accept it.) There's also the question of how one runs cgdconfig(8) and where the cgdconfig binary comes from. + A reasonable way to handle volume passphrases. MacOS apparently uses login passwords for this (or as passphrases for secondary keys, or something) and this seems to work well enough apart from the somewhat surreal experience of sometimes having to log in twice. However, it will complicate the bootup story. Given the increasing regulatory-level importance of full-disk encryption, this is at least a de facto requirement for using NetBSD on laptops in many circumstances. - As of January 2017 nobody is known to be working on this. - There is no clear timeframe or release target. - Contact dholland for further information. 6. Finish tls-maxphys --------------------- The tls-maxphys branch changes MAXPHYS (the maximum size of a single I/O request) from a global fixed constant to a value that's probed separately for each particular I/O channel based on its capabilities. Large values are highly desirable for e.g. feeding large disk arrays and SSDs, but do not work with all hardware. The code is nearly done and just needs more testing and support in more drivers. - On October 2017 jdolecek re-synced the branch, intention is to wrap this up for future netbsd-9 - Contact jdolecek or tls for further information. 7. lfs64 -------- LFS currently only supports volumes up to 2 TB. As LFS is of interest for use on shingled disks (which are larger than 2 TB) and also for use on disk arrays (ditto) this is something of a problem. A 64-bit version of LFS for large volumes is in the works. - dholland was working on this in fall 2015 but time to finish it dried up. - The goal now is to get a few remaining things done in time for 8.0 so it will at least be ready for experimental use there. - Responsible: dholland 8. Per-process namespaces ------------------------- Support for per-process variation of the file system namespace enables a number of things; more flexible chroots, for example, and also potentially more efficient pkgsrc builds. dholland thought up a somewhat hackish but low-footprint way to implement this, and has a preliminary implementation, but concluded the scheme was too fragile for production. A different approach is probably needed, although the existing code could be tidied up and committed if that seems desirable. - As of January 2017 nobody is working on this. - Contact: dholland 9. lvm tidyup -------------- [agc says someone should look at our lvm stuff; XXX fill this in] - As of January 2017 nobody is known to be working on this. - There is no clear timeframe or release target. - Contact agc for further information. 10. Flash translation layer --------------------------- SSDs ship with firmware called a "flash translation layer" that arbitrates between the block device software expects to see and the raw flash chips. FTLs handle wear leveling, lifetime management, and also internal caching, striping, and other performance concerns. While NetBSD has a file system for raw flash (chfs), it seems that given things NetBSD is often used for it ought to come with a flash translation layer as well. Note that this is an area where writing your own is probably a bad plan; it is a complicated area with a lot of prior art that's also reportedly full of patent mines. There are a couple of open FTL implementations that we might be able to import. - As of January 2017 nobody is known to be working on this. - There is no clear timeframe or release target. - Contact dholland for further information. 11. Shingled disk support ------------------------- Shingled disks (or more technically, disks with "shingled magnetic recording" or SMR) can only write whole tracks at once. Thus, to operate effectively they require translation support similar to the flash translation layers found in SSDs. The nature and structure of shingle translation layers is still being researched; however, at some point we will want to support these things in NetBSD. - As of 2016 one of dholland's coworkers was looking at this. - There is no clear timeframe or release target. - Contact dholland for further information. 12. ext3/ext4 support --------------------- Currently people are mostly using the kernel implementation of ext2 or using filesystems/fuse-ext2 from pkgsrc for later versions. We would like to be able to read and write Linux ext3fs and ext4fs volumes. (We can already read clean ext3fs volumes as they're the same as ext2fs, modulo volume features our ext2fs code does not support; but we can't write them.) Ideally someone would write ext3 and/or ext4 code, whether integrated with or separate from the ext2 code we already have. It might also make sense to port or wrap the Linux ext3 or ext4 code so it can be loaded as a GPL'd kernel module; it isn't clear if that would be more or less work than doing an implementation. Note however that implementing ext3 has already defeated several people; this is a harder project than it looks. - GSoc 2016 brought support for extents, and also ro support for dir hashes; jdolecek also implemented several frequently used ext4 features so most contemporary ext filesystems should be possible to mount read-write - still need rw dir_nhash and xattr (semi-easy), and eventually journaling (hard) - There is no clear timeframe or release target. - jdolecek is working on improving ext3/ext4 support (particularly journaling) 13. Port hammer from Dragonfly ------------------------------ While the motivation for and role of hammer isn't perhaps super persuasive, it would still be good to have it. Porting it from Dragonfly is probably not that painful (compared to, say, zfs) but as the Dragonfly and NetBSD VFS layers have diverged in different directions from the original 4.4BSD, may not be entirely trivial either. - As of January 2017 nobody is known to be working on this. - There is no clear timeframe or release target. - There probably isn't any particular person to contact; for VFS concerns contact dholland or hannken. 14. afs maintenance ------------------- AFS needs periodic care and feeding to continue working as NetBSD changes, because the kernel-level bits aren't kept in the NetBSD tree and don't get updated with other things. This is an ongoing issue that always seems to need more manpower than it gets. It might make sense to import some of the kernel AFS code, or maybe even just some of the glue layer that it uses, in order to keep it more current. - jakllsch sometimes works on this. - We would like every release to have working AFS by the time it's released. - Contact jakllsch or gendalia about AFS; for VFS concerns contact dholland or hannken. 15. execute-in-place -------------------- It is likely that the future includes non-volatile storage (so-called "nvram") that looks like RAM from the perspective of software. Most importantly: the storage is memory-mapped rather than looking like a disk controller. There are a number of things NetBSD ought to have to be ready for this, of which probably the most important is "execute-in-place": when an executable is run from such storage, and mapped into user memory with mmap, the storage hardware pages should be able to appear directly in user memory. Right now they get gratuitously copied into RAM, which is slow and wasteful. There are also other reasons (e.g. embedded device ROMs) to want execute-in- place support. Note that at the implementation level this is a UVM issue rather than strictly a storage issue. Also note that one does not need access to nvram hardware to work on this issue; given the performance profiles touted for nvram technologies, a plain RAM disk like md(4) is sufficient both structurally and for performance analysis. - As of January 2017 nobody is known to be working on this. Some time back, uebayasi wrote some preliminary patches, but they were rejected by the UVM maintainers. - There is no clear timeframe or release target. - Contact dholland for further information. 16. use extended attributes for ACL and capability storage ---------------------------------------------------------- Currently there is some support for extended attributes in ffs, but nothing really uses it. I would be nice if we came up with a standard format to store ACL's and capabilities like Linux has. The various tools must be modified to understand this and be able to copy them if requested. Also tools to manipulate the data will need to be written. 17. coda maintenance -------------------- Coda only sort of works. [And I think it's behind relative to upstream, or something of the sort; XXX fill this in.] Also the code appears to have an ugly incestuous relationship with FFS. This should really be cleaned up. That or maybe it's time to remove Coda. - As of January 2017 nobody is known to be working on this. - There is no clear timeframe or release target. - There isn't anyone in particular to contact. - Circa 2012 christos made it work read-write and split it into modules. Since then christos has not tested it. Alistair Crooks, David Holland Fri Nov 20 02:17:53 EST 2015 Sun May 1 16:50:42 EDT 2016 (some updates) Fri Jan 13 00:40:50 EST 2017 (some more updates) @ 1.29 log @fix a/an grammar in obvious cases @ text @d1 1 a1 1 $NetBSD: storage,v 1.28 2021/10/21 13:21:53 andvar Exp $ d17 1 a17 1 4. Getting zfs working for real d24 10 a33 11 7. nvme support 8. lfs64 9. Per-process namespaces 10. lvm tidyup 11. Flash translation layer 12. Shingled disk support 13. ext3/ext4 support 14. Port hammer from Dragonfly 15. afs maintenance 16. execute-in-place 17. extended attributes for acl and capability storage d39 1 a39 1 18. coda maintenance a142 14 4. Getting zfs working for real ------------------------------- ZFS has been almost working for years now. It is high time we got it really working. One of the things this entails is updating the ZFS code, as what we have is rather old. The Illumos version is probably what we want for this. - There has been intermittent work on zfs, but as of January 2017 nobody is known to be actively working on it - There is no clear timeframe or release target. - Contact riastradh or ?? for further information. d198 1 a198 22 7. nvme support ---------------- nvme ("NVM Express") is a hardware interface standard for PCI-attached SSDs. NetBSD now has a driver for these. Driver is now MPSAFE and uses bufq fcfs (i.e. no disksort()) already, so the most obvious software bottlenecks were treated. It still needs more testing on real hardware, and it may be good to investigate some further optimizations, such as DragonFly pbuf(9) or something similar. Semi-relatedly, it is also time for scsipi to become MPSAFE. - As of May 2016 a port of OpenBSD's driver has been committed. This will be in -8. - The nvme driver is a backend to ld(4) and is fully is MPSAFE, but we still need to attend to I/O path bottlenecks like kern/53124. Better instrumentation is needed. - Contact msaitoh, agc, or jdolecek for further information. 8. lfs64 d213 1 a213 1 9. Per-process namespaces d228 1 a228 1 10. lvm tidyup d238 1 a238 1 11. Flash translation layer d259 1 a259 1 12. Shingled disk support d274 1 a274 1 13. ext3/ext4 support d277 3 d305 1 a305 1 14. Port hammer from Dragonfly d321 1 a321 1 15. afs maintenance d338 1 a338 1 16. execute-in-place d368 1 a368 1 17. use extended attributes for ACL and capability storage d379 1 a379 1 18. coda maintenance @ 1.28 log @fix various typos, mainly in comments, but also in man pages and log messages. @ text @d1 1 a1 1 $NetBSD: storage,v 1.27 2019/05/29 02:34:19 msaitoh Exp $ d177 1 a177 1 an cryptographic oracle to sign your bootloader image so UEFI will @ 1.28.4.1 log @Sync with HEAD @ text @d1 1 a1 1 $NetBSD: storage,v 1.30 2025/05/19 18:02:53 nia Exp $ d17 1 a17 1 4. Stabilizing and improving zfs support d24 11 a34 10 7. lfs64 8. Per-process namespaces 9. lvm tidyup 10. Flash translation layer 11. Shingled disk support 12. ext3/ext4 support 13. Port hammer from Dragonfly 14. afs maintenance 15. execute-in-place 16. extended attributes for acl and capability storage d40 1 a40 1 17. coda maintenance d144 14 d177 1 a177 1 a cryptographic oracle to sign your bootloader image so UEFI will d213 22 a234 1 7. lfs64 d249 1 a249 1 8. Per-process namespaces d264 1 a264 1 9. lvm tidyup d274 1 a274 1 10. Flash translation layer d295 1 a295 1 11. Shingled disk support d310 1 a310 1 12. ext3/ext4 support a312 3 Currently people are mostly using the kernel implementation of ext2 or using filesystems/fuse-ext2 from pkgsrc for later versions. d338 1 a338 1 13. Port hammer from Dragonfly d354 1 a354 1 14. afs maintenance d371 1 a371 1 15. execute-in-place d401 1 a401 1 16. use extended attributes for ACL and capability storage d412 1 a412 1 17. coda maintenance @ 1.27 log @s/suppport/support/ @ text @d1 1 a1 1 $NetBSD: storage,v 1.26 2018/04/12 19:12:25 jdolecek Exp $ d226 1 a226 1 - As of May 2016 a port of OpenBSD's driver has been commited. This d331 1 a331 1 - still need rw dir_nhash and xattr (semi-easy), and eventually journalling d334 2 a335 2 - jdolecek is working on improving ext3/ext4 support (particularily journalling) @ 1.26 log @fix year for the tls-maxphys resync @ text @d1 1 a1 1 $NetBSD: storage,v 1.25 2018/04/12 19:11:35 jdolecek Exp $ d213 1 a213 1 7. nvme suppport @ 1.26.2.1 log @Sync with HEAD @ text @d1 1 a1 1 $NetBSD: storage,v 1.27 2019/05/29 02:34:19 msaitoh Exp $ d213 1 a213 1 7. nvme support @ 1.25 log @update tls-maxphys @ text @d1 1 a1 1 $NetBSD: storage,v 1.24 2018/04/12 19:08:02 jdolecek Exp $ d208 1 a208 1 - On October 2018 jdolecek re-synced the branch, intention is to wrap @ 1.24 log @update the NVMe entry; perhaps time to consider good enough and remove from here? @ text @d1 1 a1 1 $NetBSD: storage,v 1.23 2017/10/31 19:03:32 jdolecek Exp $ d208 3 a210 3 - As of January 2017 nobody is known to be working on this. - There is no clear timeframe or release target. - Contact tls for further information. @ 1.23 log @bring the WAPBL entry more up-to-date and sound less desperate, there is not really much preventing it to be enabled by default for new installs again actually @ text @d1 1 a1 1 $NetBSD: storage,v 1.22 2017/04/19 21:48:58 jdolecek Exp $ d228 4 a231 8 - The nvme driver is a backend to ld(4) which is MPSAFE, but we still need to attend to I/O path bottlenecks. Better instrumentation is needed. - Flush cache commands via DIOCCACHESYNC currently doesn't wait for completion; it must not poll since that corrupts command queue, but it should use a condition variable to wait for the flush to actually finish - There is no clear timeframe or release target for these points. - Contact msaitoh or agc for further information. @ 1.23.2.1 log @Sync with HEAD, resolve some conflicts @ text @d1 1 a1 1 $NetBSD: storage,v 1.26 2018/04/12 19:12:25 jdolecek Exp $ d208 3 a210 3 - On October 2017 jdolecek re-synced the branch, intention is to wrap this up for future netbsd-9 - Contact jdolecek or tls for further information. d228 8 a235 4 - The nvme driver is a backend to ld(4) and is fully is MPSAFE, but we still need to attend to I/O path bottlenecks like kern/53124. Better instrumentation is needed. - Contact msaitoh, agc, or jdolecek for further information. @ 1.22 log @ld(4) already improved to arbitrary ioctls, and nvme(4) updated to support both DIOCGCACHE and DIOCCACHESYNC @ text @d1 1 a1 1 $NetBSD: storage,v 1.21 2017/01/13 10:14:58 dholland Exp $ d97 2 a98 1 way forward. d125 7 d140 2 a141 7 - There is no clear timeframe or release target; but given that WAPBL has been disabled by default for new installs in -7 this problem can reasonably be said to have become critical. - jdolecek is working on fixing WAPBL, goal is to get WAPBL fixed enough to be safe to re-enable as default for -8 - Contact joerg or martin regarding WAPBL; contact dholland regarding the Harvard journaling FFS. @ 1.21 log @Update roadmaps, unilaterally, because most of these hadn't been touched since the pre-6.0 period and nobody else has been doing the work. There's a lot of things whose current state I don't know; please fill in. Also the stuff I've added is necessarily biased towards projects I think about, so please add more. @ text @d1 1 a1 1 $NetBSD: storage,v 1.20 2016/11/10 21:28:15 jdolecek Exp $ a230 5 - NVMe controllers supports write cache administration via GET/SET FEATURE, but driver doesn't currently implement the cache ioctls, leading to somewhat ugly dkctl(1) output; it would be fairly simple to add this, but would require ld(4) attachment code changed to support passing arbitrary ioctls to attachments @ 1.21.2.1 log @Sync with HEAD @ text @d1 1 a1 1 $NetBSD: storage,v 1.22 2017/04/19 21:48:58 jdolecek Exp $ d231 5 @ 1.20 log @update the wapbl entry - kern/47146 and kern/49175 are fixed @ text @d1 1 a1 1 $NetBSD: storage,v 1.19 2016/10/28 20:30:37 jdolecek Exp $ d55 1 a55 1 - As of November 2015 nobody is known to be working on this. d74 3 a76 2 - As of November 2015 nobody is working on this, and a volunteer to take charge is urgently needed. d149 1 a149 1 - There has been intermittent work on zfs, but as of November 2015 d188 1 a188 1 - As of November 2015 nobody is known to be working on this. d200 1 a200 1 disk arrays but do not work with all hardware. d205 1 a205 1 - As of November 2015 nobody is known to be working on this. d248 4 a251 3 - As of November 2015 dholland is working on this. - It is close to being ready for at least experimental use and is expected to be in 8.0. d261 4 a264 1 somewhat hackish but low-footprint way to implement this. d266 2 a267 3 - As of November 2015 dholland is working on this. - It is scheduled to be in 8.0. - Responsible: dholland d275 1 a275 1 - As of November 2015 nobody is known to be working on this. d296 1 a296 1 - As of November 2015 nobody is known to be working on this. d311 1 a311 1 - As of November 2015 one of dholland's coworkers is looking at this. d354 1 a354 1 - As of November 2015 nobody is known to be working on this. d400 1 a400 1 - As of November 2015 nobody is known to be working on this. Some d417 1 d426 1 a426 1 - As of November 2015 nobody is known to be working on this. d432 1 d436 1 @ 1.19 log @adjust the nvme entry; the flush cache is now asynchronous, and be more specific for the get/set cache entry too @ text @d1 1 a1 1 $NetBSD: storage,v 1.18 2016/09/21 20:32:47 jdolecek Exp $ d95 2 a96 3 more recently; e.g. PR 50725, PR 47146, and a problem where truncating large sparse files takes ~forever in PR 49175. Also see PR 45676. Still, it might be the best way forward. @ 1.18 log @update nvme entry to current reality @ text @d1 1 a1 1 $NetBSD: storage,v 1.17 2016/09/16 15:02:23 jdolecek Exp $ d228 3 a230 4 - Flush cache commands via DIOCCACHESYNC is currently implemented using polled commands for simplicity, limiting speed to about 10 milliseconds due to use of delay(9); investigate if it's worth changing this to a cv to avoid the delay, especially for journalled/heavy fsync scenarios d234 2 a235 1 require small changes to ld(4) attachment code @ 1.17 log @volunteer for the ext3/ext4 also @ text @d1 1 a1 1 $NetBSD: storage,v 1.16 2016/09/16 14:55:28 jdolecek Exp $ d214 6 a219 7 SSDs. NetBSD now has a driver for these; however, it was ported from OpenBSD and is not (yet) MPSAFE. This is, unfortunately, a fairly serious limitation given the point and nature of nvme devices. Relatedly, the I/O path needs to be restructured to avoid software bottlenecks on the way to an nvme device: they are fast enough that things like disksort() do not make sense. d228 8 @ 1.16 log @I'm working on WAPBL fixes, adjust the entry @ text @d1 1 a1 1 $NetBSD: storage,v 1.15 2016/05/17 21:03:36 christos Exp $ d323 6 a328 2 - As of May 2016 there is a GSoC project to implement read-only ext4 support, but (it not being summer yet) no particular progress. d330 2 a331 1 - Contact ?? for further information. @ 1.15 log @mention my last coda work @ text @d1 1 a1 1 $NetBSD: storage,v 1.14 2016/05/14 21:32:50 mlelstv Exp $ d96 2 a97 2 large sparse files takes ~forever. Also see PR 45676. Still, it might be the best way forward. d124 2 a125 3 - As of November 2015 nobody is working on fixing WAPBL. There has been some interest in the Harvard journaling FFS but no significant progress. Nobody is known to be working on or particularly d135 2 @ 1.15.2.1 log @Sync with HEAD @ text @d1 1 a1 1 $NetBSD: storage,v 1.19 2016/10/28 20:30:37 jdolecek Exp $ d96 2 a97 2 large sparse files takes ~forever in PR 49175. Also see PR 45676. Still, it might be the best way forward. d124 3 a126 2 - There has been some interest in the Harvard journaling FFS but no significant progress. Nobody is known to be working on or particularly a135 2 - jdolecek is working on fixing WAPBL, goal is to get WAPBL fixed enough to be safe to re-enable as default for -8 d213 7 a219 6 SSDs. NetBSD now has a driver for these. Driver is now MPSAFE and uses bufq fcfs (i.e. no disksort()) already, so the most obvious software bottlenecks were treated. It still needs more testing on real hardware, and it may be good to investigate some further optimizations, such as DragonFly pbuf(9) or something similar. a227 8 - Flush cache commands via DIOCCACHESYNC currently doesn't wait for completion; it must not poll since that corrupts command queue, but it should use a condition variable to wait for the flush to actually finish - NVMe controllers supports write cache administration via GET/SET FEATURE, but driver doesn't currently implement the cache ioctls, leading to somewhat ugly dkctl(1) output; it would be fairly simple to add this, but would require ld(4) attachment code changed to support passing arbitrary ioctls to attachments d322 2 a323 6 - GSoc 2016 brought support for extents, and also ro support for dir hashes; jdolecek also implemented several frequently used ext4 features so most contemporary ext filesystems should be possible to mount read-write - still need rw dir_nhash and xattr (semi-easy), and eventually journalling (hard) d325 1 a325 2 - jdolecek is working on improving ext3/ext4 support (particularily journalling) @ 1.15.2.2 log @Sync with HEAD. (Note that most of these changes are simply $NetBSD$ tag issues.) @ text @d1 1 a1 1 $NetBSD: storage,v 1.20 2016/11/10 21:28:15 jdolecek Exp $ d95 3 a97 2 more recently; e.g. PR 50725, and 45676. Still, it might be the best way forward. @ 1.15.2.3 log @Sync with HEAD @ text @d1 1 a1 1 $NetBSD: storage,v 1.21 2017/01/13 10:14:58 dholland Exp $ d55 1 a55 1 - As of January 2017 nobody is known to be working on this. d74 2 a75 3 - As of January 2017 pgoyette has done a bit of prodding of the code recently, but otherwise nobody is working on this, and a volunteer to take charge and move it forward rapidly is urgently needed. d148 1 a148 1 - There has been intermittent work on zfs, but as of January 2017 d187 1 a187 1 - As of January 2017 nobody is known to be working on this. d199 1 a199 1 disk arrays and SSDs, but do not work with all hardware. d204 1 a204 1 - As of January 2017 nobody is known to be working on this. d247 3 a249 4 - dholland was working on this in fall 2015 but time to finish it dried up. - The goal now is to get a few remaining things done in time for 8.0 so it will at least be ready for experimental use there. d259 1 a259 4 somewhat hackish but low-footprint way to implement this, and has a preliminary implementation, but concluded the scheme was too fragile for production. A different approach is probably needed, although the existing code could be tidied up and committed if that seems desirable. d261 3 a263 2 - As of January 2017 nobody is working on this. - Contact: dholland d271 1 a271 1 - As of January 2017 nobody is known to be working on this. d292 1 a292 1 - As of January 2017 nobody is known to be working on this. d307 1 a307 1 - As of 2016 one of dholland's coworkers was looking at this. d350 1 a350 1 - As of January 2017 nobody is known to be working on this. d396 1 a396 1 - As of January 2017 nobody is known to be working on this. Some a412 1 d421 1 a421 1 - As of January 2017 nobody is known to be working on this. a426 1 a429 1 Fri Jan 13 00:40:50 EST 2017 (some more updates) @ 1.15.2.4 log @Sync with HEAD @ text @d1 1 a1 1 $NetBSD: storage,v 1.22 2017/04/19 21:48:58 jdolecek Exp $ d231 5 @ 1.14 log @updated nvme entry @ text @d1 1 a1 1 $NetBSD: storage,v 1.13 2016/05/05 06:17:45 dholland Exp $ d34 1 d40 1 a40 1 17. coda maintenance d391 11 a401 1 17. coda maintenance d412 2 a413 1 @ 1.13 log @mention some of the other known severe wapbl problems @ text @d1 1 a1 1 $NetBSD: storage,v 1.12 2016/05/01 20:51:36 dholland Exp $ d224 3 a226 2 - However, the driver still needs to be made MPSAFE, and we still need to attend to scsipi and various other I/O path bottlenecks. @ 1.12 log @Update: we got an nvme driver. Also mention the ext4 GSoC project. @ text @d1 1 a1 1 $NetBSD: storage,v 1.11 2015/11/20 08:13:41 dholland Exp $ d93 4 a96 1 and judged difficult. Still, it might be the best way forward. @ 1.11 log @Add two more items: tls-maxphys and nvme support. @ text @d1 1 a1 1 $NetBSD: storage,v 1.10 2015/11/20 07:20:21 dholland Exp $ d209 3 a211 5 SSDs. NetBSD currently has no driver for these; unfortunately, while both FreeBSD and OpenBSD do neither of their drivers is likely directly suitable: the FreeBSD driver is severely overcomplicated and the OpenBSD driver won't be MPSAFE. (And there isn't much point in a non-MPSAFE nvme driver.) d219 5 a223 2 - As of November 2015 nobody is known to be working on this. - There is no clear timeframe or release target. d317 2 a318 1 - As of November 2015 nobody is known to be working on this. d401 2 @ 1.10 log @Update the storage roadmap. Please review/comment... @ text @d1 1 a1 1 $NetBSD: storage,v 1.9 2012/01/14 22:06:16 agc Exp $ d19 1 d24 10 a33 9 6. lfs64 7. Per-process namespaces 8. lvm tidyup 9. Flash translation layer 10. Shingled disk support 11. ext3/ext4 support 12. Port hammer from Dragonfly 13. afs maintenance 14. execute-in-place d39 1 a39 1 15. coda maintenance d188 39 a226 1 6. lfs64 d240 1 a240 1 7. Per-process namespaces d253 2 a254 2 8. lvm tidyup ------------- d263 2 a264 2 9. Flash translation layer -------------------------- d284 1 a284 1 10. Shingled disk support d299 1 a299 1 11. ext3/ext4 support d321 1 a321 1 12. Port hammer from Dragonfly d337 1 a337 1 13. afs maintenance d354 1 a354 1 14. execute-in-place d384 1 a384 1 15. coda maintenance @ 1.9 log @Bring the storage roadmap up to date wrt 6.0 and features. A huge thank you to dholland for his help on this. This still has some updates to happen for post-6.0 features; they will be added RSN. @ text @d1 1 a1 1 $NetBSD: storage,v 1.8 2009/11/17 21:09:54 agc Exp $ d7 29 a35 1 systems side of the operating system. d37 1 a37 2 The following elements and projects are pencilled in for 6.0, but please do not rely on them being there. a38 9 Features that will be in 6.0: 2. logical volume management 3. a native port of Sun's ZFS 4. ReFUSE, perfuse and pud 6. Support for flash devices - NAND, and flash file system 7. rump extensions 9. in-kernel iSCSI initiator 10. RAIDframe parity map 11. quota system re-work d40 2 a41 5 Features that are planned for future releases: 1. devfs/udevfsd 5. web-based management tools for storage subsystems 8. virtualised disks in userland 12. lfs renovation d43 2 a44 1 We'll continue to update this roadmap as features and dates get firmed up. d46 100 a145 2 Some explanations ================= a146 2 1. udevfsd ---------- d148 2 a149 14 There has always been discussion over devfs, and experience with it seems mixed (to be kind). At the same time, carrying around a whole populated /dev seems quite possible and effective, but maybe a bit unwieldy. jmcneill's udevfsd addresses this in a different way, and is currently in othersrc/external/bsd/udevfsd. Not planned for 6.0 right now. Responsible: jmcneill 2. Logical Volume Management ---------------------------- Based on the Linux lvm2 and devmapper software, with a new kernel component for NetBSD written. Merged in 5.99.5 sources, will be in 6.0. d151 3 a153 1 Responsible: haad, martin d155 3 a157 2 3. Native port of Sun's ZFS --------------------------- d159 2 a160 7 Two Summer of Code projects have been held, concentrating on the provision of ZFS support for NetBSD. Mostly completed by haad, and building on ver's work, this is the port of Sun's ZFS, with modifications to make it compile on NetBSD by ad@@, and based on the Sun code for the block layer. Discussions are still taking place to get the design right for support for the openat(2) system call family, and the correct architecture for reclaiming vnodes. d162 8 a169 1 The ZFS source code has been committed to the repository. d171 5 a175 1 Responsible: haad, ad, ver d177 3 a179 2 4. ReFUSE, perfuse and pud -------------------------- d181 3 a183 30 FUSE has two interfaces, the normal high-level one, and a lower-level interface which is closer to the way standard file systems operate. manu's perfuse adds the low-level functionality in the same way that ReFUSE adds the high-level functionality. In addition, there is the "pass to userspace device" framework added by pooka as part of rump. All 3 will be in 6.0. Responsible: pooka, manu, agc 5. Web-based Management tools for Storage Subsystems ---------------------------------------------------- Standard tools for managing the storage subsystems that NetBSD provides, using a standard web-server as the basic user interface on the storage device, allowing remote management by a standard web browser. CIM and related functinoality are interesting datapoints in this space, although credentials and authentication are always challenges in this space. Will not make it into 6.0 Responsible: agc 6. Support for flash devices - NAND, and flash file system ---------------------------------------------------------- ahoka has have contributed many things in this area, including flash(4), flash(9), flashctl(8) and nand(9). In addition, the University of Szeged has contributed chfs, http://en.wikipedia.org/wiki/CHFS, which is described as "the first open source flash specific file system written for NetBSD". All of these will be in 6.0. a184 1 Responsible: ahoka d186 2 a187 2 7. RUMP Extensions ------------------ d189 4 a192 3 Rump support has been in NetBSD for 2 releases now, and continues to be developed actively. Recent additions have included cgd support, and smbfs client support. d194 4 a197 1 Responsible: pooka d200 2 a201 2 8. Virtualised disks in Userland -------------------------------- d203 4 a206 4 For better support of virtualization, a library which provides a consistent view of virtualized disk images has been developed by jmcneill. This will not make it into 6.0, although some extra functionality for reading vmdk images is available in othersrc/external/bsd/vmdk. d208 3 a210 1 Responsible: jmcneill, agc d213 2 a214 2 9. In-kernel iSCSI Initiator ---------------------------- d216 1 a216 3 NetBSD has had a userland implementation of an iSCSI initiator since NetBSD 4.99.35, based on ReFUSE. Wasabi Systems kindly contributed their kernel-based iSCSI initiator, and it will be in 6.0. d218 3 a220 1 Responsible: riz, agc d223 2 a224 34 10. RAIDframe parity map ------------------------ Jed Davis successfully completed a Summer of Code project to implement parity map zones for RAIDframe. Parity mapping drastically reduces the amount of time spent rewriting parity after an unclean shutdown by keeping better track of which regions might have had outstanding writes. Enabled by default; can be disabled on a per-set basis, or tuned, with the new raidctl(8) commands. Merged in 5.99.22 sources, and will be in 6.0. A separate set of patches is available for NetBSD-5. Responsible: jld 11. quota system re-work ------------------------ The quota system has been re-worked by bouyer, and is in -current right now. dholland is updating and modifying this rework so that it is a more generalised solution, with better features for security. This is expected to be in 6.0, although there is a lot of work to complete. Responsible: bouyer, dholland 12. LFS renovation ------------------ LFS had been de-emphasised in the time period leading up to the 5.0 release, but is undergoing some rework by perseant, and dholland has some contributions in this area too. d226 129 a354 1 Responsible: perseant, dholland d358 1 a358 1 Sat Jan 14 05:52:37 PST 2012 @ 1.8 log @Update with status for some projects. Add some new projects, and sync with reality. @ text @d1 1 a1 1 $NetBSD: storage,v 1.7 2009/10/02 07:43:01 cegger Exp $ d15 2 d18 1 d20 1 d22 2 a23 3 Features that are planned for 6.0: 1. devfs 4. ReFUSE-lowlevel a24 1 6. support for flash devices - NAND and MMC/SD d26 1 a26 4 9. in-kernel iSCSI initiator We currently expect to branch 6.0 in the March 2010 timeframe, with a view to a 6.0 release later in 2010. d33 2 a34 2 1. devfs --------- d36 6 a41 8 Devfs will allow device special files (the files used to access devices) to be created dynamically as and when they are attached to the system. This will greatly reduce the number of files in a /dev directory and removes the need to run the MAKEDEV script when support for new devices is added to the NetBSD kernel. NetBSD's devfs implementation will also allow multiple instances of the file system to be mounted simultaneously, which is very useful for chroot jails. Please contact core@@ if you are interested in devfs development. d43 1 a43 1 Responsible: mjf d68 2 a69 2 4. ReFUSE-lowlevel ------------------ d72 5 a76 3 interface which is closer to the way standard file systems operate. This adds the low-level functionality in the same way that ReFUSE adds the high-level functionality d78 1 a78 1 Responsible: pooka, agc d83 6 a88 3 Standard tools for managing the storage subsystems that NetBSD provides, using a standard web-server as the basic user interface on the storage device, allowing remote management by a standard web browser. d92 2 a93 2 6. Support for flash devices - NAND and MMC/SD ---------------------------------------------- d95 6 a100 5 The NetBSD Foundation is interested in having a file system which is optimised to work with today's flash devices, including SSDs both with wear-levelling functionality and without, as well as support for NAND, and MMC/SD devices. Please get in touch with core@@ if you're interested in helping out with this area of development. d102 1 a102 1 Responsible: TBD d118 3 a120 1 view of virtualized disk images has been developed by jmcneill. d122 1 a122 1 Responsible: jmcneill d129 2 a130 3 NetBSD 4.99.35, based on ReFUSE. There is a possibility that an in-kernel initiator may be available - please contact core if you are interested in this functionality. d132 1 a132 1 Responsible: core d150 25 a174 2 Alistair Crooks Tue Nov 17 07:17:20 PST 2009 @ 1.8.6.1 log @sync with head @ text @d1 1 a1 1 $NetBSD$ a14 2 4. ReFUSE, perfuse and pud 6. Support for flash devices - NAND, and flash file system a15 1 9. in-kernel iSCSI initiator a16 1 11. quota system re-work d18 3 a20 2 Features that are planned for future releases: 1. devfs/udevfsd d22 1 d24 4 a27 1 12. lfs renovation d34 2 a35 2 1. udevfsd ---------- d37 8 a44 6 There has always been discussion over devfs, and experience with it seems mixed (to be kind). At the same time, carrying around a whole populated /dev seems quite possible and effective, but maybe a bit unwieldy. jmcneill's udevfsd addresses this in a different way, and is currently in othersrc/external/bsd/udevfsd. Not planned for 6.0 right now. d46 1 a46 1 Responsible: jmcneill d71 2 a72 2 4. ReFUSE, perfuse and pud -------------------------- d75 3 a77 5 interface which is closer to the way standard file systems operate. manu's perfuse adds the low-level functionality in the same way that ReFUSE adds the high-level functionality. In addition, there is the "pass to userspace device" framework added by pooka as part of rump. All 3 will be in 6.0. d79 1 a79 1 Responsible: pooka, manu, agc d84 3 a86 6 Standard tools for managing the storage subsystems that NetBSD provides, using a standard web-server as the basic user interface on the storage device, allowing remote management by a standard web browser. CIM and related functinoality are interesting datapoints in this space, although credentials and authentication are always challenges in this space. Will not make it into 6.0 d90 2 a91 2 6. Support for flash devices - NAND, and flash file system ---------------------------------------------------------- d93 5 a97 6 ahoka has have contributed many things in this area, including flash(4), flash(9), flashctl(8) and nand(9). In addition, the University of Szeged has contributed chfs, http://en.wikipedia.org/wiki/CHFS, which is described as "the first open source flash specific file system written for NetBSD". All of these will be in 6.0. d99 1 a99 1 Responsible: ahoka d115 1 a115 3 view of virtualized disk images has been developed by jmcneill. This will not make it into 6.0, although some extra functionality for reading vmdk images is available in othersrc/external/bsd/vmdk. d117 1 a117 1 Responsible: jmcneill, agc d124 3 a126 2 NetBSD 4.99.35, based on ReFUSE. Wasabi Systems kindly contributed their kernel-based iSCSI initiator, and it will be in 6.0. d128 1 a128 1 Responsible: riz, agc d146 2 a147 25 11. quota system re-work ------------------------ The quota system has been re-worked by bouyer, and is in -current right now. dholland is updating and modifying this rework so that it is a more generalised solution, with better features for security. This is expected to be in 6.0, although there is a lot of work to complete. Responsible: bouyer, dholland 12. LFS renovation ------------------ LFS had been de-emphasised in the time period leading up to the 5.0 release, but is undergoing some rework by perseant, and dholland has some contributions in this area too. Responsible: perseant, dholland Alistair Crooks, David Holland Sat Jan 14 05:52:37 PST 2012 @ 1.7 log @backout wrong changes after I got teached that the vowel *sound* matters and not the spelling letter (which is what I learned at school). @ text @d1 1 a1 1 $NetBSD: storage,v 1.5 2009/09/15 21:07:58 agc Exp $ d12 1 a12 1 1. devfs d15 5 a22 1 7. rump extensions d110 1 d119 1 d131 15 d147 1 a147 1 Tue 15 Sep 2009 08:44:14 PDT @ 1.6 log @fix grammar: a -> an @ text @d117 1 a117 1 NetBSD has had an userland implementation of an iSCSI initiator since @ 1.5 log @Update the NetBSD roadmaps to reflect recent changes. Please contact core if you have other major projects and requirements that you would like to see included. @ text @d1 1 a1 1 $NetBSD: storage,v 1.4 2009/01/26 05:09:25 agc Exp $ d117 1 a117 1 NetBSD has had a userland implementation of an iSCSI initiator since @ 1.4 log @Various updates to the roadmaps for features we are looking to develop over the next few years @ text @d1 1 a1 1 $NetBSD: storage,v 1.3 2009/01/26 04:55:59 agc Exp $ a8 13 NetBSD 5.0 will ship with the following storage elements in place: 1. puffs/putter 2. ReFUSE 3. rump 4. RAIDframe 5. iSCSI target 6. iSCSI initiator 7. cgd 8. fss 9. journalling functionality for ffs 10. read/write support for UDF file systems d12 12 a23 10 11. devfs 12. logical volume management 13. a native port of Sun's ZFS 14. ReFUSE-lowlevel 15. web-based management tools for storage subsystems 16. support for flash devices - NAND and MMC/SD The timescales for 6.0 are not known at the present time, but we would expect to branch 6.0 late in 2009, with a view to a 6.0 release in early 2010. d30 1 a30 1 11. devfs d40 1 d44 2 a45 8 9. Journalling Functionality for FFS ------------------------------------- Contributed by Wasabi Systems, Inc, technical review on tech-kern in March 2008, merged to HEAD in July 2008, will be in NetBSD 5.0. 12. Logical Volume Management ----------------------------- d52 10 a61 2 13. Native port of Sun's ZFS ---------------------------- d63 1 a63 4 Mostly completed by ad@@, this is the FreeBSD port of Sun's ZFS, with modifications to make it compile on NetBSD 5.0 by ad@@, and based on the original Sun code for the block layer, rather than the GEOM-based layer. d65 1 a65 1 Responsible: ad, many others d67 2 a68 2 14. ReFUSE-lowlevel ------------------- d77 2 a78 2 15. Web-based Management tools for Storage Subsystems ----------------------------------------------------- d86 38 d126 1 a126 1 Sun 25 Jan 2009 20:55:12 PST @ 1.3 log @Sync storage roadmap with reality. @ text @d1 1 a1 1 $NetBSD: storage,v 1.2 2008/08/04 15:39:46 simonb Exp $ d36 1 @ 1.2 log @Note journaling (WAPBL) is in HEAD and will be in NetBSD 5.0. @ text @d1 1 a1 1 $NetBSD: storage,v 1.1 2008/03/19 20:12:53 agc Exp $ d19 2 d22 1 a22 1 The following elements and projects are pencilled in for 5.0, but d25 1 a25 3 9. pud 10. devfs 11. journalling functionality for ffs a30 1 17. read/write support for UDF file systems d32 3 a34 21 We are working on the following elements, and expect them to be in 6.0: 18. OSD (object storage device) 19. basic FCIP support We expect to branch for the 5.0 release in April or May 2008, which would put a NetBSD 5.0 Release date in Q4 2008. An annual release cycle would thus mean that 6.0 would be branched in April or May 2009. Pictorially, this looks like: 2008 2009 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug |===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===| | ------- 5.0 --------- | | ------- 6.0 branch release branch 1-8 11,16 9,10,12,13,14,17 15 18 19 We'll continue to update this roadmap as features and dates get firmed up. d40 1 a40 1 10. devfs d53 1 a53 1 11. Journalling Functionality for FFS d63 1 a63 1 for NetBSD written. d75 1 a75 1 Responsible: oster, agc a95 9 16. OSD ------- Based on the T10 specification, and the Intel reference code. An Object Storage Device, where some of the functionality of a file system is placed in the storage device. Responsible: agc d98 1 a98 1 Sun Mar 2 23:31:03 GMT 2008 @ 1.2.2.1 log @Pull up following revision(s) (requested by agc in ticket #322): doc/roadmaps/storage: revision 1.3 Sync storage roadmap with reality. @ text @d1 1 a1 1 $NetBSD: storage,v 1.2 2008/08/04 15:39:46 simonb Exp $ a18 2 9. journalling functionality for ffs 10. read/write support for UDF file systems d20 1 a20 1 The following elements and projects are pencilled in for 6.0, but d23 3 a25 1 11. devfs d31 1 d33 21 a53 3 The timescales for 6.0 are not known at the present time, but we would expect to branch 6.0 late in 2009, with a view to a 6.0 release in early 2010. d59 1 a59 1 11. devfs d72 1 a72 1 9. Journalling Functionality for FFS d82 1 a82 1 for NetBSD written. Merged in 5.99.5 sources, will be in 6.0. d94 1 a94 1 Responsible: ad, many others d115 9 d126 1 a126 1 Sun 25 Jan 2009 20:55:12 PST @ 1.2.2.2 log @Pull up following revision(s) (requested by agc in ticket #322): doc/roadmaps/networking: revision 1.6 doc/roadmaps/storage: revision 1.4 doc/roadmaps/system: revision 1.5 doc/roadmaps/virtualization: revision 1.3 Various updates to the roadmaps for features we are looking to develop over the next few years @ text @d1 1 a1 1 $NetBSD: storage,v 1.2.2.1 2009/01/26 05:15:53 snj Exp $ a35 1 We'll continue to update this roadmap as features and dates get firmed up. @ 1.1 log @Add roadmap files, outlining the directions, projects and rough indicative timescales for new development within the networking storage system virtualization More roadmaps will be forthcoming. The dates in these documents may well change, and are provided for guidance on relative, not absolute, timescales. @ text @d1 1 a1 1 $NetBSD$ d76 1 a76 1 in March 2008. @ 1.1.8.1 log @file storage was added on branch mjf-devfs2 on 2008-10-05 20:11:18 +0000 @ text @d1 126 @ 1.1.8.2 log @Sync with HEAD. @ text @a0 126 $NetBSD: storage,v 1.1.8.1 2008/10/05 20:11:18 mjf Exp $ NetBSD Storage Roadmap ====================== This is a small roadmap document, and deals with the storage and file systems side of the operating system. NetBSD 5.0 will ship with the following storage elements in place: 1. puffs/putter 2. ReFUSE 3. rump 4. RAIDframe 5. iSCSI target 6. iSCSI initiator 7. cgd 8. fss The following elements and projects are pencilled in for 5.0, but please do not rely on them being there. 9. pud 10. devfs 11. journalling functionality for ffs 12. logical volume management 13. a native port of Sun's ZFS 14. ReFUSE-lowlevel 15. web-based management tools for storage subsystems 16. support for flash devices - NAND and MMC/SD 17. read/write support for UDF file systems We are working on the following elements, and expect them to be in 6.0: 18. OSD (object storage device) 19. basic FCIP support We expect to branch for the 5.0 release in April or May 2008, which would put a NetBSD 5.0 Release date in Q4 2008. An annual release cycle would thus mean that 6.0 would be branched in April or May 2009. Pictorially, this looks like: 2008 2009 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug |===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===| | ------- 5.0 --------- | | ------- 6.0 branch release branch 1-8 11,16 9,10,12,13,14,17 15 18 19 We'll continue to update this roadmap as features and dates get firmed up. Some explanations ================= 10. devfs --------- Devfs will allow device special files (the files used to access devices) to be created dynamically as and when they are attached to the system. This will greatly reduce the number of files in a /dev directory and removes the need to run the MAKEDEV script when support for new devices is added to the NetBSD kernel. NetBSD's devfs implementation will also allow multiple instances of the file system to be mounted simultaneously, which is very useful for chroot jails. Responsible: mjf 11. Journalling Functionality for FFS ------------------------------------- Contributed by Wasabi Systems, Inc, technical review on tech-kern in March 2008, merged to HEAD in July 2008, will be in NetBSD 5.0. 12. Logical Volume Management ----------------------------- Based on the Linux lvm2 and devmapper software, with a new kernel component for NetBSD written. Responsible: haad, martin 13. Native port of Sun's ZFS ---------------------------- Mostly completed by ad@@, this is the FreeBSD port of Sun's ZFS, with modifications to make it compile on NetBSD 5.0 by ad@@, and based on the original Sun code for the block layer, rather than the GEOM-based layer. Responsible: oster, agc 14. ReFUSE-lowlevel ------------------- FUSE has two interfaces, the normal high-level one, and a lower-level interface which is closer to the way standard file systems operate. This adds the low-level functionality in the same way that ReFUSE adds the high-level functionality Responsible: pooka, agc 15. Web-based Management tools for Storage Subsystems ----------------------------------------------------- Standard tools for managing the storage subsystems that NetBSD provides, using a standard web-server as the basic user interface on the storage device, allowing remote management by a standard web browser. Responsible: agc 16. OSD ------- Based on the T10 specification, and the Intel reference code. An Object Storage Device, where some of the functionality of a file system is placed in the storage device. Responsible: agc Alistair Crooks Sun Mar 2 23:31:03 GMT 2008 @ 1.1.10.1 log @Sync with wrstuden-revivesa-base-2. @ text @d1 1 a1 1 $NetBSD: storage,v 1.1 2008/03/19 20:12:53 agc Exp $ d76 1 a76 1 in March 2008, merged to HEAD in July 2008, will be in NetBSD 5.0. @ 1.1.4.1 log @file storage was added on branch keiichi-mipv6 on 2008-03-24 07:14:40 +0000 @ text @d1 126 @ 1.1.4.2 log @sync with head. @ text @a0 126 $NetBSD: storage,v 1.1 2008/03/19 20:12:53 agc Exp $ NetBSD Storage Roadmap ====================== This is a small roadmap document, and deals with the storage and file systems side of the operating system. NetBSD 5.0 will ship with the following storage elements in place: 1. puffs/putter 2. ReFUSE 3. rump 4. RAIDframe 5. iSCSI target 6. iSCSI initiator 7. cgd 8. fss The following elements and projects are pencilled in for 5.0, but please do not rely on them being there. 9. pud 10. devfs 11. journalling functionality for ffs 12. logical volume management 13. a native port of Sun's ZFS 14. ReFUSE-lowlevel 15. web-based management tools for storage subsystems 16. support for flash devices - NAND and MMC/SD 17. read/write support for UDF file systems We are working on the following elements, and expect them to be in 6.0: 18. OSD (object storage device) 19. basic FCIP support We expect to branch for the 5.0 release in April or May 2008, which would put a NetBSD 5.0 Release date in Q4 2008. An annual release cycle would thus mean that 6.0 would be branched in April or May 2009. Pictorially, this looks like: 2008 2009 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug |===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===| | ------- 5.0 --------- | | ------- 6.0 branch release branch 1-8 11,16 9,10,12,13,14,17 15 18 19 We'll continue to update this roadmap as features and dates get firmed up. Some explanations ================= 10. devfs --------- Devfs will allow device special files (the files used to access devices) to be created dynamically as and when they are attached to the system. This will greatly reduce the number of files in a /dev directory and removes the need to run the MAKEDEV script when support for new devices is added to the NetBSD kernel. NetBSD's devfs implementation will also allow multiple instances of the file system to be mounted simultaneously, which is very useful for chroot jails. Responsible: mjf 11. Journalling Functionality for FFS ------------------------------------- Contributed by Wasabi Systems, Inc, technical review on tech-kern in March 2008. 12. Logical Volume Management ----------------------------- Based on the Linux lvm2 and devmapper software, with a new kernel component for NetBSD written. Responsible: haad, martin 13. Native port of Sun's ZFS ---------------------------- Mostly completed by ad@@, this is the FreeBSD port of Sun's ZFS, with modifications to make it compile on NetBSD 5.0 by ad@@, and based on the original Sun code for the block layer, rather than the GEOM-based layer. Responsible: oster, agc 14. ReFUSE-lowlevel ------------------- FUSE has two interfaces, the normal high-level one, and a lower-level interface which is closer to the way standard file systems operate. This adds the low-level functionality in the same way that ReFUSE adds the high-level functionality Responsible: pooka, agc 15. Web-based Management tools for Storage Subsystems ----------------------------------------------------- Standard tools for managing the storage subsystems that NetBSD provides, using a standard web-server as the basic user interface on the storage device, allowing remote management by a standard web browser. Responsible: agc 16. OSD ------- Based on the T10 specification, and the Intel reference code. An Object Storage Device, where some of the functionality of a file system is placed in the storage device. Responsible: agc Alistair Crooks Sun Mar 2 23:31:03 GMT 2008 @ 1.1.2.1 log @file storage was added on branch matt-armv6 on 2008-03-23 00:23:07 +0000 @ text @d1 126 @ 1.1.2.2 log @sync with HEAD @ text @a0 126 $NetBSD: storage,v 1.1 2008/03/19 20:12:53 agc Exp $ NetBSD Storage Roadmap ====================== This is a small roadmap document, and deals with the storage and file systems side of the operating system. NetBSD 5.0 will ship with the following storage elements in place: 1. puffs/putter 2. ReFUSE 3. rump 4. RAIDframe 5. iSCSI target 6. iSCSI initiator 7. cgd 8. fss The following elements and projects are pencilled in for 5.0, but please do not rely on them being there. 9. pud 10. devfs 11. journalling functionality for ffs 12. logical volume management 13. a native port of Sun's ZFS 14. ReFUSE-lowlevel 15. web-based management tools for storage subsystems 16. support for flash devices - NAND and MMC/SD 17. read/write support for UDF file systems We are working on the following elements, and expect them to be in 6.0: 18. OSD (object storage device) 19. basic FCIP support We expect to branch for the 5.0 release in April or May 2008, which would put a NetBSD 5.0 Release date in Q4 2008. An annual release cycle would thus mean that 6.0 would be branched in April or May 2009. Pictorially, this looks like: 2008 2009 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug |===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===|===| | ------- 5.0 --------- | | ------- 6.0 branch release branch 1-8 11,16 9,10,12,13,14,17 15 18 19 We'll continue to update this roadmap as features and dates get firmed up. Some explanations ================= 10. devfs --------- Devfs will allow device special files (the files used to access devices) to be created dynamically as and when they are attached to the system. This will greatly reduce the number of files in a /dev directory and removes the need to run the MAKEDEV script when support for new devices is added to the NetBSD kernel. NetBSD's devfs implementation will also allow multiple instances of the file system to be mounted simultaneously, which is very useful for chroot jails. Responsible: mjf 11. Journalling Functionality for FFS ------------------------------------- Contributed by Wasabi Systems, Inc, technical review on tech-kern in March 2008. 12. Logical Volume Management ----------------------------- Based on the Linux lvm2 and devmapper software, with a new kernel component for NetBSD written. Responsible: haad, martin 13. Native port of Sun's ZFS ---------------------------- Mostly completed by ad@@, this is the FreeBSD port of Sun's ZFS, with modifications to make it compile on NetBSD 5.0 by ad@@, and based on the original Sun code for the block layer, rather than the GEOM-based layer. Responsible: oster, agc 14. ReFUSE-lowlevel ------------------- FUSE has two interfaces, the normal high-level one, and a lower-level interface which is closer to the way standard file systems operate. This adds the low-level functionality in the same way that ReFUSE adds the high-level functionality Responsible: pooka, agc 15. Web-based Management tools for Storage Subsystems ----------------------------------------------------- Standard tools for managing the storage subsystems that NetBSD provides, using a standard web-server as the basic user interface on the storage device, allowing remote management by a standard web browser. Responsible: agc 16. OSD ------- Based on the T10 specification, and the Intel reference code. An Object Storage Device, where some of the functionality of a file system is placed in the storage device. Responsible: agc Alistair Crooks Sun Mar 2 23:31:03 GMT 2008 @