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 yourassertion 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 hasonly 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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
