On Thu, Dec 27, 2007 at 09:59:15AM +0100, Guido Guenther wrote:
> On Wed, Dec 26, 2007 at 10:34:35PM +0100, Josip Rodin wrote:
> > I suppose, although that's a much more general change that would have many
> > more consequences. How was the current priority for multipath-tools-boot
> > selected, is there a rationale for it being as high as 3 (now 4)?
> > I can't say I can see the reason offhand. I suppose you want it to be
> > before S30checkfs.sh and S35mountall.sh so that people can put multipath'd
> > drives into fstab, but why would it run as early as 3 or 4?
> It was moved that early because it had to be started _before_ udev.
> Basti was maintaining the package back then (0.4.5-2) and the changelog
> doesn't give a reason why this was done.
>
> I moved it to start _after_ udev so the /dev/mapper entries get created
> correctly on the tmpfs (0.4.7-3).
>
> We can probably move it even later in the boot process but not after LVM
> cryptdisks and mdadm which would mean [21,24] if we also want to have it
> after module-init tools. But there might very well be something earlier
> that also wants access to block devices, who knows?
There's S10checkroot.sh, but it should be safe to assume that if the system
has already booted from the root partition, multipath can't change it
anyway... right?
Strange thing is, checkroot.sh also activates the swap devices found in
/etc/fstab. I can't imagine a reason why someone would have the swap
partition(s) behind a device which requires multipath, though.
I don't think we should be missing anything, because I can't think of any
extra packages that should mess with the priority space this early (<20)
and yet need multipath. The closest are ocfs2-tools and cman, which
are at 60 in this runlevel (should be near 40, but that's another matter).
> 21 looks like a good choice but I wonder if we gain that much - you
> could always load necessary modules with
>
> modprobe <module> || treue
>
> in /etc/default/multipath-tools for your special requirements. In other
> cases an initramfs makes much more sense.
Well, supporting kernel modules isn't generally considered a special
requirement, they've been around since forever :)
/etc/modules is used for specifying which kernel modules should be loaded
at system boot time, it doesn't make sense from a maintenance standpoint
for multipath to require a separate module loading method.
Another point is the fact that the script multipath-tools-boot runs modprobe
dm-multipath by default. We are already allowing for the idea that the
multipath functionality exists as a kernel module, so there's no point in
not allowing the idea that whatever is behind the device mapper can also
be a kernel module.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
