> > Oh, I almost forgot. It may be of notable mention an array with > a > > 1.0 superblock can be read as if it were an ordinary partition. This > means > > one can build a 1.0 superblock array containing a file system (ext2 may > be > > 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 > > 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 > > kernel and the initrd. (Actually, it could be made to work even if it > did > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
