Thread refresh

Dave Anderson @danderson@hachyderm.io
replies: #2 #4

Basic commandline tools never cease to surprise me it seems.

Today's surprise: by default, `du` reports the amount of bytes a file consumes on disk, not its apparent size as shown by `ls` (aka the amount of bytes you can read out of that file). To get apparent sizes, you need to `--apparent-size`, or use the shorthand `-b` (which also forces the block size to 1 byte, which shouldn't matter).

Brought to you by "why are the Unicode 16.0 data files 30MiB standalone, but 80MiB when I tar them up?"

Dave Anderson @danderson@hachyderm.io
in reply to #1 - replies: #3

Turns out because I used `du -sh` to get the total size of the standalone files, and `ls -lh` for the size of the tar file. And this machine uses ZFS, with transparent compression. So, `du` was reporting post-compression sizes.

And yes, dear reply guys, I know, "hur hur it's in the name it's disk usage not disk apparent size". It's easy to see the subtlety there once you know about it, piss off.

Anyway, as filesystems with transparent compression happen more, maybe this'll help someone else.

furicle @furicle@mastodon.social

@danderson it's the space consumed by snapshots that keeps tripping me up :-).
du and others don't reflect that correctly, you have to use zfs -o space.

@lillian
in reply to #1 - replies: #5

@danderson I've only ever used `du` to find what was using up a bunch of my disk. curious how you ended up using it to view file sizes

Ölbaum @oscherler@tooting.ch

@lillian It’s the go-to tool as soon as you have more than one file in a folder. I don’t know why you’re surprised. @danderson