Re: "Enhanced" MD code avaible for review

[Scott Long <scott_long@adaptec.com>]

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