Re: "Enhanced" MD code avaible for review

[Scott Long]

Arjan van de Ven wrote:
> > With DM, what happens when your initrd gets accidentally corrupted?
>
>
> What happens if your vmlinuz accidentally gets corrupted? If your initrd
> is toast the module for your root fs doesn't load either. Duh.

The point here is to minimize points of failure.

> > What happens when the kernel and userland pieces get out of sync?
> > Maybe you are booting off of a single drive and only using DM arrays
> > for secondary storage, but maybe you're not.  If something goes wrong
> > with DM, how do you boot?
>
>
> If you loose 10 disks out of your raid array, how do you boot ?

That's a silly statement and has nothing to do with the argument.

> > Secondly, our target here is to interoperate with hardware components
> > that run outside the scope of Linux.  The HostRAID or DDF BIOS is
> > going to create an array using it's own format.  It's not going to
> > have any knowledge of DM config files, 
>
>
> DM doesn't need/use config files.
>
> > initrd, ramfs, etc.  However,
> > the end user is still going to expect to be able to seamlessly install
> > onto that newly created array, maybe move that array to another system,
> > whatever, and have it all Just Work.  Has anyone heard of a hardware
> > RAID card that requires you to run OS-specific commands in order to
> > access the arrays on it?  Of course not.  The point here is to make
> > software raid just as easy to the end user.
>
>
> And that is an easy task for distribution makers (or actually the people
> who make the initrd creation software).
>
> I'm sorry, I'm not buying your arguments and consider 100% the wrong
> direction. I'm hoping that someone with a bit more time than me will
> write the DDF device mapper target so that I can use it for my
> kernels... ;)

Well, code speaks louder than words, as this group loves to say.  I 
eagerly await your code.  Barring that, I eagerly await a technical
argument, rather than an emotional "you're wrong because I'm right"
argument.

Scott

-
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/