fs/9p: don't set SB_NOATIME by default
PATCH 1/1 fs/9p: don't set SB_NOATIME by default
User use some syscall, for example mmap(v9fs_file_mmap), it will not update atime even if user's mnt_flags without MNT_NOATIME, because v9fs default set SB_NOATIME in v9fs_set_super.
For supporting access time is updated when user mount with relatime, we should not set SB_NOATIME by default.
--- fs/9p/vfs_super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/9p/vfs_super.c +1 -1
@@ -94,7 +94,7 @@ static int v9fs_set_super(struct super_block *s, void *data)if (v9ses->cache) sb->s_bdi->ra_pages = (VM_MAX_READAHEAD *1024 )/PAGE_SIZE ; - sb->s_flags |=SB_ACTIVE |SB_DIRSYNC |SB_NOATIME ; + sb->s_flags |=SB_ACTIVE |SB_DIRSYNC ;if (!v9ses->cache) sb->s_flags |=SB_SYNCHRONOUS ;
Signature · 1 line
1.8.3.1
Quoted 12 lines · On Tue, 27 Mar 2018 09:50:47 +0800 jiangyiwen <[email protected]> wrote:
User use some syscall, for example
mmap(v9fs_file_mmap), it will not update atime even if user'smnt_flagswithoutMNT_NOATIME, because v9fs default setSB_NOATIMEinv9fs_set_super.For supporting access time is updated when user mount with relatime, we should not set
SB_NOATIMEby default....
fs/9p/vfs_super.c static int v9fs_set_super(struct super_block *s, void *data) · line 100
Quoted 8 lines
fs/9p/vfs_super.c +1
-1@@ -94,7 +94,7 @@ static int v9fs_set_super(struct super_block *s, void *data)if (v9ses->cache) sb->s_bdi->ra_pages = (VM_MAX_READAHEAD *1024 )/PAGE_SIZE ; - sb->s_flags |=SB_ACTIVE |SB_DIRSYNC |SB_NOATIME ; + sb->s_flags |=SB_ACTIVE |SB_DIRSYNC ;if (!v9ses->cache) sb->s_flags |=SB_SYNCHRONOUS ;
So strictly speaking, this is a non-backward-compatible change, yes?
Please describe the circumstances under which an existing user might be harmed by this. I *think* such harm will occur if the user was already using 'mount -o relatime', yes? They previously weren't getting relatime treatment, but now they will, and things will be a little slower.
If correct, that sounds acceptable.
Quoted 25 lines · Andrew Morton
Quoted 12 lines · On Tue, 27 Mar 2018 09:50:47 +0800 jiangyiwen <[email protected]> wrote:
User use some syscall, for example
mmap(v9fs_file_mmap), it will not update atime even if user'smnt_flagswithoutMNT_NOATIME, because v9fs default setSB_NOATIMEinv9fs_set_super.For supporting access time is updated when user mount with relatime, we should not set
SB_NOATIMEby default....
fs/9p/vfs_super.c static int v9fs_set_super(struct super_block *s, void *data) · line 100
Quoted 8 lines
fs/9p/vfs_super.c +1
-1@@ -94,7 +94,7 @@ static int v9fs_set_super(struct super_block *s, void *data)if (v9ses->cache) sb->s_bdi->ra_pages = (VM_MAX_READAHEAD *1024 )/PAGE_SIZE ; - sb->s_flags |=SB_ACTIVE |SB_DIRSYNC |SB_NOATIME ; + sb->s_flags |=SB_ACTIVE |SB_DIRSYNC ;if (!v9ses->cache) sb->s_flags |=SB_SYNCHRONOUS ;So strictly speaking, this is a non-backward-compatible change, yes?
Quoted 5 lines
Please describe the circumstances under which an existing user might be harmed by this. I *think* such harm will occur if the user was already using 'mount -o relatime', yes? They previously weren't getting relatime treatment, but now they will, and things will be a little slower.
Yes, after using this change, if user was already using 'mount -o relatime', their atime will be changed, and some operations will result in slower performance, but I think user should use 'noatime' option if they hope their file's atime is not updated and user should not depend on the internal implement.
Quoted 4 lines
If correct, that sounds acceptable.
.