[Soc-coordination] Status Report of ZFS on Linux Integration, Week 5

[Aron Xu]

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