Re: [PATCH RESEND] ubifs: Introduce a mount option of force_atime.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux