Re: noatime on ufs2

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