Messages in this thread |  | | | Date | Sun, 21 Mar 2004 16:42:54 -0700 | | From | Scott Long <> | | Subject | Re: "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/
|  |