On 06/25/2015 07:28 PM, Artem Bityutskiy wrote:
On Thu, 2015-06-25 at 18:10 +0800, Dongsheng Yang wrote:
> -o - default behavior (no atime)
> -o relatime - relative atime support
We would find both of them are MS_RELATIME set. But we
want to do different thing in these cases. So I introduced
the force_atime. Then:
Oh, do you know where exactly the default MS_RELATIME gets set?
Ha, yes, it was set in do_mount() in vfs. I mentioned this in a mail
days ago, but let me try to explain it more clearly here.
Sorry for the looong mail :(.
* The main idea here is to find a flexible way to make ubifs to support
atime:
* 1, To make atime supporting optional to user at first.
* 2, To keep the compatibility currently.
(a), the generic options in vfs:
=================generic=======================
-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
(b), My first idea about it is making ubifs support atime but
keep the default to noatime.
=================idea 1 in ubifs===============
-o - default behavior (*no atime*) <-----keep the default to *noatime*
-o atime - atime support
-o noatime - no atime support
-o relatime - relative atime support
-o strictatime - strict atime support
-o lazyatime - lazy atime support
But there are two problems to do it.
(1), we can not distinguish them:
-o - default behavior (*no atime*)
-o relatime - relative atime support
To solve it, I planed to introduce file_system_type::parse_options()
then, file system can be in charge of the standard options. I am not
sure is that acceptable to vfs guys, but it's possible way to solve it.
(2), we can not distinguish them:
-o - default behavior (*no atime*)
-o atime - atime support
This one is much difficult to solve. Because I found even in vfs,
we can not know the difference. They are made to same in userspace by
util-linux. Yes, we can solve it by introduce a MS_ATIME, but that's
meaningless to others and we have to change code in user and kernel.
So, it's unacceptable even to myself.
(c), So, I dropped the *idea 1*. And find out an idea 2.
=======================idea 2 in ubifs=======================
-o - no atime
-o atime - no atime
-o noatime - no atime
-o relatime - no atime
-o strictatime - no atime
-o lazyatime - no atime
-o force_atime - default behavior (relatime currently)
-o force_atime,atime - atime support
-o force_atime,noatime - no atime support
-o force_atime,relatime - relative atime support
-o force_atime,strictatime - strict atime support
-o force_atime,lazyatime - lazy atime support
That means, we keep a *full compatibility* backward, and provide
a force_atime option to make ubifs to work same with *generic*
by *-o force_atime,...*. It's optional to user.
force_atime works like a switch for atime supporting.
(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
I think this one is better than others, So I planed to
do the *idea 3*.
Thanx
Yang
.
--
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
