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:10:36 +0800 [thread overview]
Message-ID: <55780D1C.6080907@cn.fujitsu.com> (raw)
In-Reply-To: <1433928078.14092.1.camel@sauron.fi.intel.com>
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.
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.
>
> .
>
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:10:36 +0800 [thread overview]
Message-ID: <55780D1C.6080907@cn.fujitsu.com> (raw)
In-Reply-To: <1433928078.14092.1.camel@sauron.fi.intel.com>
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.
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.
>
> .
>
next prev parent reply other threads:[~2015-06-10 10:15 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 [this message]
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
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=55780D1C.6080907@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.