Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Jan 2024 22:31:11 +0100
From:      Olivier Certner <olce@freebsd.org>
To:        Mike Karels <mike@karels.net>
Cc:        freebsd-current@freebsd.org
Subject:   Re: noatime on ufs2
Message-ID:  <3896441.telDhacX5M@ravel>
In-Reply-To: <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net>
References:  <ZZqmmM-6f606bLJx@int21h> <11453367.ZaXhgXhNnV@ravel> <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart68262731.uqdp97kMnW
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: Olivier Certner <olce@freebsd.org>
To: Mike Karels <mike@karels.net>
Cc: freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
Date: Mon, 29 Jan 2024 22:31:11 +0100
Message-ID: <3896441.telDhacX5M@ravel>
In-Reply-To: <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net>
MIME-Version: 1.0

Hi Mike,

I've re-ordered a bit your mail to group some of my comments more logically.

> I am not sure a sysctl is a good mechanism for setting the mount default,
> especially if it is to be set via the kernel environment from
> /boot/loader.conf.  That's an obscure place to find file system defaults.

If the setting has to matter for the root filesystem also (I think it should), currently the knob should be set in '/boot/loader.conf'.  But if "regular" filesystems (those from '/etc/fstab') have an explicit 'atime' or 'noatime', '/etc/sysctl.conf' could be enough ('/etc/rc/sysctl' is run very early).

> It also seems undesirable to add a sysctl to control a value that the
> kernel doesn't use.

The kernel has to use it to guarantee some uniform behavior irrespective of the mount being performed through mount(8) or by a direct call to nmount(2).  I think this consistency is important.  Perhaps all auto-mounters and mount helpers always run mount(8) and never deal with nmount(2), I would have to check (I seem to remember that, a long time ago, when nmount(2) was introduced as an enhancement over mount(2), the stance was that applications should use mount(8) and not nmount(2) directly).  Even if there were no obvious callers of nmount(2), I would be a bit uncomfortable with this discrepancy in behavior.

> Note that the root file system is mounted specially in the kernel, but the
> noatime option doesn't need to be set at first while the root is read-only.
> It could be updated by mount when remounting read-write from the startup
> scripts.

That's true.  However, how about other filesystems mounted by rc scripts, such as '/tmp'?  I agree that this one is not a good example, since the 'tmpfs' script ultimately calls 'mdmfs', which ultimately spawns a new process to execute mount(8).  But I fear that, if we don't have the consistency exposed just above, we are going to need to audit other programs, including external ones, which is precisely what I wanted to avoid with a simple default that applies to everything (hence, implemented in the kernel).

> Instead, I'd like to propose that the default be
> specified in a new entry in /etc/fstab, where it would be much more obvious.
> For example, a line could be placed at the beginning like:
> 
> 	# Device	Mountpoint	FStype	Options
> 	default		none		default	noatime,...
> 
> It could be retrieved with getfsspec("default") in the fs_mnntops field.
> I wouldn't include this entry when iterating through the whole file with
> getfsent() to avoid confusing existing programs.  Then mount, and other
> utilities such as zfs create, could check it explicitly.  It should be
> placed in /etc/fstab when it is created: by bsdinstall when it is used,
> preferably by having the user select this explicitly, but probably with
> noatime being the default.  It would be in the pre-configured fstab used
> for VM images and SD card images.  Anyone building a root file system by
> hand would have to deal with this to set a default.

That could be great.  And it's not necessarily in contradiction with a sysctl.  If we have the latter, setting the default could happen through it and could be done by some startup script.  Then, the only thing not covered is the root filesystem, but even this is fixable by parsing the default line from the loader itself (it already parses '/etc/fstab' after all) and converting that specification to tunables passed to the kernel.

> I would then have the mount program look up and apply the default for things
> like mounting a file system manually.  Perhaps it could have a -D option
> to ignore defaults, e.g. for scripts that don't want to be subject to local
> settings.

