Comment by adwn | Hacker News Reader

Comment by adwn | Hacker News Reader

Parent Full thread

> Nowhere else in the computer is the base-10 version standard

Well, you're simply wrong. CPU frequency is measured in GHz, that is 1,000,000,000 Hz, not 1,073,741,824 Hz. Consequently, my CPU has a nominal frequency of 3.0 GHz, not 2.793967724 GHz. Since frequencies are denominated in powers of 10, bandwidths are as well: The L1 cache in my CPU can read 64 bytes/cycle (I think), so it has a read-bandwidth of 192 GB/s, that is 192,000,000,000 B/s. My Ethernet device can transfer 1 Gbit/s, that is 1,000,000,000 bit/s, because it's clocked at 125 MHz (that's 125,000,000 Hz) and transfers 8 bit per clock cycle.

> all basic data types (bytes, ints, floats, pointers, SIMD registers, whatever) are sized to powers of 2

Yeah, and it pretty much ends with basic data types. Most of my structs aren't powers of two in size, even though their individual elements are 1, 2, 4, or 8 bytes in size. Almost none of my files have sizes related to powers of two. My SSD has a size of 931.51339 GiB – so tell me again how powers of two are more correct or more useful here?

> Almost none of my files have sizes related to powers of two.

They are all rounded up to 512 or 4096 bytes by your filesystem.

> My SSD

SSDs operate using erase blocks sized in mebibytes, and expose sector sizes of 512 B or 4096 B to the OS. [1] HDDs a similarly low-level-formatted with 512 or 4096 B sector sizes.

[1] https://spdk.io/doc/ssd_internals.html

> They are all rounded up to 512 or 4096 bytes by your filesystem.

Not always. Some filesystems allow small files to be compacted into other structures: the MTF can hold small in NTFS, ext* and btrfs support similar inlining of data in inodes for small files, other filesystems (ZFS, Reiser, btrfs again) support more general sub-block allocation (with techniques such as tail packing or block sub-division). Sometimes this is only for small files not “oddly” sized larger files, but things like tail packing can apply to the latter too.

> They are all rounded up to 512 or 4096 bytes by your filesystem.

That's an implementation detail, and neither I nor my programs care about it. We do care about the actual length of the file, which isn't related to powers of two, except in niche cases.

> SSDs operate using erase blocks sized in mebibytes, and expose sector sizes of 512 B or 4096 B to the OS.

While true, this is also an implementation detail, and I don't think about the size of my SSD in multiples of sectors or pages or kibibytes – "976762584 kiB" just isn't a useful number for me, but "1000.2 GB" is manageable. Specifying it as "931.51 GiB" isn't more correct, so it makes sense to default to powers of 10 instead of powers of 2.

The situation would be different if HDDs and SSDs always or typically had exact sizes like 512*2^30 (= 512 GiB) or 3*2^40 (= 3 TiB) – you know, like RAM – in which case using powers of 2 would make sense. But that's not the world we're living in.

> The situation would be different if HDDs and SSDs always or typically had exact sizes

I just checked two of three SSDs available to me. Two were exact multiples of power-of-two gigabytes -- 200 GiB, 120 GiB. One was 500.3 GB.

SI units might be more useful to a consumer (and I am not arguing they aren't). But the argument that storage systems have "nothing to do" with powers of two is not valid.

HDD sizes are set by manufacturers according to the IDEMA "LBA Count for Disk Drives Standard"[0] formula:

  LBA_count = 97696368 + 1953504 * (Reported_Capacity_in_GBytes - 50)

So, for 120 GB HDD:

  (97696368 + 1953504 * 70) * 512 / 1024^3 = 111.79 GiB
  (97696368 + 1953504 * 70) * 512 / 1000^3 = 120.03 GB

For 200 GB HDD:

  (97696368 + 1953504 * 150) * 512 / 1024^3 = 186.31 GiB
  (97696368 + 1953504 * 150) * 512 / 1000^3 = 200.05 GB

For 500 GB HDD:

  (97696368 + 1953504 * 450) * 512 / 1024^3 = 465.76 GiB
  (97696368 + 1953504 * 450) * 512 / 1000^3 = 500.11 GB

Doesn't look like powers of 2 at all. Are you sure about your sizes?

[0] http://www.idema.org/wp-content/downloads/2169.pdf

Logical Block Addresses were simple back when all blocks were 512 bytes. Now we have 520 (T10-PI), 4096, etc, so your math falls apart.

For disks with sectors of 4096 bytes, the formula is the same except the constants are accordingly 8 times smaller.

Regarding sectors of 520 bytes, usable bytes are still 512. Quote from the above referenced document:

> HDDs formatted with T10 PI (Protection Information) have 8 bytes added to the end of each sector. However, the user usable sector size will remain at 512 bytes or 4096 bytes. The 8 bytes of PI will increase the overhead of the disk sector density similar to overhead of ECC bytes in a given sector.

Reply on news.ycombinator.com