Mouse <mo...@rodents-montreal.org> writes: >> Agreed about devices, but fdiscard is a filesystem operation. > > It is both, according to the manpage. Or, more precisely, it is two > operations, using the same syscall and distinguishing which is to be > done based on what the file descriptor is open onto. One is the > mostly-defined[%] filesystem operation, which you get if the fd is > connected to plain file; the other is the partially-undefined device > operation, which you get if the fd is connected to a disk device. (If > you want to argue that they should be distinct calls, I might agree > with you, though I would be inclined to make the filesystem operation > new operation to fcntl instead of a new syscall.)
Ah, I totally failed to understand that. The man page needs to yell more loudly that there are two operations overloaded depending on type of operand, with two very different meanings of "discard". I see it now. > [%] The manpage does note that it fdiscard may drop less than > requested; knowing precisely what it will do depends on knowing the > filesystem block size (and whether the file is on a filesystem that > supports discarding). I did understand that part. > You seem to be lifting the undefined-data language from the "when used > on a device" paragraph and taking it asd applying to also the "when > used on a filesystem file" case. Yes, because either I'm bad at reading or the manpage isn't loud enough about semantics that don't make sense (the blurring of "make hole" and "allow read to return arbitrary data") and hence are easily misread. It is not lost on me that the disk-level discard is about telling the fs that is the disk (a zvol :-) that it can deallocate the actual disk blocks from virtual disk. But still. > (1) Not really UB. Just returning undefined data. (UB could include > things such as scribbling on other parts of the disk.) Fair point. We agree on what I meant; I was being sloppy in terminology. Thus, whether fdiscard(2) on a file results in a later disk-level discard operation is entirely unspecified, and that's ok. I have arrived at thinking that a sensible project scope is fs-level discard, only. A separate project would be a full examine/maybe-implement/maybe-redo of TRIM, both via fdiscard on block devices and integrated into all the filesystems. Obviously needs examine step first!
