On Fri, Jun 13, 2025 at 10:16:26AM -0400, Mouse wrote: > > 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.
Indeed. > > 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. Having ffs call discard on blocks it frees is a completely different proposition. There's already code for that, although you don't want to use it (see PRs 50725 and 50726) and also it isn't very effective. SSDs want you to discard large ranges all at once, not one block at a time. -- David A. Holland dholl...@netbsd.org
