On 06/26/2015 03:43 PM, Artem Bityutskiy wrote:
On Fri, 2015-06-26 at 15:13 +0800, Dongsheng Yang wrote:
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.
No, I mean removing these 2 lines from do_mount()
/* Default to relatime */
mnt_flags |= MNT_RELATIME;
and add them to the
struct file_system_type->mount()
of every individual file-system (e.g., ext4_mount()).
Well, it's possible, but I don't think others would like it. Because it
create a lot of redundancy. If we want to make file_system_type to be
aware of it, I prefer to introduce a file_system_type::parse_options()
call back. Something like that:
+ if (type->parse_options)
+ type->parse_options(path, flags, mnt_flags);
+ else
+ generic_parse_options(path, flags, mnt_flags);
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
-o atime does not mean anything from the kernel POW, it is only
user-space tools which may translate it to something meaningful for the
kernel. No file-systems can distinguish these two anyway. So I would say
this is not a problem, people have to use 'strictatime' instead.
Yes, it's only used in util-linux now. But do you think it's weird that:
-o atime - no atime (we treat it as the default behavior)
-o noatime - no atime
?
Yang
What do you think about this as the alternative to the
UBIFS_ATIME_SUPPORT configuration switch, which will introduce
additional churn?
.
--
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
