From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: <dedekind1@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
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: Fri, 26 Jun 2015 09:17:31 +0800 [thread overview]
Message-ID: <558CA82B.7050306@cn.fujitsu.com> (raw)
In-Reply-To: <1435231689.9627.17.camel@sauron.fi.intel.com>
On 06/25/2015 07:28 PM, Artem Bityutskiy wrote:
> On Thu, 2015-06-25 at 18:10 +0800, Dongsheng Yang wrote:
>> > -o - default behavior (no atime)
>> > -o relatime - relative atime support
>>
>> We would find both of them are MS_RELATIME set. But we
>> want to do different thing in these cases. So I introduced
>> the force_atime. Then:
>
> Oh, do you know where exactly the default MS_RELATIME gets set?
Ha, yes, it was set in do_mount() in vfs. I mentioned this in a mail
days ago, but let me try to explain it more clearly here.
Sorry for the looong mail :(.
* The main idea here is to find a flexible way to make ubifs to support
atime:
* 1, To make atime supporting optional to user at first.
* 2, To keep the compatibility currently.
(a), the generic options in vfs:
=================generic=======================
-o - default behavior (relatime currently)
-o atime - atime support
-o noatime - no atime support
-o relatime - relative atime support
-o strictatime - strict atime support
-o lazyatime - lazy atime support
(b), My first idea about it is making ubifs support atime but
keep the default to noatime.
=================idea 1 in ubifs===============
-o - default behavior (*no atime*) <-----keep the default to *noatime*
-o atime - atime support
-o noatime - no atime support
-o relatime - relative atime support
-o strictatime - strict atime support
-o lazyatime - lazy atime support
But there are two problems to do it.
(1), we can not distinguish them:
-o - default behavior (*no atime*)
-o relatime - relative atime support
To solve it, I planed to introduce file_system_type::parse_options()
then, file system can be in charge of the standard options. I am not
sure is that acceptable to vfs guys, but it's possible way to solve it.
(2), we can not distinguish them:
-o - default behavior (*no atime*)
-o atime - atime support
This one is much difficult to solve. Because I found even in vfs,
we can not know the difference. They are made to same in userspace by
util-linux. Yes, we can solve it by introduce a MS_ATIME, but that's
meaningless to others and we have to change code in user and kernel.
So, it's unacceptable even to myself.
(c), So, I dropped the *idea 1*. And find out an idea 2.
=======================idea 2 in ubifs=======================
-o - no atime
-o atime - no atime
-o noatime - no atime
-o relatime - no atime
-o strictatime - no atime
-o lazyatime - no atime
-o force_atime - default behavior (relatime currently)
-o force_atime,atime - atime support
-o force_atime,noatime - no atime support
-o force_atime,relatime - relative atime support
-o force_atime,strictatime - strict atime support
-o force_atime,lazyatime - lazy atime support
That means, we keep a *full compatibility* backward, and provide
a force_atime option to make ubifs to work same with *generic*
by *-o force_atime,...*. It's optional to user.
force_atime works like a switch for atime supporting.
(d), But when I heard an idea about UBIFS_ATIME_SUPPORT from you.
I get an idea 3.
======================idea 3 in ubifs=========================
UBIFS_ATIME_SUPPORT is n, same with what ubifs did:
-o - no atime
-o atime - no atime
-o noatime - no atime
-o relatime - no atime
-o strictatime - no atime
-o lazyatime - no atime
UBIFS_ATIME_SUPPORT is y, same with what generic is doing:
-o - default behavior (relatime currently)
-o atime - atime support
-o noatime - no atime support
-o relatime - relative atime support
-o strictatime - strict atime support
-o lazyatime - lazy atime support
I think this one is better than others, So I planed to
do the *idea 3*.
Thanx
Yang
>
> .
>
next prev parent reply other threads:[~2015-06-26 1:22 UTC|newest]
Thread overview: 31+ 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 22:35 ` Richard Weinberger
2015-06-08 22:55 ` Richard Weinberger
2015-06-09 2:57 ` Dongsheng Yang
2015-06-09 3:24 ` Dongsheng Yang
2015-06-09 5:00 ` Dongsheng Yang
2015-06-09 5:09 ` Dongsheng Yang
2015-06-09 6:36 ` Artem Bityutskiy
2015-06-09 8:02 ` Richard Weinberger
2015-06-10 3:16 ` Dongsheng Yang
2015-06-10 9:21 ` Artem Bityutskiy
2015-06-10 10:10 ` Dongsheng Yang
2015-06-10 10:25 ` Artem Bityutskiy
2015-06-10 10:34 ` Dongsheng Yang
2015-06-10 11:05 ` Artem Bityutskiy
2015-06-23 9:55 ` Dongsheng Yang
2015-06-23 10:44 ` Artem Bityutskiy
2015-06-23 23:49 ` Dongsheng Yang
2015-06-24 0:33 ` Dave Chinner
2015-06-24 16:04 ` Artem Bityutskiy
2015-06-25 9:55 ` Dongsheng Yang
2015-06-25 10:08 ` Artem Bityutskiy
2015-06-25 10:10 ` Dongsheng Yang
2015-06-25 11:28 ` Artem Bityutskiy
2015-06-26 1:17 ` Dongsheng Yang [this message]
2015-06-26 7:01 ` Artem Bityutskiy
2015-06-26 7:13 ` Dongsheng Yang
2015-06-26 7:43 ` Artem Bityutskiy
2015-06-26 7:52 ` Dongsheng Yang
2015-06-26 8:19 ` Artem Bityutskiy
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=558CA82B.7050306@cn.fujitsu.com \
--to=yangds.fnst@cn.fujitsu.com \
--cc=adrian.hunter@intel.com \
--cc=david@fromorbit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).