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

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

On 06/26/2015 03:43 PM, Artem Bityutskiy wrote:
> On Fri, 2015-06-26 at 15:13 +0800, Dongsheng Yang wrote:
>> 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.
>
> No, I mean removing these 2 lines from do_mount()
>
>        /* Default to relatime */
>        mnt_flags |= MNT_RELATIME;
>
> and add them to the
>
> struct file_system_type->mount()
>
> of every individual file-system (e.g., ext4_mount()).

  Well, it's possible, but I don't think others would like it. Because it
create a lot of redundancy. If we want to make file_system_type to be
aware of it, I prefer to introduce a file_system_type::parse_options()
call back. Something like that:

+       if (type->parse_options)
+               type->parse_options(path, flags, mnt_flags);
+       else
+               generic_parse_options(path, flags, mnt_flags);

>
>>      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
>
> -o atime does not mean anything from the kernel POW, it is only
> user-space tools which may translate it to something meaningful for the
> kernel. No file-systems can distinguish these two anyway. So I would say
> this is not a problem, people have to use 'strictatime' instead.

Yes, it's only used in util-linux now. But do you think it's weird that:
-o atime - no atime (we treat it as the default behavior)
-o noatime - no atime
?

Yang
>
> What do you think about this as the alternative to the
> UBIFS_ATIME_SUPPORT configuration switch, which will introduce
> additional churn?
>
> .
>