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@xxxxxxxxxxxxx
