quoted

       Oh, I almost forgot.  It may be of notable mention an array with

a

quoted

1.0 superblock can be read as if it were an ordinary partition.  This

means

quoted

one can build a 1.0 superblock array containing a file system (ext2 may

be

quoted

the best choice in this case), but boot from the partition just as if it
were not an array.  Once the system is booted, the array can be

assembled

quoted

and then /boot can be mounted.  This is because:

1.  The 1.0 superblock is at the *END* of the array.

2.  The file system when created only uses up the front part of the
partition, leaving the superblock intact.

3.  GRUB does not require the file system to be mounted in order to read

the

quoted

kernel and the initrd.  (Actually, it could be made to work even if it

did

quoted

mount the partition, but since it does not, it makes it much easier.)

       Indeed, this is the only way of which I know to boot to an array
using GRUB legacy.

Actually that is of interest. If there's a way to use a single RAID
boot partition by itself once in awhile then there's value there if
something has gone wrong and you're just trying to get the machine up
and running.

	Well, of course a basic RAID1 array can be assembled with only one
member present, but yes, a RAID1 member partition with a 1.0 superblock can
be safely read (but not written!) as if it were an ordinary partition.  If
one has an unassembled RAID1 array comprised of 3 partitions, say /dev/sda1,
/dev/sdb1, and /dev/sdc1, one can simply mount /dev/sdb1 like any other
formatted partition.  Neither the OS nor the file system will be aware the
mount point is anything but a partially filled partition.  Of course, one
does not ordinarily wish to write to the partition which is so mounted
(mounting as read-only is a good idea), since doing so will de-sync the
array, and chances are the data would be lost when the array is
re-assembled, anyway.

--
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