Re: Testing devices for discard support properly

[Ric Wheeler <ricwheeler@gmail.com>]

On 5/9/19 12:02 PM, Bryan Gurney wrote:
> On Wed, May 8, 2019 at 2:12 PM Ric Wheeler <ricwheeler@gmail.com> wrote:
>>
>> (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.
>>
> 
> In the case of VDO, writing zeroed blocks will not consume space, due
> to the zero block elimination in VDO.  However, that also means that
> it won't "reserve" space, either.  The WRITE SAME command with the
> ANCHOR flag is SCSI, so it won't apply to a bio-based device.
> 
> Space savings also results in a write of N blocks having a fair chance
> of the end result ultimately using "less than N" blocks, depending on
> how much space savings can be achieved.  Likewise, a discard of N
> blocks has a chance of reclaiming "less than N" blocks.
> 

Are there other API's that let you allocate a minimum set of physical 
blocks to a VDO device?

Thanks!

Ric