Hi Warner, > The consensus was we'd fix it in the installer.
Isn't speaking about a "consensus", at least as a general response to the idea
of making 'noatime' the default, a little premature? I have more to say on
this topic (see below). Also, I would not dismiss Lyndon's last mail too
quickly, and in particular the last paragraph. I'm as interested as he is
about possible answers for it.
> We can't change ZFS easily, and discovery of the problem, should your
> assertion be wrong, for UFS means metadata loss that can't be recovered.
Why ZFS would need changing? If you're referring to an earlier objection from
Mark Millard, I don't think it stands, please see my response to him. Else, I
don't know what you're referring to.
If I'm understanding you correctly, strictly speaking, it's true there would be
metadata loss (access times cease to be updated). As a reminder, this only
concerns people caring about access times, and who wouldn't notice the change
in default despite it being publicized, so a small minority as we can forecast
for now. Furthermore, for the scenarios already presented, recovering exact
lost metadata is not necessary, their absence "only" complicates matters
temporarily. To know which files/packages are used, you install them and then
run your system for enough time (more or less arbitrary) before checking the
access times. Unless you're monitoring a very specific access pattern that
would be hard to reproduce, you can just repeat the experience when access
times are re-enabled. For backups, access times could be used to know which
files really matter, but then you have the option to backup them all instead
until you get the metadata for the next backup. All that assuming, as said in
an earlier mail, that nothing has messed up with the access times in the
meantime, which would ruin the feasibility of such scenarios in the first place.
> By pushing to the installer, most installations get most of benefits. And
> people with special needs see the issue and can make an informed choice.
I agree for those who use the installer. But I'm not sure which proportion of
users they represent, and especially for those who care about disabling access
times. As for me, I don't think I have used the installer in the past 10 years
(to be safe). Is this such an atypical behavior?
Additionally, the installer doesn't cover other use cases:
- Mounting filesystems by hand on USB keys or other removal medias (which are
not in '/etc/fstab'). This causes users to have to remember to add 'noatime'
on the command-line.
- Using auto-mounters. They have to be configured to use 'noatime'.
- Desktop environments shipping a mount helper. Again, they have to be
configured, if at all possible.
So limiting action to the installer, while certainly a sensible and pragmatic
step, still seems to miss a lot.
> Though in all honesty, I've never been able to measure a speed difference.
> Nor have I worn out a ssd due to the tiny increase in write amp. Old
> (<100MB) SD and CF cards included. This includes my armv7 based dns server
> that I ran for a decade on a 256MB SD card with no special settings and
> full read/write and lots of logging. So the harm is minimal typically. I'm
> sure there are cases that it matters more than my experience. And it is
> good practice to enable noatime. Just that failure to do so typically has
> only a marginal effect.
It seemed to make a difference on slow USB keys (well, not just evenly slow,
but which could exhibit strange pauses while writing), but I didn't gather
enough hard data to call that "scientific". I sometimes manage to saturate M2
SSD I/O bandwidth but then I always use 'noatime', so not sure how much a
difference it makes. The "updatedb" scenario that runs 'find' causes access
time updates for all directories, causing spikes in the number of writes which
may affect the response time during the process. That said, it is only run
once a week by default.
I would say that most of the value of having 'noatime' the default is in less
tweaking by most people, and one less thing to worry about (for them).
I proposed in another mail having a sysctl which indicates the default
('noatime' or 'atime') for all filesystems. This default would be used at
mount time if neither 'atime' nor 'noatime' is explicitly specified. That way,
people wanting 'noatime' by default everywhere could just set it to that. It
may also convince reticent people to have the default (i.e., this sysctl's
default value) changed to 'noatime', by providing a very simple way to revert
to the old behavior.
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
