psusi at cfl.rr.com
Thu Sep 13 22:59:34 BST 2007
Scott James Remnant wrote:
> Yeah, there's no way to tell LVM or MDADM that "hey, I have this block
> device, don't scan just add the knowledge about this device to your
> existing knowledge".
> Which, if we could do that, would centralise the logic in udev about
> which devices were for LVM or MDADM, etc.
Exactly. In fact, I would prefer to have udevdb keep track of what type
and the id of the volume to which the device belongs rather than the
tool, then when a new disk is added which belongs to the same volume,
pass both devices to the tool and ask it to try and activate the volume
using those devices.
> The problem is that you don't ever find out that you need the parameter.
> You boot your server, it boots degraded after three minutes; how do you
> know that it needed a longer bootdelay? That's a "fail to worst case
> scenario" solution. Failing to boot at all does have the advantage that
> you *know* you need to change something.
Yes, but you may not be ABLE to change something if it is unattended and
won't boot up. At least if it boots degraded, it is available for you
to remotely admin and mdadm should email you that it is running
degraded, and automatically try to rebuild using a hot spare if
available. Then you can remotely start offlining unimportant services,
tell users you will be going down, start backing up, mail the datacenter
a new drive and ask them to replace it, etc.
If the server is attended, then the admin will see it sitting there
beeping and saying it can't find the last drive, and if he thinks
there's nothing wrong with the drive but it just takes a while, he can
hit a key to tell it to keep waiting.
More information about the ubuntu-devel