[dm-devel] Re: LVM on dmraid breakage
Phillip Susi
psusi at cfl.rr.com
Fri Aug 3 18:10:02 UTC 2007
Luca Berra wrote:
> I really have no clue, fortunately dmraid is usually used for boot
> disks, so it should be started before udev has a chance of messing with
> devices. btw, md already does this, and redhat's initrd does this as
> well.
I don't know about redhat, but Ubuntu uses udev in the initramfs.
Currently the boot scripts wait for udevsettle, then run dmraid and
pvscan to search out all detected devices, then tries to mount the root
fs, but this setup is less than ideal. Our goal is to move towards full
udev plug and play, where devices are detected by the kernel, processed,
and as soon as the one(s) needed for the root have been enumerated,
mount the root fs and run-init.
> The real solution to this is so simple.
> Just ditch the partition detection code from the kernel, and move it to
> userspace where it belongs.
> For the time being use BLKPG_DEL_PARTITION, to undo what the kernel
> should not have done.
I agree with moving the partition detection code to user space, but
trying to undo it after the fact doesn't help because udev is already
processing the add events. Also you do not need to remove the
partitions so long as pvscan understands that it shouldn't be using them.
> i'd rather not see it coupled with udev :P
> maybe i am limited, but i really fail to see how an event driven model
> could be at all useful in this cases, and i am really convinced that the
> effort needed to make i work is too high compared to possible benefits.
> The biggest question being: How do you know you have scanned all
> possible PV for a given volume group, and you have to activate it.
> Anyway i still think my proposal is sensible and adapts to the current
> paradigm of lvm2.
Udev is supposed to be the new model for enumerating devices and
performing plug and play actions on them, rather than "ls /dev/hd?". To
answer your specific question, lvm would know it has enumerated all the
required pvs because the vg information tells it how many pvs are
supposed to be there so it can check the udevdb to see if they have all
been added yet. If they have, activate the vg, otherwise do nothing
until another pv is detected.
The event driven model is useful in that it allows faster boot times (
don't need to detect ALL devices before activating and mounting the root
), and allows runtime plug and play. Where does lvm store state
information right now? In conf files in /etc isn't it? Why use its own
database for that when it could just keep the information in udevdb?
Keeping the information in udevdb makes it easily available to things
like hal in gnome, which in turn allows things like desktop popups when
a mirror has a drive fail, which changes the state of the vg in udevdb,
which pushes that update to any monitoring applications. It also allows
lvm to share information such as whether or not the device is "claimed"
with other components, without those components having to be
specifically aware of lvm and mess with its conf files. Specifically,
both dmraid and mdraid ( nor any other future components ) do not have
to be taught how to edit lvm's conf files to tell it not to access the
underlying physical disks but to use the virtual devices instead.
More information about the Ataraid-list
mailing list