Re: [patch] Add support for barriers to blk{back,front} drivers.

[Gerd Hoffmann <kraxel@suse.de>]

Ian Pratt wrote:
> What's the current logic for determining whether the backend advertises
> barrier support, and whether the frontend chooses to use it?

Backend:  "feature-barrier" node in xenstore.  It means the backend
understands the new BLKIF_OP_WRITE_BARRIER operation.  The node can be
either 1 or 0, depending on whenever the underlying block device
actually supports barriers or not.  Initially it is '1' unconditionally,
the only way to figure whenever the underlying block device supports
barriers is to actually submit one and see if it works.  If a barrier
write fails with -EOPNOTSUPP the backend changes the node to '0'.

The error is also propagated to the frontend so it knows barriers don't
work (and can in turn propagate that up to the filesystem driver), the
new BLKIF_RSP_EOPNOTSUPP error code is needed for that.

Frontend:  It simply submits barrier writes ;)  The backend takes care
that the new error code is used for barrier writes only (it should never
ever happen for normal writes anyway), so old frontends which don't know
about barriers (and thus never submit barrier write requests) should
never ever see the new error code.

> I guess the backend could always advertise it providing it did the
> appropriate queue drain whenever it encoutered one if the underlying
> block device didn't support barriers.

The filesystems do some best-effort handling when barrier are not
available anyway (which works ok for the non-write caching case).  IMO
the best way to handle non-working barriers is to simply let the
filesystems know, which is exactly what the patch implements:  It passes
through the capabilities of the underlying block device to the domU
instead of trying to fake something which isn't there.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg