fdisk assigns wrong partition sizes

Question

I'm trying to install linux(using a usb) on a new SSD (WD blue of 2TB, 1.8TB usable).

At the partition step I went with GPT table and these partitions:

• /boot 1GB
• /swap 4GB
• /root 60GB
• /home remaining space

The way I assigned the sizes was: default value for the first sector and +1G, +4G, +60G accordingly for the second sector.

For the last partition (/home) I choose the default value for both sectors so I would expect fdisk to assign all the remaining space (roughly 1735GB) to this last partition but to my surprise fdisk end up assigning 1.8TB to it.

I though maybe fdisk didn't calculate it right and so just to see what happens I continued with the installation till the end and then I checked the partitions sizes again using fdisk, df and lsblk, all of them gave me this same output:

• /boot 1GB
• /swap 4GB
• /root 59GB
• /home 1.8TB

So first a /root with 59GB instead of 60GB, but more importantly, why my /home partition have all the usable space of the SSD? I could understand that /root shows 59GB maybe because it got wrongly assigned some less bytes, but my /home partition shouldn't have all the usable space of the SSD assigned to it, what is happening here?

I tried it a second time deleting all partitions one by one and recreating them but the result was the same.

Is it possible to fix this? or I got a faulty SSD?

Answer 1

on a new SSD (WD blue of 2TB, 1.8TB usable)

SSDs have no such thing. If it's advertised as a "2TB" SSD, then it has 2TB usable. (Yes, there is over-provisioned space that isn't usable, but that's never included in the marketing materials – you'll only find it on the spec sheets.) Instead, the "1.8TB" most likely comes from the same capacity being counted in different units of measurement – disk space is typically advertised in SI scale (where 1T=1000×1000×1000×1000) because the numbers are larger that way, but many of the Linux tools show it in IEC scale (where 1T=1024×1024×1024×1024).

So if the SSD were exactly 2,000,000,000,000 bytes – 2TB in SI scale – then it would be "1.819TB" (sometimes denoted "TiB") in IEC scale, and that's exactly the same capacity, not any sort of reduced "usable" capacity.

$ echo 2T | numfmt --from=si
2000000000000

$ echo 2T | numfmt --from=si --to=iec --format=%.3f
1.819T

$ numfmt --to=si --format=%.1f 64424509440
64.5G

$ numfmt --to=iec-i --format=%.1f 64424509440
60.0Gi

Some tools have options to switch from one scale to another:

$ df -h /
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda3      btrfs  1.9T  948G  914G  51% /

$ df -h --si /
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda3      btrfs  2.0T  1.1T  982G  51% /

(Also, your 2,000,398,934,016 bytes is a very normal size for SSDs that are advertised as 2TB SI, although I don't know why – perhaps it's to match 2TB HDDs.)

but to my surprise fdisk end up assigning 1.8TB to it. [...] my /home partition shouldn't have all the usable space of the SSD assigned to it

It's not all the usable space; it's ~1.75TB – not exactly the same "1.8TB" of the total capacity. Your other partitions are tiny, relative to the total, so both 1.756 and 1.819 get rounded to the same 1.8.

This is what you have at the partition level:

Partition	Bytes	SI scale	IEC scale
/boot	1,073,741,824 B	~1.074 GB	1.000 GiB
– (swap)	4,294,967,296 B	~4.295 GB	4.000 GiB
/ (root)	64,424,509,440 B	~64.425 GB	60.000 GiB
/home	1,930,604,576,768 B	~1.931 TB	~1.756 TiB
entire disk	2,000,398,934,016 B	~2.001 TB	~1.820 TiB

As for "59G", at filesystem level the numbers will be slightly lower due to some space being reserved for filesystem metadata; i.e. you should not expect df (which deals with file capacity) to show exactly the same numbers as lsblk (which deals with block devices).