Re: [PATCH v2 3/3] doc: Add alternate trim/zero limits

[Wouter Verhelst <w@uter.be>]

On Thu, Mar 29, 2018 at 01:40:35PM -0500, Eric Blake wrote:
> On 03/29/2018 10:52 AM, Wouter Verhelst wrote:
> > On Wed, Mar 28, 2018 at 02:35:02PM -0500, Eric Blake wrote:
> > > We may also want to consider an extension where a server can advertise
> > > whether a successful TRIM guarantees a reads-as-zero effect (this behavior
> > > is not required of a generic server, but may be useful to exploit when a
> > > client knows that a specific server supports it).
> > 
> > Isn't that why we specified WRITE_ZEROES in a way that it could
> > optionally also have the effect that TRIM was meant for?
> 
> Indeed, we specified WRITE_ZEROES to be permitted to take advantage of TRIM
> semantics unless the user passes a flag that requests explicit allocation
> rather than punching a hole; although that's also relatively weak (the
> client can choose whether to avoid a trim, but cannot guarantee a trim, as
> it is optional whether the server translates a write zeroes into a trim
> based on guarantees about trim behavior).  At any rate, without a specific
> use case of where KNOWING what trim can do and why it is different from what
> WRITE_ZEROES is permitted to do, I'm not going to propose an extension at
> this time.

I'm seeing WRITE_ZEROES and TRIM as two related commands:
- WRITE_ZEROES MUST read back as zeroes, MAY drop the allocation (unless
  the request specified otherwise with the relevant flag)
- TRIM MAY read back as zeroes, MUST drop the allocation where supported

If someone wants a guarantee that something reads back as zeroes and
that allocation has been removed where supported, there's nothing
stopping them from issueing a WRITE_ZEROES (with trim allowed) followed
by a TRIM. That should be reasonably cheap in all but unusual cases[1], and
would ensure the TRIM in the unusual case, too.

[1] An implementation might support TRIM but not want to do it because
    actually writing zeroes is cheaper than trimming, and therefore its
    WRITE_ZEROES does not actually trim anything. In this
    implementation, doing a TRIM before a WRITE_ZEROES might reallocate
    things though, so hence the ordering.
    In other cases, a TRIM of a region that has already been zeroed with
    "may trim" should be an almost no-op, so issuing a WRITE_ZEROES
    followed (after completion of that command) by a TRIM should not
    have any measurable effect.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab