Re: noatime on ufs2

Am 2024-01-15 00:08, schrieb Olivier Certner:
> 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.

ZFS by default has atime=on. It is our installer which sets atime=off in 
the ZFS properties. I was understanding Warners comment about changing 
ZFS in the sense of changing the ZFS code to have a default of 
atime=off.

I agree with Warner that we should not do that. And in my opinion we 
should keep the other FS which support atime/noatime consistent (those 
which don't support atime/noatime due to technial limitations don't 
count in my opinion).

>> 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?

I haven't used an installer myself since longer (either I was creating a 
new system by attaching a disk and prepping it from an existing system, 
or by creating an image and transferring it to the target over the 
network). But I would say this is atypical behavior by people which know 
exactly what they are doing, not what a normal consumer would do. Such 
experts know exactly what they want to do with atime and handle it as 
needed.

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

Those which care about that and know where this makes a difference, have 
it in their finger-memory.

> - Using auto-mounters.  They have to be configured to use 'noatime'.

If our automounter is not able to handle that, it is a bug / missing 
feature we can change.
Personally I would have no objection to changing the automounter config 
to mount with noatime (if specifying noatime for a FS which don't 
support atime/noatime doesn't create failures).

> - Desktop environments shipping a mount helper.  Again, they have to be 
> configured, if at all possible.

If they are not able to handle that, it is a bug.
Typical media in desktop use-cases doesn't really need this. If you 
handle media which really _needs_ noatime in such a case, you may want 
to reconsider your way of operating.

> So limiting action to the installer, while certainly a sensible and 
> pragmatic step, still seems to miss a lot.

Nobody told to only limit this action to the installer. The pragmatic 
part here is to ask if it really matters for those use cases. For 
mounting by hand I disagree that it matters. For our automounter we 
should do something (at least making sure it is able to handle it, and 
if we don't want to swtich the default at least have a commented out 
entry in the config with a suitable comment). For the desktop helpers it 
is not our responsability, but interested people surely can file a bug 
report upstream.

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

While I agree that this would be an easy way of globally changing the 
default, what makes noatime special compared to nocover, or nfs4acl, or 
noexec, or nosuid, or whatever other option? Mounting noexec and nosuid 
by default and having those FS be mounted explicitely suid/exec which 
really need it would be a security benefit. And cover/nocover would 
prevent accidental foot-shooting. Where do you want to draw the line 
between "easy" and "explicit"? Only having atime/noatime handled like 
that looks inconsistent to me (which - I hope - not only me thinks is a 
POLA violation).

I fully agree with you regarding switching to noatime by default. I 
think this should not be done by changing the defaults in each FS. I 
think that having a sysctl only for atime/noatime is an ugly 
inconsistency (probably I wouldn't use a generic framework which handles 
all sensible mount options like that, and I think it would be overkill, 
but I wouldn't object to it). In my opinion the correct way of handling 
it is to ask the user at install time, and existing systems shall be 
handled by those which administrate them (don't touch an existing fstab; 
changing the default in the automounter config for a .0 release would be 
OK in my opinion, for a .x release in the middle of a stable branch I 
would add a commented out noatime option to make it visible but not 
active).

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF