Date: Mon, 15 Jan 2024 08:54:34 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Olivier Certner <olce@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "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: <bcb3d179ab5d462adb27c71bcf9bc5d4@Leidinger.net> In-Reply-To: <2798057.DSuhTWmZiM@ravel> References: <ZZqmmM-6f606bLJx@int21h> <a5e3a25e0d57d1a9@orthanc.ca> <CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com> <2798057.DSuhTWmZiM@ravel>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--=_bed717be6ecceeb9b768d58ee500a606
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
format=flowed
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
--=_bed717be6ecceeb9b768d58ee500a606
Content-Type: application/pgp-signature;
name=signature.asc
Content-Disposition: attachment;
filename=signature.asc;
size=833
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmWk5MoACgkQEg2wmwP4
2Ib/WQ//aStg6Q/fzzYW+Y383eCe4pmGoQkVB/OJLbNJoKAGs4UbGkbSgHDX61gv
q5B98iCvrQcN7gYFo5NnIUz5ZWjg0+dGi7qqgde5QRFeSZ+CrDxAKGLb77LdGKYl
x4PCQtGSRwCUt8yDmE/txa4ysUILRb81oxy5mU1nzfSq8/LT0ikfugCvtcvf1PkU
a+Fr6Ac3bpD+jYVsc+hsHp1+PitcDIwHZND0vr+5jBYbzhJcDJl3S3POW99hFwsh
XnLvxgCSk6+abKXLE0xHEuGb4HDAa6+mBQ98rcMv8wN02XdBQjOd/Ce+jHgFC7/k
yyqI3Ohion3V71mKgHb35oOCBS7B8GtpSOIlhFRDvci41Ej1/MPdR+kWuF4xX46c
aC25FVLSa7Lqxw9U4sM3iAXGCoFZkaQ1Z5xqw6zeuQkt3/KWoJtUnSBj8FBEfQkW
uXronqkdaiFerw/m5nZHP+XE/KU7yp16+NhBV1TGArnbyvBtgcAgHIEABmoOVkPE
RAbPJyGT/7YgY75OMxbBQ+oqCHcECFRhiFmT5bOm2KWgIsFG5EDZAQfIABw9mLwk
94L1oD+/uCXF0zPqI1Wvu4niG4ak0w18dkHETif3LtTvTXSE/aBWtH0qpuCznngM
tGSmdpIgCQO+lLKVyunIsElhKLgxhYKeFByRV0jhGcMXaESq/+4=
=zLZ8
-----END PGP SIGNATURE-----
--=_bed717be6ecceeb9b768d58ee500a606--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bcb3d179ab5d462adb27c71bcf9bc5d4>