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

[Artem Bityutskiy <dedekind1@gmail.com>]

On Wed, 2015-06-10 at 18:10 +0800, Dongsheng Yang wrote:
> On 06/10/2015 05:21 PM, Artem Bityutskiy wrote:
> > On Wed, 2015-06-10 at 11:16 +0800, Dongsheng Yang wrote:
> >> Therefore, I introduced a new option named as force_atime in ubifs.
> >> That's a ubifs-dependent opiton and it works as a main switch, in
> >> a higher level compared with atime and noatime. If force_atime, we
> >> support the atime-related flags. Otherwise, we don't care about all of
> >> them in flags and don't support atime anyway.
> >
> > How bad is it to just default to relatime like other file-systems do,
> > comparing to what we have now?
> 
> Ha, yes, that's a problem. I read it from wiki that the author think
> it's bad for ubifs. But I did not do a measure about it.

Since I am one of the authors, I think we were mostly looking at the
full atime support, and did not really look at relatime.

> In theory, yes, lots of writing would damage the flash. So I think
> just make it optional to user is a flexible way to do it. Even we
> want to make the default to relatime, I think it's better to keep
> the compatibility for a period and provide a force_atime to user.
> 
> When lots of users said "okey, we are mostly choosing force_atime in our
> use cases.". I believe that's a safe way to make ubifs supporting
> atime by default.

Let me make a step back. So what I hear is that the problem is that you
cannot find the original mount options. For example, when you see the
MNT_RELATIME flag, you do not know whether it was specified by the user
or it was VFS adding this flag. Is this correct?

If it is correct, then I think we need to look at a VFS-level solution.
If the above is the only problem, then I'd say that introducing a custom
"force_atime" is a work-around for VFS limitations.

Artem.