From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: ZFS on Debian GNU/kFreeBSD
Date: Wed, 28 Jul 2010 17:38:23 +0300 [thread overview]
Message-ID: <4C5040DF.7070707@gmail.com> (raw)
In-Reply-To: <AANLkTik6RrDUPXuGbQeOusge_AJntOBzNuuisNDHoGM5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]
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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
next prev parent reply other threads:[~2010-07-28 14:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 11:22 ZFS on Debian GNU/kFreeBSD Tuco
2010-07-21 21:53 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-07-21 21:56 ` Seth Goldberg
2010-07-22 17:07 ` Robert Millan
2010-07-22 18:25 ` Seth Goldberg
2010-07-23 11:21 ` Robert Millan
2010-07-23 20:26 ` Seth Goldberg
2010-07-23 11:53 ` Robert Millan
2010-07-23 20:30 ` Seth Goldberg
2010-07-28 14:38 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-07-28 15:31 ` Robert Millan
2010-07-23 11:34 ` Robert Millan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5040DF.7070707@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.