grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS


From: Seth Goldberg
Subject: Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS
Date: Tue, 3 Aug 2010 18:12:26 -0700 (PDT)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)

Hi,

Quoting Robert Millan, who wrote the following on Sat, 31 Jul 2010:

2010/7/30, Seth Goldberg <address@hidden>:

  You need to ensure that the deivce given isn't degraded.  It's certainly
possible to boot with a mirrored root with one device degraded.  If you
choose
that device for grub-setup, you may fail to write to it or you may succeed,
but something else may prevent it from being accessible on boot.

I don't think this is the appropiate place for this kind of sanity check. Keep in mind "grub-probe -t device" has many purposes, and for some of them (e.g. determining the partmap) the ZFS status is irrelevant.

Hmm. I do see your point here, but then I'd ask how you plan to handle ensuring that all disks in a mirror are properly updated with boot/core. I think the proper thing would be either to have grub-probe output a set of devices, onto which grub-setup would iterate and install boot/core, or implement an abstraction that allows that to happen behind the scenes. How does this work for lvm or other raids?


Another codepath (e.g. "grub-probe -t fs") includes this kind of functionality;
it verifies that the requested file will later be readable by GRUB (and IIRC
compares the result).  I think this kind of verification would be
suitable there,
but then, maybe the notion that GRUB can correctly read the file (regardless
on array degradation) is enough.

That may be true, because the zfs code in GRUB already recognizes the state of a mirrored device in a root pool (and refuses to read from it if it's marked degraded).


As for grub-setup, I haven't studied this use case, as I don't currently plan on
implementing it myself, at least not yet (I'm happy with filesystem-agnostic
grub-setup for now).

As it is today, for Legacy GRUB, we handle this by explicitly iterating on the set of devices in a mirror. If a device in a mirror is replaced, a script is executed that causes grub to be installed (via the Solaris installgrub command) on the newly-added device.

The question is: should GRUB2's installation be implicit or explicit for all members of a mirrored root pool when grub-setup is invoked.

 --S



reply via email to

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