> 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
mos
> 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 op
> 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".
Agreed.
> It is not lost on me that the disk-level discard is about telling the
> fs that is the disk (a zvol :-)
Yes, if your "disk"
Mouse writes:
>> 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
Mouse 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
> mostl
Joshua Gillett writes:
> I want to inquire about working on the "Discard for FFS" project listed on
> the wiki over the next couple of months.
>
> I just finished a semester-length OS course (working on teaching operating
> system, ChickadeeOS) where I wrote block-bitmap allocators, extent-based
