Date: Mon, 15 Jan 2024 00:08:15 +0100 From: Olivier Certner <olce@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>, Rick Macklem <rick.macklem@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: noatime on ufs2 Message-ID: <2798057.DSuhTWmZiM@ravel> In-Reply-To: <CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com> References: <ZZqmmM-6f606bLJx@int21h> <a5e3a25e0d57d1a9@orthanc.ca> <CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart3294561.CbG7YiG8N7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: Olivier Certner <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
Subject: Re: noatime on ufs2
Date: Mon, 15 Jan 2024 00:08:15 +0100
Message-ID: <2798057.DSuhTWmZiM@ravel>
MIME-Version: 1.0
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 i=
dea of making 'noatime' the default, a little premature? I have more to sa=
y 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 f=
rom 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 woul=
d 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 th=
e change in default despite it being publicized, so a small minority as we =
can forecast for now. Furthermore, for the scenarios already presented, re=
covering exact lost metadata is not necessary, their absence "only" complic=
ates matters temporarily. To know which files/packages are used, you insta=
ll them and then run your system for enough time (more or less arbitrary) b=
efore checking the access times. Unless you're monitoring a very specific =
access pattern that would be hard to reproduce, you can just repeat the exp=
erience 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. Al=
l that assuming, as said in an earlier mail, that nothing has messed up wit=
h the access times in the meantime, which would ruin the feasibility of suc=
h 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 p=
ast 10 years (to be safe). Is this such an atypical behavior?
Additionally, the installer doesn't cover other use cases:
=2D 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 'n=
oatime' on the command-line.
=2D Using auto-mounters. They have to be configured to use 'noatime'.
=2D Desktop environments shipping a mount helper. Again, they have to be c=
onfigured, if at all possible.
So limiting action to the installer, while certainly a sensible and pragmat=
ic 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 gathe=
r enough hard data to call that "scientific". I sometimes manage to satura=
te M2 SSD I/O bandwidth but then I always use 'noatime', so not sure how mu=
ch a difference it makes. The "updatedb" scenario that runs 'find' causes =
access time updates for all directories, causing spikes in the number of wr=
ites 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 le=
ss 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 ('no=
atime' or 'atime') for all filesystems. This default would be used at moun=
t 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 sysct=
l's default value) changed to 'noatime', by providing a very simple way to =
revert to the old behavior.
Thanks and regards.
=2D-=20
Olivier Certner
--nextPart3294561.CbG7YiG8N7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkaWAACgkQjKEwQJce
Jid1fA/9GY6er1xPMtA6COTeFy77RHMlF4PfuZOH8uGjTDgqMEyhLI96VbE5R65e
JJew7lixtYF+l96zUV4BMAb4LSOCL00XbHe0Nu0WPKiu85ALGHoCHF6Vf6MKtXjY
xLMP/NofZvYzXsy4WH1tr8a+6yS+Fdsm6w15/ZmFdy1YvsiFsfAPDgKB4XcwOhHO
W+BuyKaZrnpryKQP+aY3J+D4fsROHxO3MHmI6to5uAXuRi7DNh1jHW6CODh8qm2+
AiD/UysLmS+A60u3XXZ9tgtNw8IyZLqT0JE334Gf1qGMHcjYVO9q6WICSgmLlpM2
iujCaCql8v3WkW7O1JX+ubqmHEF4WImJ4C5nZfGW8QgFied9WhSHb04e0QQNKu83
UuShOk69r6XL0lrOjojp2Gd5E3ot5ebL8KdSld/mVkHjl9hA63QaiSjKcYJQNRcX
gVeWsdF3frsiPb08egVqxOHBqjVK/+1So2Te8xhGQGthqLMMGU5N8X0F4iVqXFoQ
vohjBDu+a6bmJN+YwsdAWZB8juOJB6il1hZF9VTVFEDretJJfo6xo5Jpff1QSkze
8x2VQX5DUIraUamB1hu51+gwVf3+2DRewhRzvUzuqfdUuz2gbzFEp9CGcAGfG5lA
9bZQDlOQPB8dahKMNDn2mAgfcIwv/6eDCSPLFp5wNIN6DmjV520=
=NJYe
-----END PGP SIGNATURE-----
--nextPart3294561.CbG7YiG8N7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2798057.DSuhTWmZiM>