Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Wed, Mar 11, 2015 at 06:09:50PM +0000, Ben Hutchings wrote:
> On Tue, 2015-03-10 at 12:47 +0100, Goswin von Brederlow wrote:
> > On Wed, Mar 04, 2015 at 09:30:24PM +0000, Ben Hutchings wrote:
> > > Thanks for your work on this bug. I ended up with a somewhat different
> > > implementation as I don't think it's necessary to duplicate the
> > > information that udev provides, and as we may now need to mount more
> > > than one filesystem. But I should have credited you in the changelog
> > > for prototyping this, and I forgot to do so.
> > >
> > > Ben.
> >
> > The idea with the udev rule was to wait up to ROOTDELAY seconds
> > without a new device apearing before giving up. Now you wait ROOTDELAY
> > seconds in total, which then can depend on the number of devices.
>
> It's now max(rootdelay, 30) because the rootdelay kernel parameter
> wasn't meant for this purpose at all.
>
> > Add new disk and you have to increase the ROOTDELAY.
>
> I hope not!
On one system the PSU isn't big enough to spin up all disks at once.
So the SCSI controler is set to not start them on power on. Instead
they come up sequentially. So one disk takes 5s, 2 disks 10s, 3 disks
15s, ... accordingly you have to set the delay. Add another disk and
the total time goes up.
> > Also it was ment so that block scripts could specifically target the
> > new devices instead of having to scan all devices every time. For
> > example say you have a crypt device and you forgot the password. Now I
> > think you will be asked 30 times for the password before the initramfs
> > gives up.
>
> True, but so far as I could see you didn't send scripts that made use of
> that. We could still implement that later, I think.
>
> And now that we potentially have to mount /usr (and possibly other
> filesystems), not just root and swap, lvm2's script needed to be told
> which device we're looking for, not which devices appeared.
>
> Ben.
That isn't realy new. Debian already had root and swap. Adding a third
doesn't realy change anything. LVM should already have known what
devices to activate for root and swap.
The problem I see there is detecting what devices to bring up. The
/usr filesystem might be in a ZPOOL that uses a crypt device on a LVM
logical volume on a raid. Or any other complex nesting. Could be any
number of devices that are needed for /usr to become available. Again
nothing new for /usr, / and swap already have that problem.
Note: LVM has persistent metadata that tell it wether to bring up a
device or not. So I'm not sure it makes much sense to guess what
devices are needed and limiting lvm to only start those. The metadata
already has this functionality and is more reliable than guessing what
devices may be needed.
MfG
Goswin
Reply to: