[PATCH RESEND] ubifs: Introduce a mount option of force_atime.

[Dongsheng Yang]

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

>
> .
>