[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [patch] Add support for barriers to blk{back,front} drivers.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |