Disabling atime

[Les Mikesell]

Benjamin Lewis wrote:

>>>> I'd expect the RedHat-style approach to this to be: add some file
>>>> under /etc/sysconfig like mount-options that contains options that can
>>>> be merged with the ones in /etc/fstab and all of the magic
>>>> automounting bits (this is probably as important on usb flash drives
>>>> as anywhere).
>>>>
>>>> [snip]
>>>>
>>> There is something which leap out at me as soon a I saw this: the kind
>>> of person who _needs_ atime, knows how to set it.
>> Yes, just like the kind of person who _needs_ networking knows how to
>> issue ifconfig commands directly to set it up.  That doesn't mean that
>> a general purpose way to set it up with the most likely default and a
>> GUI to change it is not an improvement.
>>
> That's not a fair comparison.

Right - typos in the ifconfig commands normally won't break console 
access, where a typo in /etc/fstab will make your system unbootable.

>>> The majority of people
>>> - especially the home use - has little or no use for it whatsoever. Its
>>> a bit like the way mount fails on a broken fstab, it assumes that if you
>>> are messing with the fstab you know what you are doing. Equally anyone
>>> who _needs_ atime knows what they are doing and how to enable it.
>> Except that they may have applications currently in use that rely on
>> the decades old, documented behavior and should not have these broken
>> as a surprise.  Let one release go where you encourage people to break
>> these with their own choice and report it, then you'll know what to
>> expect when you break it with the default.
>>
> I thought this only really affected some backup applications - emphasis
> on the _some_ part,

No, backups never use atime - it tells you when someone last read a 
file, not when something changed.  Atime would be used for debugging 
(did an app read this file before crashing - or at all?) or determining 
if a file has not been read since it was written (is a mailbox/maildir 
file new/unread?), or if a file is unecessary and can be deleted since 
nothing has read it for some long interval).


> mutt and tmpwatch - both of which have patches to
> resolve their issues.

That's all anyone has found, but (a) this sounds like a top-of-the-head 
guess instead of someone grepping the whole of fedora extra source and 
(b) doesn't consider apps someone has written or obtained elsewhere that 
use the documented filesystem spec.

 > In any case, with proper release notes this would
> not be a surprise.

Do people read those?  Especially if they skip the version where the 
change is made?

>>> Any sort of fancy /etc/sysconfig trick is more effort than is needed,
>>> when the only change needed to undo it is to remove an option from the
>>> fstab.
>> atime is not the only mount option that people need to change and a
>> one-off hack for every little thing is not as nice as a general
>> purpose solution that exactly matches the approach of the gazillion
>> other things under /etc/sysconfig, put there for the same purpose.
>>
> I was referring to the amount of effort required to make an
> /etc/sysconfig switch work.

One-off hacks might be easy.  That's not a good excuse for a 
distribution used by a lot of people to do them.  Anyone who has used 
RH/fedora for any length of time is used to bits and pieces of the stock 
config files being extracted into files under /etc/sysconfig for local 
management so that would be expected in this case as well.


-- 
   Les Mikesell
    lesmikesell at gmail.com