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

[Dongsheng Yang]

On 06/25/2015 06:08 PM, Artem Bityutskiy wrote:
>
>
> On Thu, 2015-06-25 at 17:55 +0800, Dongsheng Yang wrote:
>> On 06/24/2015 08:33 AM, Dave Chinner wrote:
>>> On Tue, Jun 23, 2015 at 01:44:00PM +0300, Artem Bityutskiy wrote:
>>>> On Tue, 2015-06-23 at 17:55 +0800, Dongsheng Yang wrote:
>>>>> In short, I think force_atime to ubifs is the choice from my opinion.
>>>>
>>>> So will we end up with this:
>>>>
>>>> -o - no atime support
>>>> -o atime - no atime support
>>>> -o noatime - same, no atime support
>>>> -o force_atime - full atime support
>>>> -o relatime - relative atime support
>>>> -o lazyatime - lazy atime support
>>>
>>>> IOW, atime/noatime mount options have no effect on UBIFS. To have full
>>>> atime support - people have to use "force_atime". And then the rest of
>>>> the standard options are supported.
>>>
>>> That's the exact semantics of the standard -o strictatime option.
>>> See the mount(8) man page:
>>>
>>>          strictatime
>>> 	      Allows  to  explicitly requesting full atime updates.
>>> 	      This makes it possible for kernel to defaults to
>>> 	      relatime or noatime but still allow userspace to
>>> 	      override it. For more details about the default system
>>> 	      mount options see /proc/mounts.
>>>
>>> It's passed down to the kernel via the MS_STRICTATIME flag. All
>>> you need to do is make ubifs aware of this flag...
>>
>> Hi Dave, thanx for your suggestiong, but sorry, it's a little confusing
>> to me :(.
>
> I do not know the history, but IIUC, this is what Dave's hint translates
> to for UBIFS:
>
> -o - default behavior (no atime)
> -o atime - default behavior (no atime)
> -o noatime - default behavior (no atime)
>
> -o strictatime - full atime support
> -o relatime - relative atime support
> -o lazyatime - lazy atime support
>
> Is this logical from user's perspective? No, but this is a standard
> "hack", not an UBIFS-only "hack", so we are fine.
>
> "force_atime" that you are suggesting would be UBIFS-only hack, which is
> not as fine as a standard and documented "hack".
>
> IOW, atime/noatime are the "don't use" options, they are ignored and
> every file-system is free to use its own defaults, be that noatime or
> relatime or strictatime. If you want to tell the FS what to do, use
> strictatime/relatime/lazyatime.

Ha, okey, I believe there was some misunderstanding between us.
Yes, this is what we want:

 > -o - default behavior (no atime)
 > -o atime - default behavior (no atime)
 > -o noatime - default behavior (no atime)
 >
 > -o strictatime - full atime support
 > -o relatime - relative atime support
 > -o lazyatime - lazy atime support

That's great!! But there is a problem to implement it.
Because we can not distinguish the cases below:
 > -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:

-o - no atime support
-o atime - no atime support
-o noatime - same, no atime support
-o force_atime - default behavior (relatime currently)
-o force_atime,relatime - relative atime support
-o force_atime,strictatime - strict atime support
-o force_atime,lazyatime - lazy atime support

But I agree that introducing a UBIFS_ATIME_SUPPORT as you suggested.

Yang

>
> Does it make sense?
>
> .
>