> 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.)
[%] 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). 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. > I find it bizarre that a fs op whose basic semantics are: > turn this region of a file into a hole, more or less as it if were not > written > to change to > for this part of the file, either make it a [hole], or tell the > underlying device -- whatever that means -- that you are ok with > those data blocks having UB when read Two things: (1) Not really UB. Just returning undefined data. (UB could include things such as scribbling on other parts of the disk.) (2) You get the undefined-data underlying-device operation only when you use fdiscard() on a device special "file", at least based on the manpage I read. Whether those blocks are part of a file or not, that's the caller's worry - in that respect, just like any other I/O to the underlying device. I think this is, at least, reasonable. > The essence of fdicard, as I read it, is to drop those blocks from > the inode. What happens to those blocks after that is another > matter. When applied to plain file, yes. When applied to a device special pseudo-file, other semantics apply. /~\ 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
