Commit 2ef6c32
committed
ext4: avoid updating the superblock on a r/o mount if not needed
This was noticed by a user who noticied that the mtime of a file
backing a loopback device was getting bumped when the loopback device
is mounted read/only. Note: This doesn't show up when doing a
loopback mount of a file directly, via "mount -o ro /tmp/foo.img
/mnt", since the loop device is set read-only when mount automatically
creates loop device. However, this is noticeable for a LUKS loop
device like this:
% cryptsetup luksOpen /tmp/foo.img test
% mount -o ro /dev/loop0 /mnt ; umount /mnt
or, if LUKS is not in use, if the user manually creates the loop
device like this:
% losetup /dev/loop0 /tmp/foo.img
% mount -o ro /dev/loop0 /mnt ; umount /mnt
The modified mtime causes rsync to do a rolling checksum scan of the
file on the local and remote side, incrementally increasing the time
to rsync the not-modified-but-touched image file.
Fixes: eee0023 ("ext4: commit super block if fs record error when journal record without error")
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/ZIauBR7YiV3rVAHL@glitch
Reported-by: Sean Greenslade <sean@seangreenslade.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>1 parent 31464ab commit 2ef6c32
1 file changed
Lines changed: 10 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
5997 | 5997 | | |
5998 | 5998 | | |
5999 | 5999 | | |
| 6000 | + | |
| 6001 | + | |
6000 | 6002 | | |
6001 | 6003 | | |
6002 | 6004 | | |
6003 | 6005 | | |
6004 | 6006 | | |
6005 | | - | |
| 6007 | + | |
| 6008 | + | |
6006 | 6009 | | |
6007 | 6010 | | |
| 6011 | + | |
| 6012 | + | |
6008 | 6013 | | |
| 6014 | + | |
6009 | 6015 | | |
6010 | 6016 | | |
| 6017 | + | |
| 6018 | + | |
6011 | 6019 | | |
6012 | | - | |
| 6020 | + | |
6013 | 6021 | | |
6014 | 6022 | | |
6015 | 6023 | | |
| |||
0 commit comments