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? -- Ed -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
