Date: Mon, 29 Jan 2024 10:06:53 +0100 From: Olivier Certner <olce@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net>, FreeBSD Current <freebsd-current@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>, Rick Macklem <rick.macklem@gmail.com> Subject: Re: noatime on ufs2 Message-ID: <1959441.ruP0FAUDoQ@ravel> In-Reply-To: <bcb3d179ab5d462adb27c71bcf9bc5d4@Leidinger.net> References: <ZZqmmM-6f606bLJx@int21h> <2798057.DSuhTWmZiM@ravel> <bcb3d179ab5d462adb27c71bcf9bc5d4@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2452072.rlboQYEQCB
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: Olivier Certner <olce@freebsd.org>
Subject: Re: noatime on ufs2
Date: Mon, 29 Jan 2024 10:06:53 +0100
Message-ID: <1959441.ruP0FAUDoQ@ravel>
In-Reply-To: <bcb3d179ab5d462adb27c71bcf9bc5d4@Leidinger.net>
MIME-Version: 1.0
Hi Alexander,
> 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)
I've almost addressed this point in an analysis responding to a similar point by Mark Millard, so let me wrap up and complete it.
The situation of ZFS is not comparable to that of other filesystems because ZFS keeps a persistent "access time" setting (the 'atime' property) for its filesystems. ZFS' fundamental way to deal with such kind of settings ("native control properties") is to automatically apply them at mount, so changing that part would indeed be a huge POLA violation, and I'm not proposing it (and, to be clear, never meant to).
The only place where a system default for 'atime' makes sense for ZFS is the initial value of 'atime' for the root filesystem of each pool on pool creation. So it's really only a matter of, e.g., changing 'zpool create' to behave as if 'atime=on' or 'atime=off' were explicitly specified (depending on the sysctl's value; of course, if the user really specified one or the other, his value prevails). Doing it this way makes ZFS' default for 'atime' completely invisible (a good thing, IMO). More importantly, after skimming through the relevant code, it's likely it will work without any kernel code change (whether in OpenZFS or FreeBSD) at all. There are also other possibilities.
> 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.
The point is rather that nobody, even experts, should bother tuning mounts with 'noatime' when almost all people that care want 'noatime'.
> Those which care about that and know where this makes a difference, have
> it in their finger-memory.
Sure. Does this mean that they must be forced to specify it each time, or even have scripts for that, each one developing its own? I don't see anything constructive in requiring that.
> 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.
I've already mentioned the case of buggy USB keys in another mail, which is a very annoying use case. Of course, I try to avoid it, but as you know, these things happen, and this has nothing to do with how I operate but just adaptation to the world we live in.
> > 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.
This seemed to be implicit in some other answers, so I prefer to clarify.
> 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.
I disagree for the mounting by hand part (whether to mount USB key or other external disks). For the rest, yes, it would be nice to change our automounter and external programs, but all of this becomes moot with a proper default, so why go through that hassle for the case at hand?
> 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'd say this would look incomplete rather than inconsistent, in the sense that it is always possible to add support for changing the default for other options later, as this is not a case of already having several similar features that work differently. Your objection is quite strange in this regard. I don't think we need to draw the line anywhere now. I like your suggestion about covering other options. Typically, for my use cases, I would enable by default "noatime", "nocover", "emptydir" and probably "nosuid". So the important thing to pay attention to for an "atime"/"noatime" sysctl proposal is to name things appropriately and factorize code to easily support other options.
> 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).
Great. As explained above, I don't agree about the "ugly inconsistency", but I'll make sure to pay attention to extensions to other options and try to foresee what they entail. And also, I don't think it's overkill, both in the sense that I'll use it all the time (and I suspect several other people as well) and that not a lot of code is required to make it happen.
> 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).
I generally agree. I think the user should be able to say to the installer if he wants "atime"/"noatime", but only if he indicates he wants to tweak the system by choosing some "advanced" mode or something similar. Otherwise, the default should just be 'noatime', to KISS. Once the sysctl is there, there will be two possibilites: Either the installer changes the default, via 'loader.conf' ('sysctl.conf' is most probably handled too late during boot), or it makes completely explicit in '/etc/fstab' what was specified (or defaulted) during installation, so each line will have either 'atime' or 'noatime'. I'm not sure what would be best but, not having given it much thought, a priori would be inclined to choose the first way.
So next step for me is to propose code to have the new sysctl knob. I should be able to present it hopefully within a few weeks (it shouldn't require more than a couple of hours of work, it's just that I really can't find them immediately).
Thanks and regards.
--
Olivier Certner
--nextPart2452072.rlboQYEQCB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW3aq4ACgkQjKEwQJce
JidXaRAAgDopOs899vuXvfqLlUd8pejXHakfzEHVYwLFbJdmjBTlHPyDZKp7BXiX
Pg6GJOBYF3MOhN+R5c2alXvqymMKZ0zmM930/xtW39dpkWAD2IxdiQv+5Z9AN/tt
87UAskSvOpX9OeyQdw9tJe10wMsCU9ZO4ZhRtPVOQ2S6JDvyGcCt18N4rthjW9eG
FPoGpG+rtuAowaD+XgMO42vUm5v8IYQZAvT6W4TKHCACjcantQTMflZwqsN3lPmB
FsMGW0uy+CcxkpOB28sXuC1cezZr3ILAvkJ8jCikmz+uSZCClqTEKSJkljCepDdy
vR5KlVPOiIJc1wiOd8FTvzJ2CD5lJ1Y/Ncl6sRR3iot4YZoU/ku6FJ041WdTfMd4
g9Vpk38EpcpsZRKDP0Xz4SmfLv5pLluRBWeIU3PTBtHFxzVXF8v/p/ZO7LsLOj++
U9QFiOus1FpN9deXK1MJ5vBkyOJkiWyhgjnmM6SGCzliGKybCzaiLYmYAsbXXPth
TS7UJpMvaRzIMug4ZavLdVENaZUlbQUx8FUTfHqF1P0QexZLTF+xscgDBT05a1Zt
BRYbS24iR+T2HLp76lER3mrSUVKb15cS1IJjOTL17QPCymrHU8gZX3/76A7BwBwO
AAsqg73se8g1OsPiyXLqHS7UcIUubpOAbYxYrG+Y3XSD7Y7pTso=
=e/jn
-----END PGP SIGNATURE-----
--nextPart2452072.rlboQYEQCB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1959441.ruP0FAUDoQ>