On Sun, Dec 20, 2009 at 7:37 AM, Leslie Rhorer <lrhorer@xxxxxxxxxxx> wrote: >> >> 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 >> > target, and then format the RAID array, right? Or are you saying one >> should >> > 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? > >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
