Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 24 Jan 2007 10:23:34 +0100 | From | Jens Axboe <> | Subject | Re: block_device usage and incorrect block writes |
| |
On Wed, Jan 24 2007, Chris Frost wrote: > On Thu, Jan 18, 2007 at 01:13:06PM +1100, Jens Axboe wrote: > > noop doesn't guarentee that IO will be queued with the device in the > > order in which they are submitted, and it definitely doesn't guarentee > > that the device will process them in the order in which they are > > dispatched. noop being FIFO basically means that it will not sort > > requests. You can still have reordering if one request gets merged with > > another, for instance. > > > > The block layer in general provides no guarentees about ordering of > > requests, unless you use barriers. So if you require ordering across a > > given write request, it needs to be a write barrier. > > Thank your explaining this aspect of the linux block device layer design. > Earlier, we tried bio barriers (hard barriers) and found the slow down > to be too great. After my previous email we looked further down the stack and > noticed that struct request also has a soft barrier option. For our tests, > soft barriers perform almost as well as no barriers, and our system > is ok (for now, at least) with the write reordering that devices can do. > > As our code calls generic_make_request(), it does not have access to the > created struct request. We have modified block/ll_rw_blk.c:__make_request() > to 1) not merge requests and to 2) add the REQ_SOFTBARRIER flag to the new > request's cmd_flags field. Is there a more modular way for a function to > create a new request with a soft barrier?
It would not be a problem to expose the soft/hard barrier difference at the bio level as well, so you have direct access to it. I think it would be quite useful in general.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |