RE: [Xen-devel] [patch] Add support for barriers to blk{back, front} drivers.

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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'.

What block devices currently support barriers? I assume device mapper
does (if the underlying devices do), but loop presumably doesn't. 
 
> 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.

Do you do a probe at backendd initialisation time to avoid telling the
frontend that barriers are supported and then having to tell it they are
not the first time it tries to use one? Althoug Linux may be happy with
that its not a clean interface.

It would be good if someone who know the *BSD/Solaris block stack could
offer some input here.

Thanks,
Ian

> 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@xxxxxxx>
> http://www.suse.de/~kraxel/julika-dora.jpeg
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel