lkml.org 
[lkml]   [2004]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: "Enhanced" MD code avaible for review
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans