A very long time ago when I was at Sun we struggled with this. Sun added something called the 'translucent file system' among other things. There was briefly a thought of changing stat so that it would report "data" being held by the file (all of the things written to it), "extents" of the file (all of the blocks it was taking up on disk), and "size" which accounted for partial blocks and was backwards compatible, and "flags" which included "encrypted" (yes/no), "sparse" (yes/no), "fixed" (yes/no), and at least one and possibly others that I can't remember. It served to illustrate how complex the question of file systems had become beyond the original "SAM" and "ISAM" methods from mainframes. It was either Guy Harris or Jon Livesey who pointed out that checking a damaged version of a file system with all of those capabilities as first class attributes was probably not NP complete. :-).

>However, it does leave us with no way of finding out the logical block size, which we may care about for various reasons

There's SEEK_HOLE and fiemap ioctl.

Many years ago I looked after a Novell cluster of three hosts with a rather expensive FC connected array. So what - that's pretty normal?

It was the early noughties and a TB was expensive. I wrote a spreadsheet with inputs from the Novell .ocx jobbies. The files were stored on some Novell NSS volu.mes.

I was able to show all states of the files and aggregate stats too.

Nowadays a disc is massive and worrying about compression is daft

Going back to the old days, CP/M had at least or actually one size - the number of blocks allocated to the file - managing the actual useful storage was the job of the application using the file. Though I must admit that CP/M was hardly an OS.

Isn't that true of almost all operating systems? Isn't that why Windows Explorer has "Size" and "Size on disk" as well?

Lots of filesystems in multiple operating systems have had compression for a long time...