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-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
