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

Re: Disabling atime

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).


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
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 gmail com

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