Currently, there's no generic HW flush management support in kernel.
Only 7 filesystems have their own way to manage the barrier flag.
This patch adds MS_BARRIER in sb_flags and conditionnaly issues the flush
in generic_file_fsync.
That option would be enabled from userspace mount tool.
(-As discussed with Jan, we could add barrier/no barrier in older filesystems
but this would mix both filesystem and vfs barrier terminology plus
generic_file_fsync does not have access to FS sbi.
-Some modern FS will be involved as well ; eg no journal ext4 partitions.
)
Cc: Jan Kara <j...@suse.cz>
Cc: linux-fsde...@vger.kernel.org
Suggested-by: Jan Kara <j...@suse.cz>
Reviewed-by: Jan Kara <j...@suse.cz>
Signed-off-by: Fabian Frederick <f...@skynet.be>
---
fs/libfs.c | 7 +++++++
include/uapi/linux/fs.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/fs/libfs.c b/fs/libfs.c
index a184424..21983d9 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -3,6 +3,7 @@
* Library for filesystems writers.
*/
+#include <linux/blkdev.h>
#include <linux/export.h>
#include <linux/pagemap.h>
#include <linux/slab.h>
@@ -952,6 +953,12 @@ int generic_file_fsync(struct file *file, loff_t start,
loff_t end,
err = sync_inode_metadata(inode, 1);
if (ret == 0)
ret = err;
+ if (inode->i_sb->s_flags & MS_BARRIER) {
+ err = blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
+ if (ret == 0)
+ ret = err;
+ }
+
out:
mutex_unlock(&inode->i_mutex);
return ret;
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index ca1a11b..7c14ebd 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -89,6 +89,7 @@ struct inodes_stat_t {
#define MS_KERNMOUNT (1<<22) /* this is a kern_mount call */
#define MS_I_VERSION (1<<23) /* Update inode I_version field */
#define MS_STRICTATIME (1<<24) /* Always perform atime updates */
+#define MS_BARRIER (1<<25) /* Flush data during sync operations */
/* These sb flags are internal to the kernel */
#define MS_NOSEC (1<<28)
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
