From nobody Mon Jan 29 21:31:11 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TP1h11dFBz59SBd for ; Mon, 29 Jan 2024 21:31:13 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TP1h119mjz4VFX; Mon, 29 Jan 2024 21:31:13 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706563873; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FVn9e/xJZxgNeLbTJZfyf53CDJEspSZLQN+wWmmjMOk=; b=uFQes24oRaVFbUaZLdgpmjnHwzlTx4T700eD76BDdKdalPAZ8jJBuq4R0w4fxruI3NP8aZ FeJ1SJUQVM2AXHTp826jnD4ClEuF+dUjhupJCISlhSFFqybDuxPYN0xcLTon3QtSzLHIrO w/DFCYm68gm04Zi9mpDogOeT5WqfXkjeleLP8j8oYs1tACNRVP72AsgUMqD7EaFh98TksY VR6ULK34Yigca6GNqhUKtZtlivLhh/bOApJ3WCkf8pLaG2hAQwV/15T7GegrS7Wb4Iu18l 3CMckaKAOu7bUwf8b+EE6UPHujewzNcpdaLo6K3LqnR+n1aIjnJRFke2bK7r2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706563873; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FVn9e/xJZxgNeLbTJZfyf53CDJEspSZLQN+wWmmjMOk=; b=RaKSAiKghNx+GyofeIU6nYbEpxDCxvshp5wYnXAnRKuVG5A3laVls4pZ0uRW+aNJwEdMA+ io3XVwS84ZFLctP36o7ZsbEqk8FYS4o33OgFmtbiINj88gfCUIcj41HgIuByYRQSR9ymEU KuAsKBL2rIM2/7Fe6b/1CEyUQdjSqyFIXfKXaErKlOSY2joJ/kgrNRZeFsb5By6LlFEKK+ oeCb2lFO98QFG1Grvejk1LZ14fdiFCC3BZAEFSakwTXgMKZdtT3l6oUWQZrfIcduWqdPbH WEQkTjeY2ozYKollfz4XZaGiWgcnNytF5438AYQwOJWW4aTn7n8yJRSw34Kf/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706563873; a=rsa-sha256; cv=none; b=v3y5nF34d3yuXXExc129tMVkOle5ov4tPjc7PsKxXeOL+K0Ck4++wKzBPk7kOHp/p1fFAi ptxzW/1ISfpCRGpm+qFw0dszws+Dn1TXALiF0CD/3fuo7pQ+dW7ZxBGfT2NCIqni813ZCg Glg4J1bBX/owFrTgIF8f1vspRH5jXHJDaMMhL/zxYigExy5G8jGiCuDb9QEA6tMrJRCUba 0WR0XdMNaeEyeaifhFt/IkwzQpMnOKydwKw31Ta20ClmPw0ZtErrk5KYwcKEBgTLvs5KNm XVmA1DWSnI7Q8qW9oGrRAbw1raPUDNFlRt5mo/ztGUvVIGF9QFkyuXVw5qMeXA== Received: from ravel.localnet (lfbn-nic-1-525-172.w90-118.abo.wanadoo.fr [90.118.140.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TP1h054fsz1LGm; Mon, 29 Jan 2024 21:31:12 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mike Karels 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> References: <11453367.ZaXhgXhNnV@ravel> <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart68262731.uqdp97kMnW"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart68262731.uqdp97kMnW Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Mike Karels 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--