All of lore.kernel.org
 help / color / mirror / Atom feed
From: jiangyiwen <jiangyiwen@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
	Ron Minnich <rminnich@sandia.gov>,
	Latchesar Ionkov <lucho@ionkov.net>,
	<linux-kernel@vger.kernel.org>,
	<v9fs-developer@lists.sourceforge.net>,
	Greg Kurz <groug@kaod.org>
Subject: Re: [V9fs-developer] [PATCH] fs/9p: don't set SB_NOATIME by default
Date: Wed, 28 Mar 2018 09:14:12 +0800	[thread overview]
Message-ID: <5ABAEC64.1060003@huawei.com> (raw)
In-Reply-To: <20180327161529.f7d22a36ffc92dc1a3e15d92@linux-foundation.org>

On 2018/3/28 7:15, Andrew Morton wrote:
> On Tue, 27 Mar 2018 09:50:47 +0800 jiangyiwen <jiangyiwen@huawei.com> 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.
> 
> .
> 

  reply	other threads:[~2018-03-28  1:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27  1:50 [V9fs-developer] [PATCH] fs/9p: don't set SB_NOATIME by default jiangyiwen
2018-03-27 23:15 ` Andrew Morton
2018-03-28  1:14   ` jiangyiwen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-02-09  6:13 jiangyiwen
2018-02-09  6:13 ` jiangyiwen
2018-02-24  2:47 ` jiangyiwen
2018-02-24  2:47   ` jiangyiwen
2018-02-26  1:34   ` jiangyiwen
2018-02-26  1:34     ` jiangyiwen
2018-02-26  5:28     ` Bo YU
2018-02-26  5:28       ` Bo YU

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ABAEC64.1060003@huawei.com \
    --to=jiangyiwen@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=ericvh@gmail.com \
    --cc=groug@kaod.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=rminnich@sandia.gov \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.