OpenZFS?
The ZFS bits in NetBSD seem old, and it also seems that they don't quite 100% work. Now, it seems OpenZFS is the locus of ZFS activity, and that's how FreeBSD's ZFS code is maintained: http://open-zfs.org/wiki/Main_Page Thus, it seems that it would be good to extend OpenZFS to support NetBSD (or extend NetBSD's glue code to support OpenZFS), and to have recent OpenZFS code in NetBSD's src/external. I have put this notion in the "Finish ZFS" project page: https://wiki.netbsd.org/projects/project/zfs/?updated I am curious if anyone who understands ZFS better has opinions on whether my notion of heading to OpenZFS makes sense, and how hard it is likely to be. -- Greg Troxel pgpt_7XjbsCzk.pgp Description: PGP signature
Re: OpenZFS?
On Sun, Dec 28, 2014 at 7:52 PM, Greg Troxel wrote: > > The ZFS bits in NetBSD seem old, and it also seems that they don't quite > 100% work. > > Now, it seems OpenZFS is the locus of ZFS activity, and that's how > FreeBSD's ZFS code is maintained: > > http://open-zfs.org/wiki/Main_Page > > Thus, it seems that it would be good to extend OpenZFS to support NetBSD > (or extend NetBSD's glue code to support OpenZFS), and to have recent > OpenZFS code in NetBSD's src/external. > > I have put this notion in the "Finish ZFS" project page: > > https://wiki.netbsd.org/projects/project/zfs/?updated > > I am curious if anyone who understands ZFS better has opinions on whether > my notion of heading to OpenZFS makes sense, and how hard it is likely > to be. That is definitely the way to go. It is extend NetBSD to support OpenZFS - OpenZFS does not really have a core repo. FreeBSD is the closest, plus the existing NetBSD glue. It all builds on rump, so you can work in userspace, might be easiest to start on a FreeBSD system to cross check. The OpenZFS community is pretty friendly. Justin
disk driver interface
Currently NetBSD has three programming interfaces to determine disk geometry from userland. - ioctl DIOCGDINFO. The traditional interface, limited to 32bit numbers or disks < 2TB because its data structure corresponds to the binary on-disk structure. - the "get-properties" command to the drvctl(4) driver. drvctl(4) is missing on some ports and some disk drivers don't make geometry properties available. - ioctl DIOCGWEDGEINFO. Works only for wedges but not for the disk drivers themselves. This is fine for operations on data blocks of a wedge but doesn't help e.g. partitioning tools. It also does not provide the sector size. To solve this, we could - create a new DIOCGDINFO version that uses larger numbers. AFAIK that is about what OpenBSD does. The on-disk structure could be translated but writing a label might be incompatible if partitions are defined beyond the 2TB limit. - make drvctl(4) mandatory and make all disk drivers provide geometry properties. - make DIOCGWEDGEINFO available for the disk drivers and ignore wedge-related information. - import FreeBSD DIOCGMEDIASIZE (and DIOCGSECTORSIZE) ioctls. Comments? -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
