0

We're having issue with a RAID-1 (mirrored) setup when replacing disks. Our current setup has two 1TB disks nearing end-of-life and we wanted to replaced them with two other 1TB disks.

The issue is that the two old 1To disks contains about 953GiB, while the two new 1TB disks contains about 931GiB. Now, mdadm can tolerate a 1% difference between disk size, but the difference is about 22GiB and is therefore too much. So when we try to do the replacement, we get the error message:

Problem: partition X is too big for the disk.

Where X is the number of the partition in question.

Ok, fine, we'll work on shrinking partitions and stuff to make it work. Feasible, but long and not fun.

But my question is:

How much should we have partitioned the disk in the first place to avoid this issue?

Since what we bought were 1TB disks, should we limit ourselves to a 931GiB partition, since :

1,000,000,000,000 / 1024 / 1024 / 1024 = 931.32 GiB

I mean, it was nice to get 953GiB when buying the old 1To disk, but should we limit ourselves to 931GiB to avoid this issue?

Or should we limit ourselves further, for instance to 920GiB, just in case?

Are there any "best practices" documented somewhere on how much space we should reserve in a RAID-1 disk to avoid the "partition too big" issue we're having now?

Edit: replaced Go with GB, and then GB with GiB where relevant.

1
  • 1
    Ah, I'm french, so we used the 'o' for "octets" instead of the 'B' for "bytes". You are right that it is not standard, sorry!
    – leftcursor
    Commented Dec 14, 2022 at 17:36

2 Answers 2

2

AFAIK while it's not exactly mandated by anybody, most 1TB/To HDD/SSD drives (SD cards and thumb drives have a different story) on the market should give you no less than 931GiB (for most of the time, the G / "G-something" you see on a system screen refers to GiB, except when you use parted; even GB / Go on Windows actually refers to GiB).

The 931GiB capacity originates from the IDEMA formula (PDF link to the LBA1-03 document / page the contains the link):

(97,696,368 + 1,953,504 * (1,000 – 50)) * 512 Bytes = 1,000,204,886,016 Bytes

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: 2360 NVME
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
...

(It's a WD SN550 behind the scene / an enclosure.)

(For AF 4Kn drive, the corresponding formula in the document gives an LBA count that in turn gives exactly the same capacity in Bytes when multiplied with 4096 instead.)

1,000,204,886,016 Bytes / 1024 / 1024 / 1024 > 931GiB

But as you see in the document, the formula is supposed to give 0.02% more than what is advertised, so I think legally speaking (I mean, if you country / region has relavant "consumer law" or so that protects your right on this kind of thing), a vendor only has to make sure that a 1TB/To drive provides no less than 1,000,000,000,000 Bytes.

I have no idea why sometimes a vendor is so "generous" that some of the models have more than what the IDEMA formula mandates. (Yeah I've seen an "OEM model" from WD give 953GiB while non-OEM ones all seem to give 931GiB.)

EDIT: the other answer has made me realize that the 953GiB capacity exists probably because the drive is advertised as 1024GB (note: NOT the same as thing 1TiB) instead of 1000GB as signified with 1TB/To.

(12,212,046 + 244,188 * (1024 – 50)) * 4096 Bytes = 1,024,209,543,168 Bytes

$ sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 250051158 sectors
Disk model: WDC PC SN730 SDBPNTY-1T00-1101
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
...

EDIT: Sometimes whether 1TB/To refers to 1000GB or 1024GB would by indicated by the capacities of the lower capacity sub-models. For example, I can see in here that SN730 has 256GB and 512GB sub-models, while SN550 has 250GB and 500GB ones instead. (The page of SN550 is gone but the one of SN570 can be seen as a reference.)

1
  • You made me check the datasheet and you are right. One is a 1024GB (and therefore 953GiB) model, and the other is a 1000GB (and therefore 931GiB) model. It's advertised as 1TB everywhere, but for one table on the last page. Devil's in the details, it seems... but thanks for the help!
    – leftcursor
    Commented Dec 16, 2022 at 18:28
2

931GB usable is the most common size, and the minimum advertisable one trillion bytes due to the math you've already looked at.

Some manufacturers sell 1,024,000,000,000 byte drives as 1TB instead, which translates to the other common size you got, 953GB:

1,024,000,000,000 / 1024 / 1024 / 1024 = 953.67 GB

There are other larger possible sizes, due to SSD overprovisioning being more common, but you usually have to enable it to be usable from the manufacturer's software

I would at least recommend using a rounded number like 930GB, since you can have really slight sizing problems when dealing with other situations like multiple partitions or larger block sizes

2
  • Thanks! That explains where the 953GB comes from. But do you know if there are documented practices anywhere? Surely a big corp like IBM or Microsoft have recommended practices for partition allocation on SSD disks, no?
    – leftcursor
    Commented Dec 14, 2022 at 17:57
  • 1
    @leftcursor Not that I've seen, it's just a resource to pull from. The only time you really run into issues is when you're trying to copy entire partitions like this. More normal use cases are either use the same make/model of drive across your array (more for performance reasons than size), or you abstract away partition sizing/raid altogether with something like lvm
    – Cpt.Whale
    Commented Dec 14, 2022 at 18:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .