[pkg-cryptsetup-devel] Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

[Guilhem Moulin]

Hi Michal,

On Tue, 03 Jul 2018 at 18:23:12 +0200, Michal Humpula wrote:
> Entry in /proc/mounts for ZFS is different as it refers to the actual ZFS 
> filesystem not to the devices of the underlying zpool. Which, from my point of 
> view, makes more sense. Do you see a way to export all the required 
> information in sysfs that would be acceptable by you? From top of my head, I 
> can think of something like `/sys/fs/zfs/$FS/devices` where $FS can be 
> something like `tank/my/fs`.

So $FS is what's found in /proc/mounts' first column?  For block devices
this value is not canonical (eg. /dev/mapper/xyz vs. /dev/dm-0 vs.
/dev/disks/by-uuid/$UUID vs. /dev/block/$maj:$min, etc.), but there is a
documented way to normalise it and get the corresponding sysfs
directory·ies dev/block/$maj:$min.  For “traditional” file systems it's
enough to run `stat -L -c%t:%T` and convert the values to base 10; for
btrfs (and I guess some other FS:es I'm not aware of) the list is under
/sys/fs/$FSTYPE/$UUID/devices, where $UUID is canonical and can be
obtained from /proc/mounts' first column using a generic (non
FS-specific) command.

Since ZFS doesn't expose a block device one would need another
documented way to resolve /sys/fs/zfs/$FS.  Hopefully ‘tank/my/fs’ is
unique and can't be aliased to something else, can it?  (Again for LVM,
/dev/mapper/$vgname-$lvname, /dev/dm-$n, /dev/$vgname/$lvname denote the
same device, and AFAIK whether /proc/mounts contains one or the other is
not documented.)

Do the slash characters in ‘tank/my/fs’ hint at a hierarchy, or is it a
flat string?  In the latter case it makes sense to encode the slashes as
hex-sequences (\x2f), like udev does for names under /dev/disk/by-label.
FWIW /proc/mounts encodes special characters such as tabs, linefeeds,
and spaces using octal escapes.  While it's our scripts' job and not
ZFS's to decode these, if there is any mangling under /sys/fs/zfs then
this should be documented.

> I think few other upcoming filesystems will have similar problems, e.g.
> bcachefs.

So it'd be great do expose the sysfs directories in a similar way;
thanks for bringing that up :-)

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180704/266d0551/attachment.sig>