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. So if you are the user, would not you find this confusing and inconsistent? I would. How about this alternative: we preserve current behavior, but we introduce a compile-time configuration option which enables atime support _and_ changes the default behavior to match the behavior of the mainstream file-systems. Or to put it differently. 1. We introduce the UBIFS_ATIME_SUPPORT configuration option. This option will be off by default. 3. If UBIFS_ATIME_SUPPORT is off, users get the current (legacy) behavior. Atime is not supported. The atime/noatime/relatime/lazyatime mount options are ignored. 4. If UBIFS_ATIME_SUPPORT is on, UBIFS supports atime by default. I.e.: -o - full atime support -o atime - full atime support -o noatime - no atime support We may also print a fat big warning from the mount function about the fact that atime support is enabled. Just in case a legacy user enabled this option. How does this sound to you? Artem. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html