Re: Unused blocks vsd TRIM [was Re: Working on Discard for FFS]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B