Re: Testing devices for discard support properly

[Dave Chinner <david@fromorbit.com>]

On Wed, May 08, 2019 at 10:29:17PM -0400, Martin K. Petersen wrote:
> 
> Dave,
> 
> >> > 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.
> >
> > So WRITE_SAME (0) with an ANCHOR flag does not return zeroes on
> > subsequent reads? i.e. it is effectively
> > fallocate(FALLOC_FL_NO_HIDE_STALE) preallocation semantics?
> 
> The answer is that it depends. It can return zeroes or a device-specific
> initialization pattern (oh joy).

So they ignore the "write zeroes" part of the command?

And the standards allow that?

> > For many use cases cases we actually want zeroed space to be
> > guaranteed so we don't expose stale data from previous device use into
> > the new user's visibility - can that be done with WRITE_SAME and the
> > ANCHOR flag?
> 
> That's just a regular zeroout.
> 
> We have:
> 
>    Allocate and zero:	FALLOC_FL_ZERO_RANGE
>    Deallocate and zero:	FALLOC_FL_PUNCH_HOLE
>    Deallocate:		FALLOC_FL_PUNCH_HOLE | FALLOC_FL_NO_HIDE_STALE
> but are missing:
> 
>    Allocate:		FALLOC_FL_ZERO_RANGE | FALLOC_FL_NO_HIDE_STALE

So we've defined the fallocate flags to have /completely/ different
behaviour on block devices to filesystems.

<sigh>

We excel at screwing up APIs, don't we?

I give up, we've piled the shit too high on this one to dig it out
now....

-Dave.
-- 
Dave Chinner
david@fromorbit.com