[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS,
Seth Goldberg <=