|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [patch] Add support for barriers to blk{back,front} driv
Hi,
> What block devices currently support barriers? I assume device mapper
> does (if the underlying devices do), but loop presumably doesn't.
ide does, sata does (at least ide also depending on disk capabilities),
lvm on top of these does too.
loop doesn't, I have a patch in the queue though:
http://www.suse.de/~kraxel/patches/kraxel-unstable-zweiblum-hg11870-quilt/loop-barrier.diff
>> 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.
Well, there is no way around that. The only way to probe this reliably
is to actually submit a barrier request to the hardware and see if they
work ok (due to some buggy drives, telling they support the required
features but grok if such a request is submitted).
There are likely cases where it is possible to figure it in advance and
avoid the "submit barrier req and see it fail" roundtrip. Havn't
investigated that. I'd prefer to have *one* code path only, if you have
two the unlikely of them tends to get much less tested ...
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
|
|
|
|
|