Installation on RAID-only system

Molle Bestefich molle.bestefich at gmail.com
Mon Mar 21 03:26:08 UTC 2005


> unfortunately Christophe's patch only work for linear device-mapped devs (eg. lvm2)
> and Gerte's patch only works for mirrored device-mapped devs (dmraid)
> we would nee a good mix of those two patches.

Thanks, Luca!

Perhaps it's time to try GRUB again.  Every time I've touched GRUB,
I've been burnt badly.  Seems to me it's destined to write random data
to weird places on the disk and overwrite critical structures.  Guess
there has to be a way to make GRUB behave itself though, since there
seems to be people using it :-).

*Sighs*.

I only need to tell the bootloader that this-and-that device
corresponds to BIOS device 0x80.  No remapping of sectors or any such
fancy is needed.
It's hard to believe that this is still a problem..
Not to mention that the preferred way to do this in Linux is still to
take a wild guess!!
(That goes for both GRUB and LILO, I think?)

I know that Linux does not have any guarantees wrt which order the
BIOS chooses to activate disk controllers.
I know that often, there isn't a disk-level signature in the MBR
accessible thru INT 13h / from boot loader code.
But let's make one up ourselves and save every Linux user on the
planet some pain.

Just take the first big hunk of data off each disk on bootup, using
INT 13h, and calculate a MD5.
When the kernel has finished bringing IDE drivers and device-mapper
devices up, do the same thing once again.
Compare signatures, and you've got a perfect bios<->linux drive map.

Only error situation that can occur is that you have two disks with
exactly the same signature.
That's an easy situation to handle: Bail out with an error, and leave
them out of the drive map.
Better yet, include both, so applications can see there's a problem
and present a choice to the user.

I see how there might be a potential problem with RAID1 arrays.
On some controllers, the metadata lives near the end instead of at the
disks' head, and a md5 of the first data chunk of the mirrored disks
would be identical.
Simple to solve.  Calculate the md5 based on data from both the
beginning and end of the disk.
One could even make the algorithm account for all current and future
RAID controllers with different offsets by adding a number to the
signature that indicates how many sectors the boot loader code had to
compare from the beginning and end of each disk before it had unique
signatures.  Needless to say, there should be a (perhaps adjustable)
maximum on how many sectors the boot loader would be allowed to
traverse.

What's the problem with this approach?  Why hasn't it been done yet?
I imagine I'm overlooking some major technical difficulty, or perhaps
the idea has been patented?

If you know of any prior discussion on this topic, I'd be interested
in a pointer..




More information about the Ataraid-list mailing list