Actually, the opposite is true. With regular file systems you pay with overhead for tons of features that are not used by storage nodes, starting from file ownership, all sorts of metadata like access time or custom attributes. Hard links come with a pretty big overhead, having to split directory indices from inodes, just like any other form of deduplication. And yet you still need to implement workarounds for common issues like bad performance of large directories on many file systems—in storage node’s case this would be the two-level directory structure in the blobs
directory.
I have a rough draft of a design in which I estimate only about 48 bytes per piece would have to be stored in fast, random-access storage, as opposed ~280 bytes with a default-formatted ext4 or 1kB for NTFS, while significantly reducing other I/O necessary to perform uploads/downloads/file walker. This reduction would make SSDs redundant for many setups, as this data structure would fit in RAM easily. I’d love to have more time to refine it…
Note that you still have to have a free SATA/SAS/whatever connector to use it, and a bay/mounting point. Not all setups have one.
Can you cite data on that? I’d love to see actual studies on this topic, because there’s a lot of hearsay flowing around.