> The semantics of fdiscard(2) are a bit messy, with TRIM and undefined > contents.
The messy bits apply only when discarding space on a device, as I read the (9.1) manpage. I suspect that's because that's how devices work: dropped blocks return, essentially, whatever the implementation finds most convenient. Requiring anything else would mean it simply couldn't work on existing devices. > That's surprising to me, as I see telling the hardware that blocks > are no longer needed seems separable from a file no longer > referencing those blocks. Conceptually, so do I. But, on a device with a filesystem on it, when discarding part of a file, the blocks are no longer used, so they might as well be discarded; when discarding blocks, they'd better no longer be part of a file. So tying them together makes at least some sense when discarding space in a filesystem file. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
