Setting plug can merge adjacent IOs before dispatching IOs to the disk
driver.
Without plug, it'd not be a problem for single disk usecases, but for
multiple disks using raid profile, a large IO can be split to several
IOs of stripe length, and plug can be helpful to bring them together
for each disk so that we can save several disk access.
Moreover, fsync issues synchronous writes, so plug can really take
effect.
Signed-off-by: Liu Bo
---
v2: Explain why setting plug makes sense.
fs/btrfs/file.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index e43da6c..504e96d 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2018,10 +2018,20 @@ int btrfs_release_file(struct inode *inode, struct file
*filp)
static int start_ordered_ops(struct inode *inode, loff_t start, loff_t end)
{
int ret;
+ struct blk_plug plug;
+ /*
+* This is only called in fsync, which would do synchronous
+* writes, so a plug can merge adjacent IOs as much as
+* possible. Esp. in case of multiple disks using raid
+* profile, a large IO can be split to several segments of
+* stripe length(64K).
+*/
+ blk_start_plug();
atomic_inc(_I(inode)->sync_writers);
ret = btrfs_fdatawrite_range(inode, start, end);
atomic_dec(_I(inode)->sync_writers);
+ blk_finish_plug();
return ret;
}
--
2.9.4
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html