Re: "Enhanced" MD code avaible for review

[Lars Marowsky-Bree]

On 2004-03-22T14:59:29,
   Scott Long <scott_long@xxxxxxxxxxx> said:

> Ok, the technical arguments I've heard in favor of the DM approach is 
> that it reduces kernel bloat.  That fair, and I certainly agree with not
> putting the kitchen sink into the kernel.  Our position on EMD is that
> it's a special case because you want to reduce the number of failure
> modes, and that it doesn't contribute in a significant way to the kernel
> size.  Your response to that our arguments don't matter since your mind
> is already made up.  That's the barrier I'm trying to break through and
> have a techincal discussion on.

The problematic point is that the failure modes which you want to
protect against all basically amount to -EUSERTOOSTUPID (if he forgot to
update the initrd and thus basically missed a vital part of the kernel
update), or -EFUBAR (in which case even the kernel image itself won't
help you). In those cases, not even being linked into the kernel helps
you any.

All of these cases are well understood, and have been problematic in the
past already, and will fuck the user up whether he has EMD enabled or
not. That EMD is coming up is not going to help him much, because he
won't be able to mount the root filesystem w/o the filesystem module,
or without the LVM2/EVMS2 stuff etc. initrd has long been mostly
mandatory already for such scenarios.

This is the way how the kernel has been developing for a while. Your
patch does something different, and the reasons you give are not
convincing.

In particular, if EMD is going to be stacked with other stuff (ie, EMD
RAID1 on top of multipath or whatever), having the autodiscovery in the
kernel is actually cumbersome. And yes, right now you have only one
format. But bet on it, the spec will change, vendors will not 100%
adhere to it, new formats will be supported by the same code etc, and
thus the discovery logic will become bigger. Having such complexity
outside the kernel is good, and its also not time critical, because it
is only done once.


Sincerely,
    Lars Marowsky-Brée <lmb@xxxxxxx>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/