On 06/23/2015 06:44 PM, 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.
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?
Great!! good idea to me.
And we can also do the other changes to match mainstream
file-systems, if necessary, in similar way in future.
Yang
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
