On Sun, Dec 20, 2009 at 7:37 AM, Leslie Rhorer [off-list ref] wrote:

quoted

quoted

quoted

Oh, and you'll also very likely want grub to read the /boot
filesystem, which is why it must be on a partition followed by the
raid header, instead of a partition containing a raid header and raid
protected partition.  That use is OK since grub operates read-only.

       I think I follow you, here.  IOW, partition the drive, create the

md

quoted

target, and then format the RAID array, right?  Or are you saying one

should

quoted

format the partition and then create the RAID array on top of it?

It works much more cleanly if you create the RAID array first, and
then use the container it provides;

       Now I definitely don't follow you.  Are you saying one should create
an array from the raw drive, partition it, format the first partition, then
create secondary arrays from the second and third partition, and finally
format the second and third array?

quoted

this way the end of your file-system does not overlap the raid super-
block.

       I can follow that - there's a danger of wiping or moving the mdadm
superblock if it is contained in the filesystem, but it seems to me
partitioning the drive and then creating the array from a partition, as I
first suggested, will accomplish that just fine.

It is an option to partition it after the fact; however generally it's
better to partition it first, and then apply whatever raid level you
like to each partition.

You misunderstand on the second half; the danger is that both the
'filesystem' and 'mdadm superblock' attempt to use the whole device.
That may appear to work for a while, but there is danger that the
filesystem could grow and store data in the same place the mdadm
superblock is; depending on if the filesystem or mdadm then filesystem
within the device was used this will either fail, or destroy the raid
information block.
--
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