Hi everyone, This is the sixth report of ZFS on Linux Integration GSoC project. This week, I have continued to work on debian-installer support of ZFS on Linux, but there isn't very much interesting progress.
The thing I get stuck is still partman-zfs, particularly how to handle the fact that ZFS on Linux create its block device as /dev/zd[0-9]* while on kFreeBSD they are created as /dev/zvol/$zpool/$zvol. partman-zfs has been relying on the path name to perform many important actions, so that the problem becomes more complicated than I've expected last week. The device table is read by /bin/parted_device in partman-utils, from /proc/partitions. And I've checked with ZoL upstream that Linux kernel only allows devices to exist in the top level of /dev/, so that changing the behavior of ZoL to fit the path isn't doable. So that I did a few attempts to cheat in d-i to let it reuse the code that handles /dev/zvol/$zpool/$zvol, but none of them can help me go further than the filesystem creation step. The problem is that partman-zfs reads the probed device path, getting the names of zpool and zvol from that path, and use such info almost everywhere it needs to know $zpool and $zvol - which simply translates to "/dev/zd0" rather than something like "rpool/lv1", and apparently commands like "zfs set mountpoint=/ /dev/zd0" will fail. Upstream create a soft link for each zfs block device using udev in normal environment, but it won't help in debian-installer. An interesting thing is that partman-zfs's block device is created but not used, it only uses that path created in /dev/zvol to complete following steps No matter how many space is allocated in the dialog when creating the block device, once it's getting committed to disk the block device is first destroyed and then it create a dataset with the same name without quota definition. Resolution could be maintaining a mapping between device names and zvol names and use such mappings everywhere when $zpool and $zvol is needed. But this has risks to contain wrong information if it isn't carefully implemented to handle some rather unusual cases, such as making sure the mapping is up-to-date when the user destroys the zvol and recreate with the same name for several times. I'll be working on this next week. -- Regards, Aron Xu _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
