The problem I see with current zfs.mod is that it integrates with GRUB using the "filesystem model", i.e. each pool has one backend (the storage device) and one frontend (the filesystem).
But ZFS is different in both ends: each pool can use N storage devices and provide M filesystems. In the current representation this yields two problems for GRUB: - zpools where more than one device is essential (i.e. not just mirror like RAID1) aren't accessible. - To allow more more than one filesystem in a zpool, filesystems are selected in a special manner, e.g.: (hd0)/@/ (hd0)/foo@/ This collides with an assumption consistently made by GRUB utilities and scripts: that you can construct a GRUB path by combining the result of make_path_relative_to_its_root() (known at install time) with the device that contains this filesystem (usually known at run time). My impression is representing ZFS as a filesystem is doable, but not the best fit. ZFS is much more like what GRUB calls an "abstraction" (RAID or LVM). In fact if you take LVM interface: grub> ls (hd0) (hd1) grub> insmod lvm grub> ls (hd0) (hd1) (foo) (bar) the only difference for ZFS is that (foo) and (bar) are provided directly as filesystems (like pxe.mod does) instead of block devices for GRUB to probe. So my intention is to readjust zfs.mod to follow this interface. Aside from enabling multi-device pools, this will also make it much easier to support ZFS in the install utilities and scripts later. Comments / objections / suggestions? _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
