From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: <dedekind1@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org, adrian.hunter@intel.com
Subject: Re: [PATCH RESEND] ubifs: Introduce a mount option of force_atime.
Date: Wed, 10 Jun 2015 18:34:12 +0800 [thread overview]
Message-ID: <557812A4.8020409@cn.fujitsu.com> (raw)
In-Reply-To: <1433931934.14092.11.camel@sauron.fi.intel.com>
On 06/10/2015 06:25 PM, Artem Bityutskiy wrote:
> On Wed, 2015-06-10 at 18:10 +0800, Dongsheng Yang wrote:
>> On 06/10/2015 05:21 PM, Artem Bityutskiy wrote:
>>> On Wed, 2015-06-10 at 11:16 +0800, Dongsheng Yang wrote:
>>>> Therefore, I introduced a new option named as force_atime in ubifs.
>>>> That's a ubifs-dependent opiton and it works as a main switch, in
>>>> a higher level compared with atime and noatime. If force_atime, we
>>>> support the atime-related flags. Otherwise, we don't care about all of
>>>> them in flags and don't support atime anyway.
>>>
>>> How bad is it to just default to relatime like other file-systems do,
>>> comparing to what we have now?
>>
>> Ha, yes, that's a problem. I read it from wiki that the author think
>> it's bad for ubifs. But I did not do a measure about it.
>
> Since I am one of the authors, I think we were mostly looking at the
> full atime support, and did not really look at relatime.
>
>> In theory, yes, lots of writing would damage the flash. So I think
>> just make it optional to user is a flexible way to do it. Even we
>> want to make the default to relatime, I think it's better to keep
>> the compatibility for a period and provide a force_atime to user.
>>
>> When lots of users said "okey, we are mostly choosing force_atime in our
>> use cases.". I believe that's a safe way to make ubifs supporting
>> atime by default.
>
> Let me make a step back. So what I hear is that the problem is that you
> cannot find the original mount options. For example, when you see the
> MNT_RELATIME flag, you do not know whether it was specified by the user
> or it was VFS adding this flag. Is this correct?
>
> If it is correct, then I think we need to look at a VFS-level solution.
> If the above is the only problem, then I'd say that introducing a custom
> "force_atime" is a work-around for VFS limitations.
That's correct. Yes, I really want to solve it in vfs at first. But
later, just submited this patch as a Problem-solved for us. Because I
thought the force_atime would disappear when we decide to support
atime by default in future.
Besides a change in VFS would cause more discussion, after a trade-off,
I submitted this patch for ubifs. :)
But yes, there is really, at leat, a TODO entry for VFS in this
scenario I think. If you think we need to do it rather than a
work-around as what this patch did. I will think a better way
in VFS for that. :)
Thanx
Yang
>
> Artem.
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: <dedekind1@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
<linux-mtd@lists.infradead.org>, <adrian.hunter@intel.com>,
<linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RESEND] ubifs: Introduce a mount option of force_atime.
Date: Wed, 10 Jun 2015 18:34:12 +0800 [thread overview]
Message-ID: <557812A4.8020409@cn.fujitsu.com> (raw)
In-Reply-To: <1433931934.14092.11.camel@sauron.fi.intel.com>
On 06/10/2015 06:25 PM, Artem Bityutskiy wrote:
> On Wed, 2015-06-10 at 18:10 +0800, Dongsheng Yang wrote:
>> On 06/10/2015 05:21 PM, Artem Bityutskiy wrote:
>>> On Wed, 2015-06-10 at 11:16 +0800, Dongsheng Yang wrote:
>>>> Therefore, I introduced a new option named as force_atime in ubifs.
>>>> That's a ubifs-dependent opiton and it works as a main switch, in
>>>> a higher level compared with atime and noatime. If force_atime, we
>>>> support the atime-related flags. Otherwise, we don't care about all of
>>>> them in flags and don't support atime anyway.
>>>
>>> How bad is it to just default to relatime like other file-systems do,
>>> comparing to what we have now?
>>
>> Ha, yes, that's a problem. I read it from wiki that the author think
>> it's bad for ubifs. But I did not do a measure about it.
>
> Since I am one of the authors, I think we were mostly looking at the
> full atime support, and did not really look at relatime.
>
>> In theory, yes, lots of writing would damage the flash. So I think
>> just make it optional to user is a flexible way to do it. Even we
>> want to make the default to relatime, I think it's better to keep
>> the compatibility for a period and provide a force_atime to user.
>>
>> When lots of users said "okey, we are mostly choosing force_atime in our
>> use cases.". I believe that's a safe way to make ubifs supporting
>> atime by default.
>
> Let me make a step back. So what I hear is that the problem is that you
> cannot find the original mount options. For example, when you see the
> MNT_RELATIME flag, you do not know whether it was specified by the user
> or it was VFS adding this flag. Is this correct?
>
> If it is correct, then I think we need to look at a VFS-level solution.
> If the above is the only problem, then I'd say that introducing a custom
> "force_atime" is a work-around for VFS limitations.
That's correct. Yes, I really want to solve it in vfs at first. But
later, just submited this patch as a Problem-solved for us. Because I
thought the force_atime would disappear when we decide to support
atime by default in future.
Besides a change in VFS would cause more discussion, after a trade-off,
I submitted this patch for ubifs. :)
But yes, there is really, at leat, a TODO entry for VFS in this
scenario I think. If you think we need to do it rather than a
work-around as what this patch did. I will think a better way
in VFS for that. :)
Thanx
Yang
>
> Artem.
>
> .
>
next prev parent reply other threads:[~2015-06-10 10:39 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 10:07 [PATCH RESEND] ubifs: Introduce a mount option of force_atime Dongsheng Yang
2015-06-08 10:07 ` Dongsheng Yang
2015-06-08 22:35 ` Richard Weinberger
2015-06-08 22:55 ` Richard Weinberger
2015-06-09 2:57 ` Dongsheng Yang
2015-06-09 2:57 ` Dongsheng Yang
2015-06-09 3:24 ` Dongsheng Yang
2015-06-09 3:24 ` Dongsheng Yang
2015-06-09 5:00 ` Dongsheng Yang
2015-06-09 5:00 ` Dongsheng Yang
2015-06-09 5:09 ` Dongsheng Yang
2015-06-09 5:09 ` Dongsheng Yang
2015-06-09 6:36 ` Artem Bityutskiy
2015-06-09 6:36 ` Artem Bityutskiy
2015-06-09 8:02 ` Richard Weinberger
2015-06-09 8:02 ` Richard Weinberger
2015-06-10 3:16 ` Dongsheng Yang
2015-06-10 3:16 ` Dongsheng Yang
2015-06-10 9:21 ` Artem Bityutskiy
2015-06-10 9:21 ` Artem Bityutskiy
2015-06-10 10:10 ` Dongsheng Yang
2015-06-10 10:10 ` Dongsheng Yang
2015-06-10 10:25 ` Artem Bityutskiy
2015-06-10 10:25 ` Artem Bityutskiy
2015-06-10 10:34 ` Dongsheng Yang [this message]
2015-06-10 10:34 ` Dongsheng Yang
2015-06-10 11:05 ` Artem Bityutskiy
2015-06-10 11:05 ` Artem Bityutskiy
2015-06-23 9:55 ` Dongsheng Yang
2015-06-23 9:55 ` Dongsheng Yang
2015-06-23 10:44 ` Artem Bityutskiy
2015-06-23 10:44 ` Artem Bityutskiy
2015-06-23 23:49 ` Dongsheng Yang
2015-06-23 23:49 ` Dongsheng Yang
2015-06-24 0:33 ` Dave Chinner
2015-06-24 0:33 ` Dave Chinner
2015-06-24 16:04 ` Artem Bityutskiy
2015-06-24 16:04 ` Artem Bityutskiy
2015-06-25 9:55 ` Dongsheng Yang
2015-06-25 9:55 ` Dongsheng Yang
2015-06-25 10:08 ` Artem Bityutskiy
2015-06-25 10:08 ` Artem Bityutskiy
2015-06-25 10:10 ` Dongsheng Yang
2015-06-25 10:10 ` Dongsheng Yang
2015-06-25 11:28 ` Artem Bityutskiy
2015-06-25 11:28 ` Artem Bityutskiy
2015-06-26 1:17 ` Dongsheng Yang
2015-06-26 1:17 ` Dongsheng Yang
2015-06-26 7:01 ` Artem Bityutskiy
2015-06-26 7:01 ` Artem Bityutskiy
2015-06-26 7:13 ` Dongsheng Yang
2015-06-26 7:13 ` Dongsheng Yang
2015-06-26 7:43 ` Artem Bityutskiy
2015-06-26 7:43 ` Artem Bityutskiy
2015-06-26 7:52 ` Dongsheng Yang
2015-06-26 7:52 ` Dongsheng Yang
2015-06-26 8:19 ` Artem Bityutskiy
2015-06-26 8:19 ` Artem Bityutskiy
2015-06-26 8:22 ` Dongsheng Yang
2015-06-26 8:22 ` Dongsheng Yang
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=557812A4.8020409@cn.fujitsu.com \
--to=yangds.fnst@cn.fujitsu.com \
--cc=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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.