Can't we just agree on sizes?

[BoosterT]

This is so frustrating and it's one of the reasons I think Synology engineers need a good kick up their bums. I recently increased the storage pool for my Backup NAS. Storage Manager shows 4 — yes 4 — different numbers for the volume size. See the image below:

Is it 56.4TB? Is it 54.1 TB? Is it 57711 GB? and if you add up the usable drive sizes, it comes to about 60TB — and that's after the 10% size reduction from the stated sizes. It boggles my mind that the numbers are all different. Can someone explain what's going on? Inquiring minds would like to now
Thanks

Stephen

 

[EAZ1964]

This has nothing to do with the Synology engineers, it is a wide spread lie from the marketing divisions from the disk manufacturers plus digital versus decimal.

Terabytes, Gigabytes, & Petabytes: How Big Are They?

How big is a terabyte? How many GB in a TB? How many megabytes in a gigabyte? What's a petabyte? As crazy as it all sounds, it's easy to understand.

www.lifewire.com

 

[BoosterT]

This has nothing to do with the Synology engineers, it is a wide spread lie from the marketing divisions from the disk manufacturers plus digital versus decimal.

Terabytes, Gigabytes, & Petabytes: How Big Are They?

How big is a terabyte? How many GB in a TB? How many megabytes in a gigabyte? What's a petabyte? As crazy as it all sounds, it's easy to understand.

www.lifewire.com

That part I understand ... all are factors of 2, so a megabyte is really 1,048,576 bytes and so on ... and when a manufacturer says "16 tb drive" you have to divide by 1,099,511,627,776 ... so a 16TB drive is really 14.55 TB

But my gripe is not that ... it is the fact that the same page shows different values ... adding up the drives shows 60.1 TB which aligns with the value found on the website you gave, 16TB is really 14.55 TB, which agrees with the 14.6TB the storage pool shows.... taking 90% of that gives 54.1 TB which is what the bottom number is. But the drives ALREADY have 10% taken off for the 2s conversion. Why take another 10%? Further, the top number is 56.4 TB ... ignoring the rest, which is it: 56.4 or 54.1? Diving 57711GB by 1,048,576 gets close to 54.1 also, so I suspect that's the "right" value ... but some consistency would be appreciated.

Stephen

 

[EAZ1964]

I never really bothered for the details to be honest.
What I know is that a volume is smaller than a pool as system partition takes space, which is not available for data.
Also BTRFS takes around 6% of disk space as overhead for the file system, and that space is therefore unavailable.

The TB/GB conversion depends on the higher marketing definition of TB (decimal) or binary definition.
57711 GB = 56.36 TB (in binary), 57.7TB (in decimal)

 

[jeyare]

there are several pieces of information that cannot be mixed into an evaluation:

1. Because it is unclear from the screenshot the setup is about SHR1 RAID level + BTRFS and all are based on 3x16TB + 1x 14TB + 2x 10TB drives (RAW capacity).

2. Then DSM needs to prepare RAID building (SHR1 in your case).

3. when DSM is done - you will get total : 3x14.6TB + 1x 12.7TB + 2x 9.1TB = 74.7TB .... it is correct from single point of view. But the SHR1 algorithm changed to:
Protection capacity = defined by single 16TB RAW = 14.6TB netto
Pool capacity = defined by 2x16TB+1x14TB+2x10TB RAW = 2x16.6TB + 1x 12.7TB + 2x 9.1TB = 60.1TB of the pool capacity.

And here is the root of the problem mentioned by @BoosterT:
4. The Pool Capacity 60.1TB you need to be sliced by all necessary partitions. Then you get 56.4TiB from the max. allocated capacity. The value is right, but the TB label isn't correct..
Test:
57711GB / 1024 = 56.3584TiB rouned to 56.4TiB
they mixed binary and decimal calc into a single value.
The correct approach is:
57711GB / 1000 = 57.711TB rouned to 57.7TB
Someone should write to them, I won't write to Syno support anymore. It does not interest me.

So when the Allocated capacity is about:
57711GB = 57.71TB and not 56.4TB but 56.4TiB of allocated capacity = this is the capacity you can slice between your VOLUMES.

 

[BoosterT]

I never really bothered for the details to be honest.
What I know is that a volume is smaller than a pool as system partition takes space, which is not available for data.
Also BTRFS takes around 6% of disk space as overhead for the file system, and that space is therefore unavailable.

The TB/GB conversion depends on the higher marketing definition of TB (decimal) or binary definition.
57711 GB = 56.36 TB (in binary), 57.7TB (in decimal)

Thanks ... THAT'S what I was missing and to answer jeyare, yes, it is SHR1, and that explanation makes sense. Thank you both for providing me with the answers.

Stephen

 

[jeyare]

enjoy

Thanks to the input from your post, we learned something new:
1. The DSM7 GUI in the Storage Manager section incorrectly displays the Pool capacity in decimal (GB, TB), while the value is calculated in binary (GiB, TiB).
2. Checked in the latest version of DSM6 - displays correctly.

@BoosterT - write here the (full) number of the DSM version you are using.

 

[BoosterT]

enjoy

@BoosterT - write here the (full) number of the DSM version you are using.

DSM 7.1-42661 Update 4

 

[wckhor]

I'm so glad I found this thread. It clarifies the question I had for a long time. Thanks @BoosterT and @jeyare !