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 ...

quoted

(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.

.