Skip to contentSkip to conversation

Any pros or cons of using full disk versus partitons?

DISCUSSION David Miller 6 participants 6 messages Apr 13, 2011 – Apr 14, 2011 1 message not in the archive MD RAID

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

From: "Matthew Tice" <[email protected]>
Date: Wed, 13 Apr 2011 13:38:39 -0600

Quoted 6 lines

So of course it technically doesn't matter but are there certain (non-apparent) repercussions for choosing one over the other? It seems to save a couple steps by using the whole disk (not having to partition) - but is that it? One thing I'm thinking about the pros of using partitions is if all your disks (or some) are different sizes - then you can set the partition sizes the same.

First, you sent this to "linux-raid-owner" instead of just "linux-raid". The former goes to me, not to the mailing list.

I've corrected it in the CC:

Second, to answer your question, for some disk label variants you risk over-writing the disk label if you use the whole device as part of your RAID volume. This definitely will happen, for example, with Sun disk labels.

#2 lore raw
Quoted 13 lines · David Miller

From: "Matthew Tice"<[email protected]>
Date: Wed, 13 Apr 2011 13:38:39 -0600

Quoted 6 lines

So of course it technically doesn't matter but are there certain (non-apparent) repercussions for choosing one over the other? It seems to save a couple steps by using the whole disk (not having to partition) - but is that it? One thing I'm thinking about the pros of using partitions is if all your disks (or some) are different sizes - then you can set the partition sizes the same.

First, you sent this to "linux-raid-owner" instead of just "linux-raid". The former goes to me, not to the mailing list.

Quoted 6 lines

I've corrected it in the CC:

Second, to answer your question, for some disk label variants you risk over-writing the disk label if you use the whole device as part of your RAID volume. This definitely will happen, for example, with Sun disk labels.

Using whole disks in the raid will make it easier for replacing disks - you don't have to worry about partitioning them. You can just plug them in and use them. If you have some sort of monitoring scripts and hot plug disks, you may be able to avoid any interaction at all on disk replacement.

