On Thu, Mar 30, 2017 at 01:44:09PM +0200, Christoph Hellwig wrote:
> On Thu, Mar 30, 2017 at 12:06:41PM +0200, Lars Ellenberg wrote:
> > On Thu, Mar 23, 2017 at 10:33:40AM -0400, Christoph Hellwig wrote:
> > > It seems like DRBD assumes its on the wire TRIM request always zeroes data.
> > > Use that fact to implement REQ_OP_WRITE_ZEROES.
> > >
> > > XXX: will need a careful audit from the drbd team!
> >
> > Thanks, this one looks ok to me.
>
> So the DRBD protocol requires the TRIM operation to always zero?
"users" (both as in submitting entities, and people using DRBD)
expect that DRBD guarantees replicas to be identical after whatever
operations have been completed by all replicas.
Which means that for trim/discard/unmap, we can only expose that to
upper layers (or use it for internal purposes) if the operation has
a well defined, and on all backends identical, result.
Short answer: Yes.
> > The real question for me is, will the previous one (21/23)
> > return != 0 (some EOPNOTSUPP or else) to DRBD in more situations than
> > what we have now?
>
> No, blkdev_issue_zeroout should never return -EOPNOTSUPP.
>
> > Will it make an fstrim cause thinly provisioned
> > devices to suddenly be fully allocated?
>
> Not for SCSI devices. Yes for dm-thinp until it implements
> REQ_OP_WRITE_ZEROES, which will hopefully be soon.
"good enough for me" ;-)
Thanks,
Lars
