grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ZFS on Debian GNU/kFreeBSD


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: ZFS on Debian GNU/kFreeBSD
Date: Wed, 28 Jul 2010 17:38:23 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5

On 07/23/2010 02:53 PM, Robert Millan wrote:
> 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.
>
>   
They are simply not implemented yet. When it will be you'll have to just
access any underlying device and other devices will be autoscanned.
>  - 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).
>
>   
This syntax is the one that reflects the real structure of ZFS. OS often
needs some kind of tricks which warp the reality and show it in a way
which is the best in achieving many OS goals. GRUB goals are much
simpler and such warping would only complicate the design. One example
of this is using (<DISK>)/<path> instead of mount points. It results in
more difficulty in userland tools but there we can manage complexity
easier since we have all the usual tools.
> 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.
>
>   
It was the way I originally did it but it turned out that ZFS is goot at
representing tree-like structure of subvolumes, it may have thousands of
subvolumes and snapshots. Trying to "ls" it would be useless. Handling
tree-like structure in devices is possible but probably not necessary,
just for ZFS.
> 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?
>
>   
I don't think that the design needs changes but I'm open to discussion.
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]