This is a complication in the case of using sysctl knobs and the kernel being in charge of applying them as the defaults.  It implies that mount(8) should know some fixed old defaults, irrespective of the sysctl values.  As evoked in another mail, I think the choice of defaults is really an administrative matter.  If some scripts really need 'atime' to work, I would think that the administrator should not change the default to 'noatime', else make sure these scripts explicitly pass 'atime' (or use a line in '/etc/fstab' that specifies 'atime').  Doing the latter seems to be exactly the same effort as having the same scripts start to use '-D' (whether by configuration or direct modification).
 
> It would be plausible to set the default(s) in rc.conf instead, although
> that is more convenient for shell scripts than C programs. It would be
> possible to read output from something like "sysrc filesystem_defaults".
> It would also not be as obvious when setting or checking file system
> configuration.

The non-obvious remark seems to be an argument in favor of having the defaults in '/etc/fstab'.

> btw, I think there is consensus that noatime is the most useful setting for
> most systems and users.  However, I don't think there is consensus that the
> default should be changed for things like mount with no options.  I think
> that putting a default somewhere fairly obvious could make it more palatable
> (less POLA violation).  Opinions may vary, though.

To be clear, when you say mounting without options, there are two cases with mount(8):
- Either a single argument referencing some line in '/etc/fstab', which could well specify an explicit 'noatime' or 'atime', in which case of course it should apply, not the global default.  If the fstab line doesn't specify either one, should the global default apply?  For consistency and simplicity, I think it should.
- A device and a mount point, in which case I don't see why the default shouldn't apply.

If the default is controlled by a sysctl, it's an administrator setting, and only an opt-in one as long as we don't change the sysctl's default value.  Simplicity and consistency are key to make this mechanism useful.  Administrators should not be put in a position where which options are going to be applied is not obvious to them.  Once they have set the sysctl, not always obeying it is what I would think is the real POLA violation.  What would be the reasons to depart from this scheme?

Thanks and regards.

-- 
Olivier Certner
--nextPart68262731.uqdp97kMnW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW4GR8ACgkQjKEwQJce
JicaJA/+NI4oFoH5YBYgVu20K3PGO86LiMINRcinPRwlQW9hrHxYz4Vg95gSSM8v
kEBWWX3/r/qB25za5klYPUK8iDI8QnsyNiA1iQ63oH0SyCc7iwcpP17NZ0X0gN5n
8J6A5M8ji+4Lccl1FrfrjmvrElddeHf+i9V98SaqjS2yR0tl4Eqo2IgBVUDTe2x5
jEPRffXYaZyXUXJCIbBil3Z/F3SG1C+/cpF++AvI620pqxlL3/g42lYWafa2P/6a
duWni+zsKDa+kanNokkqQ+aR3Vo4kDEhyKL5SlhDY8fIWAAME7KNxYG0woL00XHL
O0mJSLvTUhNrSgSPub0FF/szWYTzm985IuQ2t7OhRp7ifCuW12xKXVQY7J8Tr5AJ
vumnWequBGLM0bvmyZHt+tK0eQiiuwpoFufid2O49buRyfMHyPyRKAzflCmisBtP
uc9ohfDdv8DnwIC0yjjRiyKT2nez5YwupO8hLXxfE7qf0Dd/R05T4EZk4vfvMzQx
oP6C61DccRGjE+Zx1Zb02My7uGGq3SHaMm4tukYGb9QFwACePGDklto9VOZTIOSk
7iQXpdqjUDpVTkIagWrSf8avL6Kmrds7OmCv3ibVRUiVWPAtBPvVzlhhGP/adN8G
Da47Dzprwop01+HMuUoPSKHQulden0DQs+H4NudPokGOLPKlMIw=
=uZ6I
-----END PGP SIGNATURE-----

--nextPart68262731.uqdp97kMnW--






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3896441.telDhacX5M>