Re: Testing devices for discard support properly

[Ric Wheeler <ricwheeler@gmail.com>]

(stripped out the html junk, resending)

On 5/8/19 1:25 PM, Martin K. Petersen wrote:
>>> WRITE SAME also has an ANCHOR flag which provides a use case we
>>> currently don't have fallocate plumbing for: Allocating blocks without
>>> caring about their contents. I.e. the blocks described by the I/O are
>>> locked down to prevent ENOSPC for future writes.
>> Thanks for that detail! Sounds like ANCHOR in this case exposes
>> whatever data is there (similar I suppose to normal block device
>> behavior without discard for unused space)? Seems like it would be
>> useful for virtually provisioned devices (enterprise arrays or
>> something like dm-thin targets) more than normal SSD's?
> It is typically used to pin down important areas to ensure one doesn't
> get ENOSPC when writing journal or metadata. However, these are
> typically the areas that we deliberately zero to ensure predictable
> results. So I think the only case where anchoring makes much sense is on
> devices that do zero detection and thus wouldn't actually provision N
> blocks full of zeroes.

This behavior at the block layer might also be interesting for something 
like the VDO device (compression/dedup make it near impossible to 
predict how much space is really there since it is content specific). 
Might be useful as a way to hint to VDO about how to give users a 
promise of "at least this much" space? If the content is good for 
compression or dedup, you would get more, but never see less.

Ric