lesmikesell at gmail.com
Sat Aug 11 19:50:59 UTC 2007
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.
lesmikesell at gmail.com
More information about the fedora-devel-list