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

[Dongsheng Yang <yangds.fnst@cn.fujitsu.com>]

On 06/26/2015 03:01 PM, Artem Bityutskiy wrote:
> On Fri, 2015-06-26 at 09:17 +0800, Dongsheng Yang wrote:
...

> This means that if a file-system (e.g., UBIFS or JFFS2) never supported
> atime, it is harder to add atime support without breaking the old
> behavior.
>
> What if we push the two "set NOATIME flag" lines of code down to
> individual file-systems, instead of having it at the VFS level?

    TO be sure I understand it correctly, do you mean pushing the flags
parsing work to individual file-systems? Then we can set the default
behavior in file-system itself.

    Yes, I explained one idea about it in my last mail to introduce a
file_system_type::parse_options(). Then we can implement a callback
in ubifs to do what we want.

    But there is another problem I called as problem 2 in my last mail.
That we can not distinguish:
    -o - default behavior (*no atime*)
    -o atime - atime support
Even in vfs, we can not distinguish them. They are made to same in
userspace by utils-linux. There is an idea to solve it, introducing
a MS_ATIME. But that's too costly I think.

Yang
>
> ... snip ...
>
>> (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
>
> Yes, this is an option, I am just trying to explore other possibilities.
>
> .
>