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

Re: wait for the boot device



also sprach Marco d'Itri <md@Linux.IT> [2009.07.19.2309 +0200]:
> > Really?  So is /usr/share/initramfs-tools/scripts/local-top/mdadm
> > (from the mdadm package) wrong, or something else buggy or broken by
> > design?  I also experienced the need for udevsettle when booting from
> > LVM over partitioned multipath devices.  I thought it was the kpartx
> > invocation which I had to wait for before the lvm2 script.  I'd be
> > grateful for some advice on how to handle such cases properly.
>
> In an event driven model everything should happen as a reaction to a
> kevent, introducing a serialization point is just a workaround for a
> broken design.
> Other distributions (SuSE at least) mount file systems with udev RUN
> rules as a side effect of the relevant device appearing.

Yeah, that sounds great, and mdadm has recently grown the bits to
support that (incremental assembly). However, that does not mean
that it's ready for production use or that anyone has had the time
to really make it happen in Debian.

The Ubuntu patch is mostly useless for Debian as it's one big lump
that touches other things and introduces dependencies, and Suse did
some weird udev stuff the last time I checked.

Then there is udev, which is so contrary to my understanding of how
Unix works that it always takes me ages to get anything done with
it. Plus, udev's deprecation period wasn't very clearly communicated
either, and there are no usable docs that would make a migration
easier.

It would be good if you could help and provide something to work of.
Basically it's just calling `mdadm --incremental` for all component
devices.

But then there are things to work out:

1. use --run to start arrays as soon as possible, or only start an
array when it's completely assembled?

2. when can we assume that the arrays are ready to be started?

3. how does the rest of the operating system find out when /dev/md0
is ready to be used?

4. How do we properly deal with the device node change? What
previously was /dev/md2 with normal assembly is now /dev/md_d2?

It's not quite as easy as just deprecating udevsettle on a distro
scale.

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the truth is rarely pure and never simple. modern life would be very
 tedious if it were either, and modern literature a complete
 impossibility!"
                                                        -- oscar wilde

Attachment: digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)


Reply to: