Hi Tejun,
Just a small qs about this patch.
On 09/03/2010 06:29 PM, Tejun Heo wrote:
loop implements FLUSH using fsync but was incorrectly setting its
ordered mode to DRAIN. Change it to DRAIN_FLUSH. In practice, this
doesn't change anything as loop doesn't make use of the block layer
ordered implementation.
According to Documentation/block/barrier.txt,
QUEUE_ORDERED_DRAIN
Requests are ordered by draining the request queue and cache
flushing isn't needed.
Sequence: drain => barrier
QUEUE_ORDERED_DRAIN_FLUSH
Requests are ordered by draining the request queue and both
pre-barrier and post-barrier cache flushings are needed.
Sequence: drain => preflush => barrier => postflush
And for loop device, it call fsync in barrier request. See
do_bio_filebacked in drivers/block/loop.c
bool barrier = !!(bio->bi_rw & REQ_HARDBARRIER);
struct file *file = lo->lo_backing_file;
if (barrier) {
if (unlikely(!file->f_op->fsync)) {
ret = -EOPNOTSUPP;
goto out;
}
ret = vfs_fsync(file, 0);
if (unlikely(ret)) {
ret = -EIO;
goto out;
}
}
So actually the sync is done in barrier and no extra flush is needed?
Or Do I misread the rules in barrier.txt?
Regards,
Tao
Signed-off-by: Tejun Heo<tj@xxxxxxxxxx>
---
drivers/block/loop.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index f3c636d..c3a4a2e 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -832,7 +832,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
lo->lo_queue->unplug_fn = loop_unplug;
if (!(lo_flags& LO_FLAGS_READ_ONLY)&& file->f_op->fsync)
- blk_queue_ordered(lo->lo_queue, QUEUE_ORDERED_DRAIN);
+ blk_queue_ordered(lo->lo_queue, QUEUE_ORDERED_DRAIN_FLUSH);
set_capacity(lo->lo_disk, size);
bd_set_size(bdev, size<< 9);
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
