Ah yes...now it makes sense! :) The current 'word of caution' (about increased I/O load on block devices), seems mild IMHO. Maybe we should we have a stricter warning...something like enabling this option might be harmful to the life of your block device (due to excessive writes) and will also lead to reduced performance? HTH, -mandeep On Fri, Dec 18, 2015 at 2:12 PM, Raymond Jennings <shentino@xxxxxxxxx> wrote: > On Fri, Dec 18, 2015 at 10:50 AM, Mandeep Sandhu > <mandeepsandhu.chd@xxxxxxxxx> wrote: >> >> You've removed the strictatime option altogether. So how does that >> satisfy people who _do_ want it? > > > ...actually it looks like I was an idiot and got my diff backwards when I > pulled it out of git :P > > Here's the correct version. > > diff --git a/fs/Kconfig b/fs/Kconfig > index 6ce72d8..4b917eb 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -4,6 +4,17 @@ > > menu "File systems" > > +config DEFAULT_STRICTATIME > + bool "Use strictatime by default" > + default n > + help > + Use strictatime as a default mount option. > + > + Strictatime preserves ancient historic behavior of keeping the > atime field always up to date. > + However, it was changed in 2007 to relatime to reduce I/O load on > block devices. > + > + If unsure, say N. > + > # Use unaligned word dcache accesses > config DCACHE_WORD_ACCESS > bool > diff --git a/fs/namespace.c b/fs/namespace.c > index 0570729..48e7c15 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -2680,9 +2680,15 @@ long do_mount(const char *dev_name, const char __user > *dir_name, > if (retval) > goto dput_out; > > - /* Default to relatime unless overriden */ > +#ifdef CONFIG_DEFAULT_STRICTATIME > + /* Default to strictatime unless overridden */ > + if (flags & MS_RELATIME) > + mnt_flags |= MNT_RELATIME; > +#else > + /* Default to relatime unless overridden */ > if (!(flags & MS_NOATIME)) > mnt_flags |= MNT_RELATIME; > +#endif > > > /* Separate the per-mountpoint flags */ > if (flags & MS_NOSUID) > > > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies