On 9/5/2014 07:18, Richard Zimmerman wrote: > > Until I read this thread, I've never heard of building RAIDs on bare > metal drives. I'm assuming no partition table, just a disk label? I don't know what you mean by a disk label. BSD uses that term for their alternative to MBR and GPT partition tables, but I think you must mean something else. In Linux terms, we're talking about /dev/sda, rather than /dev/sda1, for example. > What is the advantage of doing this? The whole idea of a RAID is that you're going to take a bunch of member disks and combine them into a larger entity. On top of *that* you may wish to create partitions, LVMs, or whatever. So the real question is, why do you believe you need to make each RAID member a *partition* on a disk, instead of just take over the entire disk? Unless you're going to do something insane like: /dev/md0 /dev/sda1 /dev/sdb1 /dev/md1 /dev/sda2 /dev/sdb2 ...you're not going to get any direct utility from composing a RAID from partitions on the RAID member drives. (Why "insane?" Because now any I/O to /dev/md1 interferes with I/O to /dev/md0, because you only have two head assemblies, so you've wiped out the speed advantages you get from RAID-0 or -1.) There are ancillary benefits, like the fact that a RAID element that spans the entire partition is inherently 4k-aligned. When there is a partition table taking space at the start of the first cylinder, you have to leave the rest of that cylinder unused in order to get back into 4k alignment. The only downside I saw in this thread is that when you pull such a disk out of a Linux software RAID and put it into another machine, you don't see a clear Linux partition table, so you might think it is an empty drive. But the same thing is true of a hardware RAID member, too.