Add new patches for the next merge window
[ext4-patch-queue.git] / fs_only_call_sync_filesystem_when_remounting_read-only
blob6d5f97780e1be6e67ac194f67bbd70257bff8de9
1 fs: only call sync_filesystem() when remounting read-only
3 Currently "mount -o remount" always implies an syncfs() on the file
4 system.  This can cause a problem if a workload calls "mount -o
5 remount" many, many times while concurrent I/O is happening:
7    http://article.gmane.org/gmane.comp.file-systems.ext4/42876
9 Whether it would ever be sane for a workload to call "mount -o
10 remount" gazillions of times when they are effectively no-ops, it
11 seems stupid for a remount to imply an fsync().
13 It's possible that there is some file system which is relying on the
14 implied fsync(), but that's arguably broken, since aside for the
15 remount read-only case, there's nothing that will prevent other writes
16 from sneaking in between the sync_filesystem() and the call to
17 sb->s_op->remount_fs().
19 Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
20 ---
21  fs/super.c | 3 +--
22  1 file changed, 1 insertion(+), 2 deletions(-)
24 diff --git a/fs/super.c b/fs/super.c
25 index 80d5cf2..0fc87ac 100644
26 --- a/fs/super.c
27 +++ b/fs/super.c
28 @@ -717,10 +717,9 @@ int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
29                         if (retval)
30                                 return retval;
31                 }
32 +               sync_filesystem(sb);
33         }
35 -       sync_filesystem(sb);
37         if (sb->s_op->remount_fs) {
38                 retval = sb->s_op->remount_fs(sb, &flags, data);
39                 if (retval) {