On the other hand, using partitions gives you lots more flexibility. You can do things such as use a small partition on each disk to form a raid10 array for swap, while using a bigger partition for data. Or perhaps you want a very small partition on each disk as a wide raid1 mirror, for your /boot (not that you need so much safety for /boot, but that it's easier to boot from a raid1 with metadata format 0.90 than from other raid types).

#3 lore raw
Quoted 30 lines · David Brown
Quoted 17 lines · David Miller

From: "Matthew Tice"<[email protected]>
Date: Wed, 13 Apr 2011 13:38:39 -0600

Quoted 9 lines

So of course it technically doesn't matter but are there certain (non-apparent) repercussions for choosing one over the other?  It seems to
save a couple steps by using the whole disk (not having to partition) - but
is that it?  One thing I'm thinking about the pros of using partitions is if
all your disks (or some) are different sizes - then you can set the partition sizes the same.

First, you sent this to "linux-raid-owner" instead of just "linux-raid".  The former goes to me, not to the mailing list.

Quoted 6 lines

I've corrected it in the CC:

Second, to answer your question, for some disk label variants you risk over-writing the disk label if you use the whole device as part of your RAID volume.  This definitely will happen, for example, with Sun disk labels.

Using whole disks in the raid will make it easier for replacing disks - you don't have to worry about partitioning them.  You can just plug them in and use them.  If you have some sort of monitoring scripts and hot plug disks, you may be able to avoid any interaction at all on disk replacement.

Quoted 6 lines

On the other hand, using partitions gives you lots more flexibility. You can do things such as use a small partition on each disk to form a raid10 array for swap, while using a bigger partition for data.  Or perhaps you want a very small partition on each disk as a wide raid1 mirror, for your /boot (not that you need so much safety for /boot, but that it's easier to boot from a raid1 with metadata format 0.90 than from other raid types).

Just my 2 cents: I've faced problems when newer disk was smaller than old disk two or three times, so using partitions now with setting some free space at the end - something near 80 or 100 megabytes.

If your system is located on the same disks which holds useful data, it might be useful to split data into another mountpoint/block device and let system skip fs check on startup and produce booted server, which is helpful in case of system crash/powerloss and dirty fs/breaked raid. RAID assembly problems may be caused by crappy controller like lsi 1068e which was hanging the whole system and desync data writes on disks on SMART request or completely on it's own.

Quoted 7 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Signature · 6 lines
Best regards,
[COOLCOLD-RIPN]
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#4 lore raw
Quoted 37 lines · On Thu, 14 Apr 2011 11:57:47 +0400 CoolCold <[email protected]> wrote:
Quoted 30 lines · David Brown
Quoted 17 lines · David Miller

From: "Matthew Tice"<[email protected]>
Date: Wed, 13 Apr 2011 13:38:39 -0600

Quoted 9 lines

So of course it technically doesn't matter but are there certain (non-apparent) repercussions for choosing one over the other?  It seems to
save a couple steps by using the whole disk (not having to partition) - but
is that it?  One thing I'm thinking about the pros of using partitions is if
all your disks (or some) are different sizes - then you can set the partition sizes the same.

First, you sent this to "linux-raid-owner" instead of just "linux-raid".  The former goes to me, not to the mailing list.

Quoted 6 lines

I've corrected it in the CC:

Second, to answer your question, for some disk label variants you risk over-writing the disk label if you use the whole device as part of your RAID volume.  This definitely will happen, for example, with Sun disk labels.

Using whole disks in the raid will make it easier for replacing disks - you don't have to worry about partitioning them.  You can just plug them in and use them.  If you have some sort of monitoring scripts and hot plug disks, you may be able to avoid any interaction at all on disk replacement.

Quoted 6 lines

On the other hand, using partitions gives you lots more flexibility. You can do things such as use a small partition on each disk to form a raid10 array for swap, while using a bigger partition for data.  Or perhaps you want a very small partition on each disk as a wide raid1 mirror, for your /boot (not that you need so much safety for /boot, but that it's easier to boot from a raid1 with metadata format 0.90 than from other raid types).

Quoted 3 lines

Just my 2 cents: I've faced problems when newer disk was smaller than old disk two or three times, so using partitions now with setting some free space at the end - something near 80 or 100 megabytes.

You don't need partitions to do this. Just use the --size option to mdadm.

NeilBrown

Quoted 21 lines

If your system is located on the same disks which holds useful data, it might be useful to split data into another mountpoint/block device and let system skip fs check on startup and produce booted server, which is helpful in case of system crash/powerloss and dirty fs/breaked raid. RAID assembly problems may be caused by crappy controller like lsi 1068e which was hanging the whole system and desync data writes on disks on SMART request or completely on it's own.

Quoted 7 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
Quoted 5 lines · On Thu, 14 Apr 2011 18:11:59 +1000 NeilBrown <[email protected]> wrote:
Quoted 3 lines · On Thu, 14 Apr 2011 11:57:47 +0400 CoolCold <[email protected]> wrote:

Just my 2 cents: I've faced problems when newer disk was smaller than old disk two or three times, so using partitions now with setting some free space at the end - something near 80 or 100 megabytes.

There are also some Gigabyte motherboards which like to cut off a small portion of a disk at the end via HPA, and writing a backup of their BIOS there.
https://encrypted.google.com/search?q=gigabyte+bios+hpa
If you had your user data or mdadm metadata there, bad luck.

On earlier motherboards this was done automatically to every new disk on SATA0, on newer ones I think it's optional and can be disabled. But anyway, I now prefer to leave about 8 MB of space at the end of each drive unpartitioned, just in case.

And another point, again related to buggy BIOSes: some of them seem to read first sectors of all attached disks and expect to see an MBR-style partition table there; and if there's something else instead (e.g. basically random data, in case of the whole disk used for RAID), they may become confused and lock-up at boot. I had a couple of such cases where a board would lock-up at HDD detection with a certain drive attached, and would only boot up properly after it was zeroed and repartitioned.

Quoted 2 lines

You don't need partitions to do this. Just use the --size option to mdadm.

But then the 1.x+ metadata is still stored at the very end of the device, which makes it vulnerable to the HPA problem described above.

Signature · 2 lines
With respect,
Roman
#6 lore raw
Quoted 1 line · Roman Mamedov

But then the 1.x+ metadata is still stored at the very end of the device, which makes it vulnerable to the HPA problem described above.

That's why I prefer v1.2 superblocks, it's stored safely away from MBR overwrites, but still not at the end.

Quoting "man mdadm"

1, 1.0, 1.1, 1.2
Use the new version-1 format superblock. This has few restrictions. The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2).

I consider v1.0 and v1.1 as dangerous because of why you wrote, as well as accidental MBR writes.

Signature · 1 line
Mikael Abrahamsson    email: [email protected]