Re: [PATCH 2/2] Make relatime default

[Bill Davidsen]

Andrea Arcangeli wrote:
> On Thu, Mar 26, 2009 at 06:48:38PM +0000, Alan Cox wrote:
> > On Thu, 26 Mar 2009 17:53:14 +0000
> > Matthew Garrett <mjg@xxxxxxxxxx> wrote:
> >
> > > Change the default behaviour of the kernel to use relatime for all
> > > filesystems. This can be overridden with the "strictatime" mount
> > > option.
> > NAK this again
>
> NAK but because if we change the default it is better to change it to
> the real thing: noatime.
>
> I think this can be solved in userland but perhaps changing this in
> kernel would be a stronger message that atime is officially
> obsoleted. (and nothing will break, not even mutt users will notice,
> and if they really do it won't be anything more than aesthetical)
This makes the assumption that atime is not used, which may be true on your 
system but isn't on others. I regularly move data between faster and slower 
storage based on atime, and promote reactivated projects to something faster, 
while retiring inactive project data elsewhere. Other admins use it to identify 
unused files which are candidates for backup to offline media or the bit bucket.

Let people who want that behavior specify it for existing filesystems, if you 
want to remove functionality from ext4 or btrfs or some thing place where people 
have no existing expectations, I still think it's wrong, but I couldn't say I 
think it might break anything.

I did a patch a few years ago which only updated atime on open and write, and 
that worked about as well as relatime, the inode update on open is cheap, the 
head is already there, and it was only slightly slower than noatime. The were no 
programs which kept files open for days and just read them. The the only storage 
hierarchy was "slow and cheap." ;-)

--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/