| Message ID | 1435302083.9627.36.camel@sauron.fi.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 ... > >> (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. > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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()). > 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. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2015-06-26 at 15:52 +0800, Dongsheng Yang wrote: > > 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 Yes, it is, and worse, this is inconsistent with other file-systems, e.g., ext4. So I think I am convinced that with UBIFS_ATIME_SUPPORT we'll end up with a better overall result. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/26/2015 04:19 PM, Artem Bityutskiy wrote: > On Fri, 2015-06-26 at 15:52 +0800, Dongsheng Yang wrote: >> >> 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 > > Yes, it is, and worse, this is inconsistent with other file-systems, > e.g., ext4. So I think I am convinced that with UBIFS_ATIME_SUPPORT > we'll end up with a better overall result. Great!! Then I will plan to do it later. Thanx for you patience on this proposal :). > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/namespace.c b/fs/namespace.c index d0659ec..f0e7530 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1920,6 +1920,9 @@ long do_mount(char *dev_name, char *dir_name, char *type_page, if (data_page) ((char *)data_page)[PAGE_SIZE - 1] = 0; + /* Default to relatime */ + mnt_flags |= MNT_RELATIME; + /* Separate the per-mountpoint flags */ if (flags & MS_NOSUID) mnt_flags |= MNT_NOSUID; @@ -1931,8 +1934,6 @@ long do_mount(char *dev_name, char *dir_name, char *type_page, mnt_flags |= MNT_NOATIME; if (flags & MS_NODIRATIME) mnt_flags |= MNT_NODIRATIME; - if (flags & MS_RELATIME) - mnt_flags |= MNT_RELATIME; if (flags & MS_STRICTATIME) mnt_flags &= ~(MNT_RELATIME | MNT_NOATIME); if (flags & MS_RDONLY)