On 2018/3/28 7:15, Andrew Morton wrote: > 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'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. >> >> ... >> >> --- a/fs/9p/vfs_super.c >> +++ b/fs/9p/vfs_super.c >> @@ -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. >
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. > If correct, that sounds acceptable. > > . >
