Re: block_device usage and incorrect block writes

[Chris Frost]

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?

thanks again,
-- 
Chris Frost  |  <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
   Email chris@xxxxxxxxxxxx with the subject "retrieve pgp key"
   or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/