On 06/25/2015 06:08 PM, Artem Bityutskiy wrote:
On Thu, 2015-06-25 at 17:55 +0800, Dongsheng Yang wrote:
On 06/24/2015 08:33 AM, Dave Chinner wrote:
On Tue, Jun 23, 2015 at 01:44:00PM +0300, 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.
That's the exact semantics of the standard -o strictatime option.
See the mount(8) man page:
strictatime
Allows to explicitly requesting full atime updates.
This makes it possible for kernel to defaults to
relatime or noatime but still allow userspace to
override it. For more details about the default system
mount options see /proc/mounts.
It's passed down to the kernel via the MS_STRICTATIME flag. All
you need to do is make ubifs aware of this flag...
Hi Dave, thanx for your suggestiong, but sorry, it's a little confusing
to me :(.
I do not know the history, but IIUC, this is what Dave's hint translates
to for UBIFS:
-o - default behavior (no atime)
-o atime - default behavior (no atime)
-o noatime - default behavior (no atime)
-o strictatime - full atime support
-o relatime - relative atime support
-o lazyatime - lazy atime support
Is this logical from user's perspective? No, but this is a standard
"hack", not an UBIFS-only "hack", so we are fine.
"force_atime" that you are suggesting would be UBIFS-only hack, which is
not as fine as a standard and documented "hack".
IOW, atime/noatime are the "don't use" options, they are ignored and
every file-system is free to use its own defaults, be that noatime or
relatime or strictatime. If you want to tell the FS what to do, use
strictatime/relatime/lazyatime.
Ha, okey, I believe there was some misunderstanding between us.
Yes, this is what we want:
> -o - default behavior (no atime)
> -o atime - default behavior (no atime)
> -o noatime - default behavior (no atime)
>
> -o strictatime - full atime support
> -o relatime - relative atime support
> -o lazyatime - lazy atime support
That's great!! But there is a problem to implement it.
Because we can not distinguish the cases below:
> -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:
-o - no atime support
-o atime - no atime support
-o noatime - same, no atime support
-o force_atime - default behavior (relatime currently)
-o force_atime,relatime - relative atime support
-o force_atime,strictatime - strict atime support
-o force_atime,lazyatime - lazy atime support
But I agree that introducing a UBIFS_ATIME_SUPPORT as you suggested.
Yang
Does it make sense?
.
--
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
