On 14/09/2009, at 17.08, Ed Cashin <[email protected]> wrote:
On Mon Sep 14 05:38:23 EDT 2009, [email protected] wrote:
On Fri, Sep 11 2009, Ed Cashin wrote:
The Documentation/block/barrier.txt information seems geared toward
block device drivers that handle I/O requests from the
request_queue,
and not drivers that handle bios directly by providing their own
make_request_fn via blk_queue_make_request.
So I think the section quoted below does not apply to such a
bio-handling driver.
* Currently, no matter which ordered mode is used, there can be
only
one barrier request in progress. All I/O barriers are held off by
block layer until the previous I/O barrier is complete.
Right, that synchronization does not exist at the bio level.
The implication is that when a bio_barrier(bio) is seen by the
make_request_fn, it should sleep until any in-progress barrier bio
has
been completed. Is that correct?
Yes, that is correct.
Thanks.
It looks like interested parties like filesystems use
blkdev_issue_flush to generate a barrier, but a bio generated by
blkdev_issue_flush will always be "empty", with no associated I/O to
do.
Can a make_request_fn-style driver count on barrier bios always being
I/O operation free?
No, they usually carry data too.
--
Jens Axboe
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
