From nobody Mon Jan 29 09:06:53 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 4TNj9N231sz58XKh for ; Mon, 29 Jan 2024 09:07:04 +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 4TNj9N1NXHz4jbl; Mon, 29 Jan 2024 09:07:04 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706519224; 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=fGySF9FZKgwe1bLpogT1iyrGmzENzWDL7dBlgQavlPo=; b=xuXqEjSVfJegKfzgEWEtG81KoLhi5n6uRl6n4o3w2+SRK8kQZP7JuAkOUkXly9ekuhqn3Z qi/QUShcBwYgCtQif1MFuOCTn2ZGW/F3jzLFXlwkYFBjkBkmZpqe+Jfb+79DK6xCJVM7Hs +7wfXN21Z/HTyAvw++8qbfHIYrZ4KKBM/DQ6y0lg04o93xC/2+f8Jvmx2Op0CGlxUXitsT kA+U41hmuRfuUwN0m9Fzlshhge+ZtnKGDG6G2kPMbLY5+HUYi6Rxn7tjaLenqH8L2NB12Y q6C/6SN2kTDpsj/E1lrs3m+1XRxk1Z96dlrTi9Csg/eCoEN8AmFsPNmnkSkn4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706519224; 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=fGySF9FZKgwe1bLpogT1iyrGmzENzWDL7dBlgQavlPo=; b=guASpowY3kLLiHJOs8m1qLlBETVSe9YwoCFdc60NONF4YygCCAS/SG+YscYmI8f3E/Dyrj YhkY77124H7ZYAmvjUTNbgwaB76fRiJnmanXdCgkUppdQQMPWxQQcoWYlnuagufNKknnI4 PWzMbiyeAmpeUfjzoopSLOBuW0blDUhpfBygR0LP+dh5dLTDZX0vfFKAxwxLzkjFFctzFh GNMuqatwoErd67xpxdl3m4wGoidWmeOngZFyYaS2jMalXq5mWATMzpy8fxYCIY64DYWJ5m cL45ys6Ocz378jbKG+OQD1f7q8rsswknB2URTVDcwgRbBQ/izM6Ynav3Y1hk6g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706519224; a=rsa-sha256; cv=none; b=pE3iU1eso9dDloRPKHjsNFAkmEGH7TM5J/DFnyhDA5i7AnhLquVR/qYxfqPvwhL1Lymal5 r8TEGxM+wBw6qmSewNHPjaKa9r5Xsvjw5xTeob3O1u6eeA1P3cGSbfO67K4OvvLie2nrlZ LqIkIpb0ujsjg9KnrP8FxCEuiobtg5ZVSGnTTxhVlH4uXBzz8AIbc92XZbcGHGtL1XsrYn kp3mINbWp7NB8x68/eoMo5FLqBfnaVVHyyQ4bU3ceFO3TGpzJKh3GdNA6dsuZYKQrcg6Xl 7eZaiBwP1tzO2FJUuSTeLRz3myqK0codbHApqoxKzWdGMkPXxZNjh5BLHNpJWQ== 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 4TNj9M1K0qz16p9; Mon, 29 Jan 2024 09:07:03 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Alexander Leidinger , FreeBSD Current Cc: Warner Losh , "Lyndon Nerenberg (VE7TFX/VE6BBM)" , Rick Macklem Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 10:06:53 +0100 Message-ID: <1959441.ruP0FAUDoQ@ravel> In-Reply-To: References: <2798057.DSuhTWmZiM@ravel> 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="nextPart2452072.rlboQYEQCB"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2452072.rlboQYEQCB Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 10:06:53 +0100 Message-ID: <1959441.ruP0FAUDoQ@ravel> In-Reply-To: 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-- From nobody Mon Jan 29 10:27:05 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 4TNkxs5wgYz58Qk5 for ; Mon, 29 Jan 2024 10:27: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 4TNkxs5JyFz4rtj; Mon, 29 Jan 2024 10:27:13 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706524033; 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=3bXuq4gQfO2kX/K78pwqhJKUHOulkSLKOni2E8roDp4=; b=xkvINTeL1WPQVBEiF0OadgvlBnjpD5lFxLtakmOh0cBIUNk0SM3im1aIErLVoeWzh7Hnif yMY2MIn9Hk4ZDYPii59UtaQ0hEzs24j98mNyPZ3QlF6DiOUKIUQ3O7SIqDxp9wi/4PcEAp llWKT846tP8kxHN/Igu8nhy/+kUlEiHDM0M28pkHI7ZCjf+x5NCQ0eiw9YKrG5bh85T8fc FbGKR/1vdctpk51x7GGgLfx+ZTxsXbVoZLKhVjOOgg9Dl4wD5VRuMKlpqEGreK9EHB/mGC q79+M39ZvLnae71FjY9s0IZkkCYd815SwM0ytrByfqvwoyRYnpJijL43CLJUjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706524033; 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=3bXuq4gQfO2kX/K78pwqhJKUHOulkSLKOni2E8roDp4=; b=B4spr+//+hGN/3uwfTrL5vcslnTG/7auRYLSna86J7N6Ylh2/IChf5SZAiKf3ZOMzHNHo/ mg074nWRwzkgHTxHkpWmiaqPb5eC5Q1aYP+qhPv75Tjn3AGgY/TPgFK0Ud+qXjuzSRuWvU 5Jqo+TlYmKaY6zHR9Q/fEeAJrTSyp3I1uunsE/NRsTimPOJcNo8329bjdOUAMIZOBwpl7Z gI6WBoKY8FrnrcHQMD6iEQ6x111Lr70p05jIXzN9n6+NvRZvHUxbwFq2zy2xROfySe9ait Z07cmXNbt6k0jPehpFUA8Z/wJipsry3UAkhHKLNkj7AfcBXDim/rs7cnAl7iaA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706524033; a=rsa-sha256; cv=none; b=EkFQLFUzpmrshNEDeupbMXA04HshWf4S43hGDxCAmHwYjuJ0zPXaUIvv/ndS9rGJA2OcYc MNZIATdNlXyOhDyWJ2Gkf3P3FTPhow4zKfueAtFZ207TtrcatopR3zgSYx06uVl1A80Igw IcykO6hICVJMV6Ytl7j1W/V3/j2NUiGW6Ca7OSEH4S6hr541QUpLngq1GZom+gBf54aPHu tvKkHAzC4DFNl71U4lAKd4jytnKBDFVirfwkF1z8pcx3NzdW6WXeWHj6846EAGNWFp3gg7 MM4zjg3ivsz0Bz2+dd3fAMj0JrZD87HfNdoyGzWOBbLGtjOo1++Mru1llRLuiQ== 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 4TNkxs22YBz182g; Mon, 29 Jan 2024 10:27:13 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mark Millard Cc: Current FreeBSD Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 11:27:05 +0100 Message-ID: <10218883.mV2X7mr0Zk@ravel> In-Reply-To: <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com> References: <12921270.kl7XSLc1hW@ravel> <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com> 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="nextPart2609540.JStIQ7tifP"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2609540.JStIQ7tifP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Mark Millard Cc: Current FreeBSD Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 11:27:05 +0100 Message-ID: <10218883.mV2X7mr0Zk@ravel> In-Reply-To: <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com> MIME-Version: 1.0 Hi Mark, > I'm confused: I go to the trouble to produce the same end result > as your suggested change of defaults would produce, ending up > with no recording of access times. That's nice of you, but unfortunately that's missing the point. First, you= claimed to "seriously care" about access time, so I simply asked about you= r use cases, which you have not talked about. Second, your suggestions do = not (in fact, cannot) produce the same end result as what I'm suggesting (c= hange of default, or have a sysctl to control the default). I've already l= isted three use cases in an answer to Warner that can't be covered by modif= ying '/etc/fstab', and two of them that can't by just specifying mount opti= ons to mount(8) on the command-line (the auto-mounters).=20 > My focus was on things like mount command notation and > /etc/fstab notation (that tracks mount defaults) or subroutine > interface equivalents of such things and changing their > behavior without requiring changing the notation already in > place in various files. > Nothing about that of itself > implies that I'd want the defaults for mount notation or /etc/fstab > notation or the like changed --or that I'd want them unchanged. > To narrow of a context for such a judgment about defaults. These two paragraphs seem to contradict themselves. If you've gone to the = trouble mentioned above, wasn't it precisely to avoid changing the defaults= ? Because changing them implies that the exact same mount(8) command-line = or line in '/etc/fstab' will have a different effect if 'atime' nor 'noatim= e' aren't explicitly specified. This is a goal, not an unwanted side effec= t. > In case the potential confusion is involved I'm wondering if you might be confusing default options per mount (as a lin= e in '/etc/fstab') and system defaults applying to all mounts. By design, = the former can't apply to mounts not handled by '/etc/fstab'. The latter a= pplies in any situation, barring explicit specifications by the administrat= or (or delegated software), which is why it belongs to the kernel (it has t= o apply to the relevant system calls). > (I've tried to word the above without making new points, > avoiding contributing more to the bike shed material.) Bike shedding has become so popular in these circles that some people see b= ike shedding where there is none, and/or use it as a tactic to try to disqu= alify what others are saying. The initial bike shedding email was about a = simple, obvious change to sleep(1) that prompted a flame war lasting weeks,= with unfriendly fire from the project's people, sometimes from the old tim= ers. We haven't had much of that so far, except perhaps for a few mildly a= ggressive or emotional emails, and the thread was active for only 10 days. = It was then paused for 12 days since I didn't find time to read the latest= mails and produce answers until today. What sets it apart also from the s= leep(1) example is that I intended to drop an idea and gather reactions bef= ore having even produced code, because I wasn't sure on how it would be rec= eived and in particular what are the use cases that could be affected. Obt= aining this feedback is essential because this project is about people from= diverse backgrounds and needs. It also helps in clarifying a particular d= esign, which some answers fulfilled. I'm now at the point where the next s= tep is to put up some code for review for a sysctl knob. Is 'noatime' not being the default the biggest problem we currently have in= FreeBSD? I agree it isn't. However, it doesn't mean there is no value in= it. On the contrary, I think it is very important that the project has sa= ne defaults that match contemporary uses: It reduces the need for tweaks, w= hich serves both beginners but *also* seasoned administrators. This is in = isolation a very small step in this direction, but there have been others a= nd more will come. Collectively, they can build up to significant addition= al value for the project. Regards. =2D-=20 Olivier Certner --nextPart2609540.JStIQ7tifP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW3fXkACgkQjKEwQJce JicpSg//YIxXX7O0Q6BD9vWa/FLj9hqy53iRzTS6t7i8m7ypCHVfbj7ACxP28jl6 O50HchsOpDJ1gbp4dO0bRRNMPkMWetFQU/rwWcD94QXbeDZ1oclj/BEwh0K31Zqu 5jqmQCy/fzkqJKTLBR/Xb8vTedLTUyz1uz4/2wfPLlgHjTwyinu03jmBSu+uLL2h aIrRGpFn1b43SZS45oNgifI+afqA756kocpA4URl5l4+qYZFzSTfReS0dGzqHnY4 S3KS7w0aXz0j1F5LoBI9Ur0swFGdxrAO+BJ59ONpFvyhtepGMf6ApoqtRnXL8ncI /znO1+3LoX3Kw4kf3rp8at58IBxrB1jog5iFeRL91Bhfbu+cpoQXZW6JxiHJRYw0 9pSpybB/tk02Rrd5xJ5m49fx8IUsFoHr07T7XPUXho+vE+tpG6zkUMNkA8CtGclN 4bumzwROY4u2vAvN+9Kb2RqKQdo4q9l3dKt6Dbqsh/1z1qSKqr3gFrO5KxS33sTR pph4UtCRxI+Xf2viByk84XhPc1N8Zv5LeSH9w6PDQJgVgD2Lgy4UemkhRNVNIpQn LFJ74NHZYYC0VOxjZGvMBT11MkGgtEy48mDAJGyPK8xgLQt0ggvtLdvh4JsUoMKW qRABr4z2q1iZC23S5XQq+yxPEbXNWP0IG0qGFEBaw3IPKaA8N20= =IKf/ -----END PGP SIGNATURE----- --nextPart2609540.JStIQ7tifP-- From nobody Mon Jan 29 10:50:05 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 4TNlSP0RMRz58SQ5 for ; Mon, 29 Jan 2024 10:50:13 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TNlSN6qm2z4tyb; Mon, 29 Jan 2024 10:50:12 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706525413; 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=66EJovFA1jwP+WZZDYz540LSk8dXIdD9vQmO/qrbI3A=; b=k1yuFGaAzUYd21BdoTtJNb+MQrPrEyoITBwCU0QtYZ5fSuZKMCAlbYidOaLrWy8OP7d4UG LJ9UHeNqULUhXIZppNFTEMOlzxCkmKXiiZj/5vTh+XZWJEa88xfN26MSIzJGfU/SOKVAS0 OQtStXaXYIElz9R0OuB7AuIypuhlpE2GnlObFGeiNrwgaYsEC8H9fpo8RlKfAqjZgraACs 5NBJzqiSwhl6i564l4SM4lcjUooNV7PiO+/R7N8qL1RbPopqMatUwRv4YOgBHBbIo4jGsn WVGGwwPChjHhLPPLW5UJi01z87KqXz1QjjaO7+FRn29rFddhMbD14/XHvr/+nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706525413; 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=66EJovFA1jwP+WZZDYz540LSk8dXIdD9vQmO/qrbI3A=; b=tkx+wIvzfBu2efKN4Yez+7IWdj2CT6FVfXTgntoHErlz62nZ23ZTpefc2pFlqEl2o8J9Qa WS42WhRvhygjZWrq95K/zVS5mHqVqQc8WgaXRsGyXiWfZ/9nHgk0th9h/9s3x797lf/DjL mRo/jhV/4qXNDBpG+/3hrORrG58nXJ6j+igfEBFeGcBz4N8//nVo30cV7IWPQKVgmDxB1B 1cA6sN4ZfpN5wCd/UnCe6RfWAzyXCvPq+VzCGHE3bskx9mszkHxzs1/cPxOYAH5J00zzC6 6+jOMLSetPgOa0Q5YNA4pMpg803X805NIA+R2mrprdktCo5Q+8zkFLbDOk2r5w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706525413; a=rsa-sha256; cv=none; b=qfvIXFsBImwP6F5ZHm8RMoWcdD2YMTmbpuq2atz2oUs7H5ufBdDfOZ61WWqDfXDK8CRafB mxFxHBnz4UWVD0ig5BLvB5K+BGUj5GpMNBH0lZ5yK1VvTI29JIxvYFVBjNWMTimVdfLY8d cRNQxw63HivwIgBU341wtoXfwtkrobUNFpaXw4fIqzLBs4pSrfKAerPeIb1vFNYeSQN4tY 63Kmic0jVylX+FasriE8V5rXClE89ajCz5l5bmE2uBNxApJJqMLqWyRoRx6Aj4dxqv8FV/ WGOBsQSym+DNcVklO42HzQCO9eMeJL/RzxT7jN41KuHql5sXvcTlnOFss8TfkA== 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 4TNlSN3bPNz18Dx; Mon, 29 Jan 2024 10:50:12 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Chris Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 11:50:05 +0100 Message-ID: <11453367.ZaXhgXhNnV@ravel> In-Reply-To: <9155214edb61b1bc3bad3bc96f96e22b@bsdforge.com> References: <6714298.qJWK8QVVMX@ravel> <9155214edb61b1bc3bad3bc96f96e22b@bsdforge.com> 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="nextPart2621567.ixSHFKNIK3"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2621567.ixSHFKNIK3 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Chris Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 11:50:05 +0100 Message-ID: <11453367.ZaXhgXhNnV@ravel> In-Reply-To: <9155214edb61b1bc3bad3bc96f96e22b@bsdforge.com> MIME-Version: 1.0 Hi Chris, > Honestly! Gosh... This doesn't start well. > Why do we have to upend decades of usage and understanding? Just > because it's old doesn't mean it's wrong. Who says that exactly? Separately, in case you haven't noticed yet, some things have changed in the past 50 years... > Several weeks of replies confirm my initial > belief -- atime as it is currently implemented, is as it should be. Several weeks? The first mail was sent on January 7th, my first intervention about 'noatime' being the default was on the 9th and your mail is dated the 16th. I would suggest that you revise your implementation of access times. > I haven't seen anything in this thread that wouldn't be better placed in > tuning(7) or tunefs(8). It's not really surprising since, given what you said before that, it seems that you haven't really paid attention to the messages exchanged. > Security and forensics are good reasons to keep atime unchanged. Having access times maintained may occasionally provide a bit more information, especially against script kiddies. But if you think it's a reliable source of information, you're deluded. See my response to Lyndon about the general problem with access times. I also already talked about auditing's needs in my very first mail in this thread. > Any discussion regarding changes to it's current behavior seems folly or bikeshedding. About bike shedding, see my recent response to Mark, it applies to "folly" as well. > Apologies for the "attitude". Yeah. Most prompts imagined by Poul-Henning Kamp in his bikeshed email would have applied perfectly to your message. Thanks for the thought. -- Olivier Certner --nextPart2621567.ixSHFKNIK3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW3gt0ACgkQjKEwQJce Jicq6A/+JHfwy2ym5kFij4noLEA40gxt7xWFmETLPsYLlfE6njNCSrbMHU5B7uHn GLzx7KxuDoYrr9IeMtFzEY7V/gOXn/jUm0OHiEWiy8B1s6Q10nmzAQ9mUT3IVlK4 p0X3LZCErEFmleTPCPMqVHWDFp2dMAkw8bak9x0qqxulfZQJQSugmGbJGBIetcUb KLLlHGk8W/RMy5ZwIKs4RPdGaw/WXU9kSYMYmTeLi/iFMW7KDVM8wuSRecijC6qL YhfN4B5urOfxqAianORdFYhJacLWT1Cac67wwcenqMmcdHiB478419VLBLCw3YTY kja7TLrkSPqmPwv5DCilxkK0O/duHqp+1xAT1wU6ri6cGjWwEuuXsu/GapBC51W7 2RIQBTklFYRvCKkTFB7mGgRjm+8u94QVg1gXLe1R4O9DVzsqQD2yfuwwS24OGaOS BbFxCw/5v6ugXtycJNUulEzkEur1taE5tcmDcGJBnF3EOhzbWwSXuKl+kAbMxZ0c vDWy0cx3EzTO7IhaquYwpzlB248v2OGRXZZs5/Rj6c7Tpcgsd7qUBe9xTz/xoJyW SoleoszeuF7mRh8lBWZe0+ZdFN7xwIfIyaHxXwGxnzGyR7ZxvzvGhVahxUFIeq3J DUTNqcbwkJWtVg+rPrU3tGeBYLCsJLowpTfharC+dWhbYUBc9cw= =VgeN -----END PGP SIGNATURE----- --nextPart2621567.ixSHFKNIK3-- From nobody Mon Jan 29 17:40:39 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 4TNwZ76Lw6z595q6 for ; Mon, 29 Jan 2024 17:40:47 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNwZ74btYz4wlN; Mon, 29 Jan 2024 17:40:47 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40THeeTK087188; Mon, 29 Jan 2024 11:40:40 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1706550040; bh=6BaQEBSH1RRyFC577D055pYgrHS/Tlt5CWNMc9Jwq3Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jQ5/SWQ3masntgjBkvTUFY5/c0efKUqqyKPvkxinsKcIfuBFMPRNV/D3ynSqUbVQs VbqFgYg5CrsE4CMHzv54x2Rwy5Dq/8taBd0GaQUCPKFEVkAMczCW+fGCl7b4mtp9V5 5qmz8YDgV2MDpDRJGr3DvpB4WZKyDwhvEh5yYBOpIZkSa5AxoQSVVqbXcNGEAGI69W 78rmkYVUdz1NKxcKbYfVQCilxiJ5z/8pvix/7igPRNQw10Fn3ZMp6jhMGA1tqrxLE6 adSRppeWYiLqpyCWwETtODr07gz9aLmVkPNEmr98v0DXcbEerwftyBkBtSf4YVe3A2 5skG1w74fdKOA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id Oxv1LBjjt2WSVAEAs/W3XQ (envelope-from ); Mon, 29 Jan 2024 11:40:40 -0600 From: Mike Karels To: Olivier Certner Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 11:40:39 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net> In-Reply-To: <11453367.ZaXhgXhNnV@ravel> References: <6714298.qJWK8QVVMX@ravel> <9155214edb61b1bc3bad3bc96f96e22b@bsdforge.com> <11453367.ZaXhgXhNnV@ravel> 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: text/plain X-Rspamd-Queue-Id: 4TNwZ74btYz4wlN X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] Not responding to a specific message, but following up on the thread: 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. It also seems undesirable to add a sysctl to control a value that the kernel doesn't use. 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. 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. 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. 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. 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. Mike From nobody Mon Jan 29 19:15:10 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 4TNygL4pF6z59FDm for ; Mon, 29 Jan 2024 19:15:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNygL1RxYz45tK for ; Mon, 29 Jan 2024 19:15:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706555724; bh=Fwfa9IkGjgyhkKMU08qpbsqBM+Rc4fDtOdBZGg3PsDU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CZk3/vOxcv8vUAX/hA9JimAxcH7fPfzkfFab4CjCZXni9R3/Oz5lH4xAv3tOeZoQ7H/FO02NmqHzERvfYaLw83qvFshG+OJwVw+omSM2I93TZK74d34wuAyttMVS3QGYuI9l6a7HazjplyNfriIZlwWHdsWOAwqkV5SeWg+4I1rT+IWis30E3l9BGhUdWcs/mPFFSmDBgKsC/6zVpDUTf9PXw4g4F9EUdzuLUCuMqUmGxbVA8GqPcDau0jPfTeKxH9SBpla5DYNp9XrvuP/mG6yrzzaIxppY2petCeJXZYmjti0SBiUl083+8saE+P3Mn5ApR1uc5oYbljC7hOXotw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706555724; bh=Ht3q+mxbyj1pph0e8neCNX1tvIb9Q8PHi9cYDg7nbMK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iQAcDOjAlW/N7tow4PFH3peuDjJ2vUhOUSXmJzzOZfvSPTULjAIZw7WEm59NFvxUmzQrvYWixFGX2wEFC7oPefyqXaxdH5XAyt+dYITRZ5ree1wr3mNRPN/E5fliB3g16facLMw7vE6BjJWPEUq/TakL/uLpL+xFhmHYw79k65jtCConh/Hu7xhjgqzafkWTbzUP1Zn+PWy09O+Krc7Awy2XSnnDtsx4+ubL0Z+9Bs0qSEHPRIvP38O7e9H/TcZ519nRkZ/Ju/s45GzttBFgOSXR+RKynAXG94s5WVSoOaeSkGWjOSpjinXZDGDaiVbfkm2OKDfIMeBfAtme+WzW0Q== X-YMail-OSG: tpG75RAVM1mZ0alpwYJL9bW0Fu8_Q1OiIEmAdX_qMgbSX57AUyEKP.n9d0jJCyW b3czcWejJQAKN7WFCTbNUC9HVRknn4Y.nDHHuvRql4t_PHMhEJ0nK.NJcTFue4EORfBkqisLa4Kx O1hCtZNlt8mufrGafGk_nZXCkUW240O7efyKurD3VwoER3rVuaE7FV_T3WcV_9UZoGQe.JONTYYE JgKRoNkbeqPHrTKjRCbVEEobDfwB1OOP1_3pClZHoBNkht13E1oxEDX9Z16sBm6Xo0TLqbk3Yt_X ds9VvKzQNkFoXT1OvqvahHLpheCB6JiQFlKr0d.hFQRQJvdZV5x2LxFpDw1HjJ7_w2hJIwn.MBrX EHHHyavq_5ENPnstnEg_Ynr9KhYyqksLg5LLWa8wz8WjMcHqoBaHe75anPN7v8lpY40H8Wp5TW6k .FXeWmnE3160iZJ_CoOrDlE2mwA_.ItzuE4zpeKMxXvtaKJZk6d57zQtFrEZoqxEHqihGLIRirvv nrGJoOFc0GBZ3GRieRPX9qXgTJNCAsWP9r93eNHz7Z5P60r3p.n9KxxhacytXtkHYpNwb3i7d.lu GUzQtFI_7AhNSDLYb6tpyQCHejBqxCCw5gLGKrQsfOMFXX3XZeEAkDpwuicf8dIT2FY5.b9Xc7xK JFMxdizLjWQxYYwmhH.ODYUVpkjYzwltaWMKUwfe_N9YpNWtfdo4jFpODHKshoCru0bSx725iKIv ktUFCcujJXdT_PuNHfR0QduMWnlBhjCUaKVSxM2HyQWJMeQg1h3JW6rhC8BeczZyViQM_ENA27Kc RD9UXY5BriUGTW7H.RWYuUOImc7u8Oi5ezQkTGRiyr6YNShjFjcnNNhz4l06PZNhI3MK5ynyuOl9 OVSpd_jZj1NnGUl1ItBRrrMNbGl.Xd0pEFDCUsOAQDfMFHaoSBEHaGEpuXy4IOwG5ugYsBDV8Vbr ZMC.BuWLnbTHfQrefIArRnPa0PF9HcL8bQXfOeAyxcyFq7DdjeEquQ1R1v8u3aDfCUROhktZDupU W8S5tSxqbVsFd6yaXYEqwAvmwJrjbAulMdGb_j56MzudFI9RjZWgjpwQo1gx6Z0AJMNB5xI271ao 5OV3UNjYPk_JI76HPi7YvsHaKsJ7spcdn70QubMwnwZ342PSB6.y7_8YtaowIMMLwTAqLI0X2DfM .ziXlv6sQaCpFt.E151c.jeiXn9J34ZYzu007Tp0Ovi.oulJ_aGsASIXLziJCpkp0n3U0PrLVIRA nWw9m0C6cWjn8.TEJ3k9OAEnciYRgbswSttZIaYVqv2LI1X7rsLXQPnOa0wJToqD0XQqP_9bg1YJ 6SKL2hh1.Ts5CeytdYRGySCPtnjPlnIw1KXYEWJMKiBLGiHbWjfagZ4lSD8gF1SqyMnsV8NQzdiZ MCuxQBmokqm.0QodGqiYDFcHE.lu6btSZ.7KCrmYP7Mp0C5Vdq8orDpV9_GzUTc.9sGxOSVOz72D _zDEPU8mV_TIx9hCkr88J8VJ6FgsBsXh4EZp5OLWfNK3Gr9qPxF3LhddKI29g9W_bg0MHQQbo6bG oOUTRQZnalOTlY9THEMct3IDR65QjkqGCb_pUmQzbM5hD1g42FcsC_2mWQ9OfftP87VFS6DJ5.Mw qZ.58L9AciGQrRxqW2qoGv2p7R4LuWRk125b0w6RYj1XQGiitfOWlmBRMau.GY7zS7moIU3eo9fC JRYyMXLmDcS5VAEcuUJQLnRCwfEYKu.qVS_.zUZ6uM_6d5r.ZvRTDXHyq0kTdDZ5OcIK1CbvXPHt PpelDKtJaoIeYcKIu0WbaT787WmhkBPwBa92mcBthRTrCKU_L1waJoEVWbssayuqnTr6RxioqYBU frmO1TKsoA7LL12lR_Dn1DN1a5DBQzNNFnW9KEccw69AhrBGtlKoPGu4DJQmaj_0TIEM3oVjq4ja TnUjBO9qxmrLbtLdzFrHPxlb3c_xVcct_Ifzjds8o2nWBVDIWFGgE0fIlLWCqPS.8hqOXB1lG8nl rwcCxw6IGUroKwE2Dunm1YUxd1FrT3_gbl2hJxg7ydwm2EnrKSlPP0A0QkhD_o2i3w.CiW6ckNhs iFkGJJ4BkBoc5Appf89ZL2fCpYbElLMExVuXKqSCErzTut6iUsmD_JQyn_CkGUOHHIl_0Md5H2kz 5VT5JatsJwna5ShwNJ_JsTSHnwjyj9yHRVWGyT7gUIumLmxxLoC8jbTZwxQL633o1R6H54kJucg0 HpQw4iQJ_UTVUsoWQbA.rDp8C9XoUeaaoNEJMYHGBdbldgsxxVQ0ox3BxR7YAiTkflUu8wPk5N_I - X-Sonic-MF: X-Sonic-ID: edc91cfa-9aa0-43d3-8e9f-617c766779c6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jan 2024 19:15:24 +0000 Received: by hermes--production-gq1-5c57879fdf-7xbd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 408391154ef3711b8dc91d55fda0d5ec; Mon, 29 Jan 2024 19:15:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: noatime on ufs2 From: Mark Millard In-Reply-To: <10218883.mV2X7mr0Zk@ravel> Date: Mon, 29 Jan 2024 11:15:10 -0800 Cc: Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <13F49F4E-4DC6-45E6-9CCF-25C17ACF63E1@yahoo.com> References: <12921270.kl7XSLc1hW@ravel> <74B030A5-6141-4FE2-AE8C-79548B82FAF0@yahoo.com> <10218883.mV2X7mr0Zk@ravel> To: Olivier Certner X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TNygL1RxYz45tK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 29, 2024, at 02:27, Olivier Certner wrote: > Hi Mark, Hello. Let me start out by indicating that some bike shed sessions are useful overall, even if not contributing to crucial matters. I do not see withdrawing from continued participation with new material as disqualifying of any of the rest of the overall effort in a bike shed session. Given what has already occurred in the session, I've nothing significant to add to the accumulated material and am trying to avoid adding less significant material that wastes effort/time. >> I'm confused: I go to the trouble to produce the same end result >> as your suggested change of defaults would produce, ending up >> with no recording of access times. >=20 > That's nice of you, but unfortunately that's missing the point. = First, you claimed to "seriously care" about access time, so I simply = asked about your use cases, which you have not talked about. Second, = your suggestions do not (in fact, cannot) produce the same end result as = what I'm suggesting (change of default, or have a sysctl to control the = default). I've already listed three use cases in an answer to Warner = that can't be covered by modifying '/etc/fstab', and two of them that = can't by just specifying mount options to mount(8) on the command-line = (the auto-mounters). I tried pointing out that my limited usage context is too narrow to make a reasonable generalization from for the overall problem. Auto-mounting is a good example that I'll point out relative to my usage context: What auto-mounting? But auto- mounting should be considered. I had to try to span beyond my usage context to form the options that I expressed. To only consider my usage would have been inappropriate. I can not use my usage context to justify coverage of that additional attempted span. Much of the overall usage is in that "additional attempted span". I will adjust and deal with whatever happens overall. That is something I know I can do for my usage context. >> . . . > . . . >=20 > Is 'noatime' not being the default the biggest problem we currently = have in FreeBSD? I agree it isn't. However, it doesn't mean there is = no value in it. On the contrary, I think it is very important that the = project has sane defaults that match contemporary uses: It reduces the = need for tweaks, which serves both beginners but *also* seasoned = administrators. This is in isolation a very small step in this = direction, but there have been others and more will come. Collectively, = they can build up to significant additional value for the project. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 29 21:19:45 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 4TP1Qx6LLnz59R6Z for ; Mon, 29 Jan 2024 21:19:53 +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 4TP1Qx5qjMz4RyP; Mon, 29 Jan 2024 21:19:53 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706563193; 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=Tg1PoPyJOEtY4JLsKHkfq59xKgtTzddpeXZXyZJDVzk=; b=L0insHcG6s9cmycOHXXsrcKvCZ1m4/0CrJgArwef+eSXIXO8KT6XaFRnWEJrs05Q2At6fw qcsV73ZqvnWaFCGbUHNG+GdZzDusEm2vjEltT9B8lbQT/TkfwHXIDgK0O+c/sgtfLVJ0Tv RiOzWr2HpsQIRaXLcQrQby2TZJUAoHpf/GDitK0UOaYFUoJdSzSzB7VaGvrb7BsUQJtV3s hWl6tJ3j4XXhKGBuA4LC3yJQDM2HzSb6Br0/YoxOTw5YmAxt7XN0H+QR9DzYj8OXrYX3Z7 GLWFuTJq4zBJ7zfjglFFJU7nOQfpM1dm4+0/9emdXx95eHXndpYc4HR1O8X4rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706563193; 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=Tg1PoPyJOEtY4JLsKHkfq59xKgtTzddpeXZXyZJDVzk=; b=yEQnGcaF+KxCwfmbkZS7kk7EwSNz0RXhth5UuoGmejxNyn2L/2rufdOeEMJVcsk9Zv2mFa DNwWhT4Na03vhzPY9ZeyWma2wy/yse2iUZo2qjt2NjUAMtjlqNqGiZsxsePnjKl3+YtfLF PUxAmVwVZuAy45vqlElpXuiATfZIFs/xXmSYW3aHitbAkTqOe0xApUV8VealL1HAan2HLj woOOfE9Ncw7TwoJUIAg+hpKBWvXeY4X6/H/51M0YLyA6zQ5gUXGoPKVu5TTrLxrNFYZEdt 88TnEJNtItK9KEf6bGjVRmIuRftcOhHKUgMj/TAx5/GTA0YYvz83JyPLeNXykA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706563193; a=rsa-sha256; cv=none; b=GN/BiH1HPSgqDZXWg6nZoWEO11yjUl5fzhU9J73/wV5/FcsvMmM4D8BMcGBtbJUGcleVkA KSEA9txhyHFrdOGh3Gj0XkqM8gSKByk17qqtkcusU+DbjmludEqTrspzKJMc8fKVEyRjR4 bv7N7AAMlbrBfCx+px2lcP0lgCzFoyisLQSiF1rMahoRNRocMMedYGQSH3L9OMsqqche2C GhVtMbA3R8uSu2f2wqRePp+9Ktc4kiMSu5BwCzdasxVubjDx8yB5J50mHCa7EEc1XYazdO fbYJ4+JttUmTGEkxQZBQMDKhO6Nc0SzRzVsdaoMUMfrqbZoLs3buKYJLNm3tSA== 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 4TP1Qx2WMxz1LmC; Mon, 29 Jan 2024 21:19:53 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mark Millard Cc: Current FreeBSD Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 22:19:45 +0100 Message-ID: <4102492.E50ot47v4H@ravel> In-Reply-To: <13F49F4E-4DC6-45E6-9CCF-25C17ACF63E1@yahoo.com> References: <10218883.mV2X7mr0Zk@ravel> <13F49F4E-4DC6-45E6-9CCF-25C17ACF63E1@yahoo.com> 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="nextPart1727467.TmH3gSYhMb"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1727467.TmH3gSYhMb Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Mark Millard Cc: Current FreeBSD Subject: Re: noatime on ufs2 Date: Mon, 29 Jan 2024 22:19:45 +0100 Message-ID: <4102492.E50ot47v4H@ravel> In-Reply-To: <13F49F4E-4DC6-45E6-9CCF-25C17ACF63E1@yahoo.com> MIME-Version: 1.0 Hi, > Let me start out by indicating that some bike shed sessions > (snip) > Much of the overall usage is in that "additional attempted span". Ok, so it seems I've misunderstood what you were saying or your intent in this regard. > I will adjust and deal with whatever happens > overall. That is something I know I can do for my > usage context. With a sysctl knob defaulting to 'atime', you won't have to change anything. Thanks for your participation. Regards. -- Olivier Certner --nextPart1727467.TmH3gSYhMb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW4FnEACgkQjKEwQJce JieAyQ/7BaRGru1h4zAaBIn2tZ6oJqywCRARbFoecQUALHz08Eanyiajjjf4XaLM fYMDDav7ai3qhBJyMqvajLBPJJJgHRCT4NDdCff53cSYQ2Hld9IY9P2YR/EMPHVF 30zb/AHZW6AhiY/O5reUXcEgpb1byniyetrNaPo6U9ryobBui12AoP6mlG+F/6hB 45ZNWd5TWzKCXvb4qCNI/qEWGSELolLQHyiu5QV54makXk5mMWIXe8Y02kSWnUMy IzJg++aULZiJaKH+eL+VeSQ/SLyP0J+oebeBVadxJ6TJLNAZSLSwlHfuIigZwSRh ZiYHK4DI1ozFCPtFl4z4qGt9Y6UT05v+ZRTsvEx8RLdKBx0qatjooaYtwJ5i1bOS twPS1ub2zrCALYWYNtiFao3qSkfQnWoluNdSsM/iq25GfMA6iHJ+R9A0HFES2J6d VXc8c/L0IMBeX8lkyg8VUxypYuUHuZdCOzICJ8nG+aAT3T3cX04vJB6Vvko63R9C UtFOL6cF0IbfMEpe7Mfeb6Z6RtGULpsw88uw1m7WW9gH3lciquWLzkGwPxapRMsp A70dhimNchoFK6mDsOa8GZAgTywH7YZ+3pLbSTmWZfqdqyFpXK9QqlGusXO49hVY jKqFQw1nfMyM7EK6Zcho99A9nsob32J2Q/Slp0bqGimM4rQRZ04= =dV1l -----END PGP SIGNATURE----- --nextPart1727467.TmH3gSYhMb-- 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-- From nobody Tue Jan 30 00:21:13 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 4TP5SS2HXQz57mbS for ; Tue, 30 Jan 2024 00:21:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TP5SS0Tfkz3xBT for ; Tue, 30 Jan 2024 00:21:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-55ad2a47b7aso3312593a12.3 for ; Mon, 29 Jan 2024 16:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706574086; x=1707178886; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=clYv60kkb1n4AEWQNtbKQ9rFCK9AzfEqWQwiS1Q3Umw=; b=SvSYRdOwC5n7p1PsWfla84woavPCRvq1g8QELPfCzuhbYM0AYMoazYnWZwA6cGGRv1 nsPN01Fwhjd1DB0hJmjgXiv+J3RfAuRJmG4xHtr28cq1mQnbc7cbh42xuSzFsNT13Tfa 0vj3sq1WxJotxhQ64i+CXH4PQ4VPkt3PHqxtqmKKMyv5sYa/1J57AXtmFQ/g1a8Ye22i alKY1xaYIqXZIrXESJ0xhGelkTsJzXTUsOOl56KHEQR/EeLkk/NLLAJx847D50Y35YMg m9ansE//Vs3s0Mk4STAsTMK/E+LdM4qe0Lq/m5tSdwdeYA76CMZvwKG9kp4yYCblBIqi T23A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706574086; x=1707178886; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=clYv60kkb1n4AEWQNtbKQ9rFCK9AzfEqWQwiS1Q3Umw=; b=OOsCfoV2IMXEQ3tuJfVLlXze8L6n74CCPxjM62LbiD2/Ksdd/C+LBzM8eaymaPLhwv jaEv9QsJ9Kc0AtLAglzoJLN3UAbHvvgruHGds6pxtM9fYMclC2ukiHKIIK8lzqCKTJAH TvrpWDTdJNz5HxNui7tACTz2wOUmh8OlEuXqxlCtP6TqoGiVJCf+rAlbvWVMhmi+yUy5 AzgEH1dsCadadmK3qovNj7WKGL/5GrMAp3GysmMajQlA8pRIBMuqc3i1tltXs97dMey2 O7cdeUCYzzRY3LzUR7+fYFITI57zNcTrUQnEg+E8ugScE7DJRF4cNd063y6CN387nivF AohQ== X-Gm-Message-State: AOJu0YyffaR94lFM3wzm1DfgB4/7od3nJRSo+0yYuLKEDvJJbHCMT7Pj WskpYApUir8qTnkOMiR8PghED35AQ0axBMcT5VarXsyQbQ6T71X38qyUgKZ5jqzEJSPq/9BdRXI reUrf+8a04vCct1LnDU7pZyI1BIiPP3Hd4ShsqA== X-Google-Smtp-Source: AGHT+IHJyBrybjVleoDWzKwrIh3R3X2zzV/er1ltO3zVQPib0Qf8qDwHHzCp9sHXu/MqNHQ9LS0KzRNVxW9ABI4tiv8= X-Received: by 2002:a05:6402:35c4:b0:55d:20f2:11c9 with SMTP id z4-20020a05640235c400b0055d20f211c9mr5464532edc.25.1706574085253; Mon, 29 Jan 2024 16:21:25 -0800 (PST) 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 References: <11453367.ZaXhgXhNnV@ravel> <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net> <3896441.telDhacX5M@ravel> In-Reply-To: <3896441.telDhacX5M@ravel> From: Warner Losh Date: Mon, 29 Jan 2024 17:21:13 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Olivier Certner Cc: Mike Karels , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000227b2a06101ebeba" X-Rspamd-Queue-Id: 4TP5SS0Tfkz3xBT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000227b2a06101ebeba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 29, 2024 at 2:31=E2=80=AFPM Olivier Certner = wrote: > 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 defaul= t, > > especially if it is to be set via the kernel environment from > > /boot/loader.conf. That's an obscure place to find file system default= s. > > 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 ve= ry > early). > I strongly oppose this notion to control this from loader.conf. Root is mounted read-only, so it doesn't matter. That's why I liked Mike's suggestion: root isn't special. > > 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 ag= o, > 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. > I disagree. I think Mike's suggestion was better and dealt with POLA and POLA breaking in a sane way. If the default is applied universally in user space, then we need not change the kernel at all. We lose all the chicken and egg problems and the non-linearness of the sysctl idea. > > 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 startu= p > > 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, implemente= d > in the kernel). > If it's in fstab as default, then it would be read by whatever updates things in user space. > > 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 wit= h > > 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 use= d > > for VM images and SD card images. Anyone building a root file system b= y > > 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 cover= ed > 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) an= d > converting that specification to tunables passed to the kernel. > I really like Mike's idea. It obviates the need for the sysctl entirely. It gets around the need to update loader.conf as well. It concentrates the change in one place and does so in a way that's not at all atime focused: It could also be generalized so that the FSTYPE could have different settings for different types of filesystem (maybe unique flags that some file systems don't understand). > > 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 optio= n > > 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). > I don't like this, because it is atime focused. atime is a trivial little optimization that really isn't worth the effort for the vast majority of things. However, it would be nice to have some way to specify another layer of defaults, like we do for rc variables, loader variables, etc. mount is currently missing that generality. One could also put it in /etc/defaults/fstab too and not break POLA since that's the pattern we use elsewhere. > > It would be plausible to set the default(s) in rc.conf instead, althoug= h > > 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 thi= nk > > 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 sysct= l, > not always obeying it is what I would think is the real POLA violation. > What would be the reasons to depart from this scheme? > I don't think the case for sysctl has been made. It's a big, inelegant hammer that can be solved more elegantly like Mike suggested. And it can be used for more than just atime: it can be used for any option or set of options you want. It's agnostic to why you want to do it. It follows the 'tools not rules' philosophy the project has had for decades. Anyway, I've said my piece. I agree with Mike that there's consensus for this from the installer, and after that consensus falls away. Mike's idea is one that I can get behind since it elegantly solves the general problem. Warner > Thanks and regards. > > -- > Olivier Certner --000000000000227b2a06101ebeba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 29, 2024 at 2:31=E2=80=AF= PM Olivier Certner <olce@freebsd.org= > wrote:
= Hi Mike,

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

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

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

I strongly oppose this notion to control this f= rom loader.conf. Root is mounted read-only, so it doesn't matter. That&= #39;s why I liked Mike's suggestion: root isn't special.
= =C2=A0
> It also seems undesirable to add a sysctl to control a value that the<= br> > 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= ).=C2=A0 I think this consistency is important.=C2=A0 Perhaps all auto-moun= ters 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 app= lications should use mount(8) and not nmount(2) directly).=C2=A0 Even if th= ere were no obvious callers of nmount(2), I would be a bit uncomfortable wi= th this discrepancy in behavior.

I disa= gree. I think Mike's suggestion was better and dealt with POLA and POLA= breaking in a sane way. If the default is applied universally in user spac= e, then we need not change the kernel at all. We lose all the chicken and e= gg problems and the non-linearness of the sysctl idea.
=C2=A0
> 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 r= ead-only.
> It could be updated by mount when remounting read-write from the start= up
> scripts.

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

If= it's in fstab as default, then it would be read by whatever updates th= ings in user space.
=C2=A0
> Instead, I'd like to propose that the default be
> specified in a new entry in /etc/fstab, where it would be much more ob= vious.
> For example, a line could be placed at the beginning like:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0# Device=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mountpoi= nt=C2=A0 =C2=A0 =C2=A0 FStype=C2=A0 Options
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0non= e=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default noatime,...
>
> It could be retrieved with getfsspec("default") in the fs_mn= ntops field.
> I wouldn't include this entry when iterating through the whole fil= e with
> getfsent() to avoid confusing existing programs.=C2=A0 Then mount, and= other
> utilities such as zfs create, could check it explicitly.=C2=A0 It shou= ld 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 wit= h
> noatime being the default.=C2=A0 It would be in the pre-configured fst= ab used
> for VM images and SD card images.=C2=A0 Anyone building a root file sy= stem by
> hand would have to deal with this to set a default.

That could be great.=C2=A0 And it's not necessarily in contradiction wi= th a sysctl.=C2=A0 If we have the latter, setting the default could happen = through it and could be done by some startup script.=C2=A0 Then, the only t= hing not covered is the root filesystem, but even this is fixable by parsin= g the default line from the loader itself (it already parses '/etc/fsta= b' after all) and converting that specification to tunables passed to t= he kernel.

I really like Mike's ide= a. It obviates the need for the sysctl entirely. It gets around the need to= update loader.conf as well. It concentrates the change in one place and
does so in a way that's not at all atime=C2=A0focused:=C2=A0 It= could also be generalized so that the FSTYPE could have different settings= for different types of filesystem (maybe unique flags that some file syste= ms=C2=A0don't understand).

=C2=A0
> I would then have the mount program look up and apply the default for = things
> like mounting a file system manually.=C2=A0 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 bei= ng in charge of applying them as the defaults.=C2=A0 It implies that mount(= 8) should know some fixed old defaults, irrespective of the sysctl values.= =C2=A0 As evoked in another mail, I think the choice of defaults is really = an administrative matter.=C2=A0 If some scripts really need 'atime'= to work, I would think that the administrator should not change the defaul= t to 'noatime', else make sure these scripts explicitly pass 'a= time' (or use a line in '/etc/fstab' that specifies 'atime&= #39;).=C2=A0 Doing the latter seems to be exactly the same effort as having= the same scripts start to use '-D' (whether by configuration or di= rect modification).

I don't like th= is, because it is atime focused. atime is a trivial little optimization tha= t really=C2=A0isn't worth the effort for the vast majority of things. H= owever, it would be nice to have some way to specify another layer of defau= lts, like we do for rc variables, loader variables, etc. mount is currently= missing that generality. One could also put it in /etc/defaults/fstab too = and not break POLA since that's the pattern we use elsewhere.
=C2=A0
> It would be plausible to set the default(s) in rc.conf instead, althou= gh
> that is more convenient for shell scripts than C programs. It would be=
> possible to read output from something like "sysrc filesystem_def= aults".
> 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 defau= lts in '/etc/fstab'.

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

To be clear, when you say mounting without options, there are two cases wit= h mount(8):
- Either a single argument referencing some line in '/etc/fstab', w= hich could well specify an explicit 'noatime' or 'atime', i= n which case of course it should apply, not the global default.=C2=A0 If th= e fstab line doesn't specify either one, should the global default appl= y?=C2=A0 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 de= fault value.=C2=A0 Simplicity and consistency are key to make this mechanis= m useful.=C2=A0 Administrators should not be put in a position where which = options are going to be applied is not obvious to them.=C2=A0 Once they hav= e set the sysctl, not always obeying it is what I would think is the real P= OLA violation.=C2=A0 What would be the reasons to depart from this scheme?<= br>

I don't think the case for sysctl h= as been made. It's a big, inelegant hammer that can be solved more eleg= antly like Mike suggested. And it can be used for more than just atime: it = can be used for any option or set of options you want. It's agnostic to= why you want to do it. It follows the 'tools not rules' philosophy= =C2=A0the project has had for decades.

Anyway, I&#= 39;ve said my piece. I agree with Mike that there's consensus for this = from the installer, and after that consensus falls away. Mike's idea is= one that I can get behind since it elegantly solves the general problem.

Warner
=C2=A0
Thanks and regards.

--
Olivier Certner
--000000000000227b2a06101ebeba-- From nobody Tue Jan 30 07:53:06 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 4TPHVs3NWBz58KHn for ; Tue, 30 Jan 2024 07:54:13 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPHVr5lVqz4sCQ; Tue, 30 Jan 2024 07:54:12 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1706601238; 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=xgLNwlZwuAAZJOyyfXGpeeG5rGQaQVUiZpg3RGKCoGA=; b=1debEQgHtEhJg7yQP+f7NJtZpjphZJRRRRDcvXGGTzaVPZHcGcjTpRr8BdGt1H2X3zefVk Xgj5CbAk93Znq2bO/D7kj7BdtmD530Bqqe0zPDJzi1agH5FmVIfmU/3T+0TtVh9lLMKrq0 DDEPCXRB8aCFWROixr6EfN0X5/x7xe3XcAV4XMZfjdnPssGak2lICjsj3rQiNHgkEs6LtK vpQyh7LN74A7ORPqWwQAzRgLDZJsw4G1OXlsygafcvtYofAu1jZptELfWVIIg0Kgpxa+Nl 8Qb7Gz8l2GTgudqroTA9tmRjC2pN+kDj1gYFGYsdQlyWxF36iYZHLPbpp/M9wQ== Date: Tue, 30 Jan 2024 08:53:06 +0100 From: Alexander Leidinger To: Warner Losh Cc: Olivier Certner , Mike Karels , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-Reply-To: References: <11453367.ZaXhgXhNnV@ravel> <6430CD93-B4D1-49D6-A39B-B8BCF424258F@karels.net> <3896441.telDhacX5M@ravel> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_53eb568801c96d0fa085e1e2ea2426aa"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4TPHVr5lVqz4sCQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_53eb568801c96d0fa085e1e2ea2426aa Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-01-30 01:21, schrieb Warner Losh: > On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner > wrote: >>> 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. > > I disagree. I think Mike's suggestion was better and dealt with POLA > and POLA breaking in a sane way. If the default is applied universally > in user space, then we need not change the kernel at all. We lose all > the chicken and egg problems and the non-linearness of the sysctl idea. I would like to add that a sysctl is some kind of a hidden setting, whereas /etc/fstab + /etc/defaults/fstab is a "right in the face" way of setting filesystem / mount related stuff. [...] > It could also be generalized so that the FSTYPE could have different > settings for different types of filesystem (maybe unique flags that > some file systems don't understand). +1 nosuid for tmpfs comes into my mind here... > One could also put it in /etc/defaults/fstab too and not break POLA > since that's the pattern we use elsewhere. +1 > Anyway, I've said my piece. I agree with Mike that there's consensus > for this from the installer, and after that consensus falls away. > Mike's idea is one that I can get behind since it elegantly solves the > general problem. +1 Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_53eb568801c96d0fa085e1e2ea2426aa Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmW4qvIACgkQEg2wmwP4 2IYpvw//cu7vY0OfkJje0v0rZ7fuu5zJl4AoWTRult/0uNKhfcU9sj/K+Pif82WX vZ8aRlQquhnRUEK/n+ltIjQj7hKgqFaGVsymu2gUpA5mxVmOgPRYUwGbhsyLYjEC d5Lyp8OCyCIsNbWQNe1/Y4UWBlzrR5BCF/8hiWMQJVRJ7wXew0I4NiNJrfNf3ptz s4AcV8kNdt9X72ArD5p/wjuc5VcnM7OJP15k58OoKfNV5S1XHH1pFXIJceTLYLMz 9/p0LeyaJbUnzqSSbiSu97znBIdIkZuFh9MA5bfyj6ttg6DF2Tnun4UtkOl7zUtl sTVziXjQCoeyX1cpC7aDxGZGIXlR36XmA6+zJOLfeC3TOqIPz61IHLPGe+kXuqrp Xjodi8sWd7GAylnO3viMxRUcxHCjNhwXtFruSNvO4eRBWktZ02/XGlYFR9RUS83G senjvfaQupVz+pXnr0JluohlJhE8Y+PX8fC7Gat8bfPWcwIJGr4orTe+lIPffuL7 j1JqK6TXwIJO6JDX/TTXZC7KmxYhpB4fchDqgtxqUO6AOQ+xfkC3xog6CG6dlXbs 6A20zsorvj+vUTrzYPSP+BJHK5d/pFnB9XzZ5EQwHFdVA0COuhQdI5ZH6vd92qTd kTFSfNxB8OD0V/8q3TYK1Im9BxoBdgOFX5Xd0XSkyh4lWdvelFA= =CERi -----END PGP SIGNATURE----- --=_53eb568801c96d0fa085e1e2ea2426aa-- From nobody Tue Jan 30 09:00:35 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 4TPJzc6KbMz58QqN for ; Tue, 30 Jan 2024 09:00:44 +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 4TPJzc589nz41KY; Tue, 30 Jan 2024 09:00:44 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706605244; 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=+ZAx7momUPAaRB4eKUIfo6rCyxAs2oICgxt5FBs7B6k=; b=fiRv+N1POQajatko5hs8KvSCyNV6GyyJHVGbZr/Krbb2acD8JghYrJpMqHeYjDP5QT2aFX /zLph6L+IUQjhxsdzYBY4jWSrZD1kq773Yar9LWkfffmpPDbWi0LVil3HRvti86KxobnsY iBPQImhO5WqkUvGbZZIjjhm3B1lo6WFd0fqJ1X3PCbnBjPhy0HVay2M4u4lCVCPcN0pdhN 40MCoohOSE/bJpu5PHhtjb0STD15cqqRsR/wGBJxf0sWTxhHbMHH/AHciyB7IyqB6uPbtB mpRopdUe80a+BfNJ2ZaD+1XqsokIkaSkLOjADzA3wLvEPHwTtc9Jky952Yn3vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706605244; 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=+ZAx7momUPAaRB4eKUIfo6rCyxAs2oICgxt5FBs7B6k=; b=A58CzKrLdeDHc6jxrU8GISeDY5le+KvZdDZD9UaLG49abPq01szO+O7VuOjeCTdvEwWkjP 5HGwtH9LX59wYrFS/nVvV7PL2gircPxA27WxNk2p8YHe0Eeno8Vz711+wrC+Np2fT32yiO bhABo0OPkLS6y1U0tH8puA3obD0bqEIsqWTkwn9En5bYOz59IwrNU+TQDYH872Q2qBU9Kr 3jhaNyQwtHhcnyR7K/QvD5RRPjsKBjy5dz5+Upyr41wDGLLdm+x+YnLN6CWeFZptkkXBHb WFwzNUfuFaKdeRihyGlZNDnYIrivOhU2wndH2joUztgav8JAvi7fC6kaV0msIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706605244; a=rsa-sha256; cv=none; b=i42o/fs+pQOk6gtHcv/KiQvAHEOGTaCn5SKqRxEWCEAssUK3qm1CjtSuJKdJOjLgJriubK YKeqEuAxTNStYe4O247Bk8U70tWvfetvcmC4fvQUFq2s21RuXn/NZ2gsrsKbWP25ddNJhk kgSpMaPEo/wn/nsJ/c2d6EzPuAj68qAFMNNC6bHTgE5ux2H4phGlVixqwSaFMegwr3Qb5Y OZc0kwqArsi+7dstAuF9fJlBWn64rvSs6fBzo4wUiBXdy2Q7HI/3zuR/K+glzHn98P2VWd 8FUiqwZbf2mjbVrsoouISywXx+0Cg7bkosGSwcU3k6hgdvEt7gdR9qZ5tRCFJA== 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 4TPJzb6XFVz1ZL1; Tue, 30 Jan 2024 09:00:43 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Warner Losh Cc: Mike Karels , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 10:00:35 +0100 Message-ID: <1732771.R3xgXyqmLP@ravel> In-Reply-To: References: <3896441.telDhacX5M@ravel> 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="nextPart4015718.3Q9M2VvjI4"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart4015718.3Q9M2VvjI4 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Warner Losh Cc: Mike Karels , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 10:00:35 +0100 Message-ID: <1732771.R3xgXyqmLP@ravel> MIME-Version: 1.0 Hi Warner, > I strongly oppose this notion to control this from loader.conf. Root is > mounted read-only, so it doesn't matter. That's why I liked Mike's > suggestion: root isn't special. Then in fact there is nothing to oppose. You've just said yourself that root is mounted first read-only. As Mike already said, it is remounted r/w in userland later in the boot process. I just re-checked the code, because I only had a vague recollection of all this, and can confirm. I mentioned the need to modify '/etc/loader.conf' as a possible consequence, not as a goal. Given what we have established, there is no need to change it at all. The root FS is thus in no way more special in the sysctl proposal than with Mike's (assuming it doesn't rely on sysctl), this is an independent property due to the boot process design. > > > 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. > > > > I disagree. I think Mike's suggestion was better and dealt with POLA and > POLA breaking in a sane way. If the default is applied universally in user > space, then we need not change the kernel at all. I think applying the changes to userland only is really a bad idea. I've already explained why, but going to do it again in case you missed that. If you have counter-arguments, fine, but I would like to see them. Changing userland only causes a discrepancy between mount(8) and nmount(2). Even if the project would take a stance that nmount(2) is not a public API and mount(8) must always be used, the system call will still be there. And if it's not supposed to be used, what's the problem with changing it as well? Second, we can control what is in the base system, but not other applications, so we can't really prevent nmount(2) to be used. Some of the goals of my proposal include to simplifying things, both in terms of administration but also in terms of the amount of code, and to provide reliable behavior. My current evaluation is that changing userland will require more code changes than the sysctl I propose, and it has all the drawbacks I've just mentioned. What I find great in Mike's proposal is to use '/etc/fstab' to control filesystem defaults, because '/etc/fstab' is already the go-to place for filesystems and already holds options to apply to particular mounts. But again, this is independent of where the mechanism is actually implemented. > We lose all the chicken and egg problems and the non-linearness of the sysctl idea. As already said above, there is in the end no such problem, and it wasn't linked at all with the sysctl idea. On the contrary, with the '/etc/fstab' proposal, if there is no kernel backing, the loader must be modified to parse default options, and then pass them to the kernel (via 'vfs.root.mountfrom.options'), or the script remounting r/w be modified to apply the proper options (or 'mount -u' itself changed to do so). > If it's in fstab as default, then it would be read by whatever updates > things in user space. It's very unlikely that applications would not need modifications in this regard. Mike even said that he wouldn't have getfsent() return such entries to avoid confusing existing programs. Needing specific code makes this point moot (if you have to modify a program to read and process the special lines in '/etc/fstab', you can as well modify it to use sysctl(8)). The real advantage is direct modifications in a text file by an administrator, and this is why I like the '/etc/fstab' idea. > It obviates the need for the sysctl entirely. It doesn't obviate the need for a kernel mechanism (sysctl(8) or else), see argument on mount(8) and nmount(2) above. And once you need a kernel mechanism, sysctl(8) is most probably the best candidate for tunables (why re-invent the wheel?). > It gets around the need to update loader.conf as well. You keep repeating that, but it's false as explained above. > It concentrates the change in one place and does so in a way that's not at all atime focused: It could also be > generalized so that the FSTYPE could have different settings for different types of filesystem (maybe unique flags that some file systems don't > understand). You can also have this with a properly designed sysctl(8) hierarchy. > I don't like this, because it is atime focused. atime is a trivial little > optimization that really isn't worth the effort for the vast majority of > things. Others have disagreed, not going to summarize all the previous mails, there are for anyone to read. > However, it would be nice to have some way to specify another layer > of defaults, like we do for rc variables, loader variables, etc. mount is > currently missing that generality. One could also put it in > /etc/defaults/fstab too and not break POLA since that's the pattern we use > elsewhere. I also think having the defaults in '/etc/defaults/fstab' would be better because more in line with what we're doing for rc(8) and loader(8). This would be at the expense of discoverability for adopters, but it seems to be worth it given it applies to other things and has some logic. > I don't think the case for sysctl has been made. It's a big, inelegant > hammer that can be solved more elegantly like Mike suggested. I think it's the exact opposite. As explained above, the change in defaults must be implemented in the kernel. The inelegancy of the pure userland solution will become apparent in terms of the necessary changes' content, its higher number of lines of code and its intrinsic unreliability in the face of external applications using nmount(2). > It follows the 'tools not rules' philosophy the project has had for decades. FreeBSD is far from being the only project having it. Anyway, I've never proposed anything not in these lines. Can you really argue that the sysctl proposal goes against that? > Anyway, I've said my piece. I agree with Mike that there's consensus for > this from the installer, and after that consensus falls away. Mike's idea > is one that I can get behind since it elegantly solves the general problem. In the current situation, I can back using '/etc/fstab', or probably better, '/usr/local/etc/fstab' to hold default mount options, but I'm strongly opposing a pure userland implementation as long as my objections above are not addressed properly. Thanks and regards. -- Olivier Certner --nextPart4015718.3Q9M2VvjI4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW4urMACgkQjKEwQJce JieWAA//TAbWHw8+hvWfRe20E9iCtBESeb0sib8Zf2eyNYMBabEs82+JYB4zh94m 3XBh0KKaD7/pLPkvxF3FpBJFB6Wkgw2FqpzWYAbSHTLM14xTPQ9RqVExruZ91Tbi 7OA/LHXGthsz7aaSmAqcuax1zi8JiNTEZ/83dDVs5dKKS+A/aY9sEKMC46N+0/EU upthTVCBMgLrNn+xRSetpoX4beMTxQD9eJNU8uolFJmOMPAGRJFdy1SLBXMh7Ia3 atIc+gWdI64XD/R0QUe2PQ+uFhKOLlQcEN6/JI3RReIx5Qfax89IIdCeGQIYXH7p s3ztj9WTJ5lKQc6TgKTuHEidvi2I89aeeENL2nJYDf9U/Ox0DyXC/xVUGz/Fe18B WWCKxVTQ3MUsa4qBp8szENvi8xh4KDUv7SQYonZEcSSEfHq8IGYabAgpp3KYaXDx TbSrcK3Kt3AMgwef5MYIppYXuEXuxE91+aKR5C8uRNKY+bZcEiygK0grAoNiyqDA Cju6rxqCcYkAE1tavonwTI+R0YTjT+l4BwNVwilfaCdaWyzQMJ3wYM9VJNLfRv2c AMM8l9XleohAHf09lW3qFqd/IPgP+fPzZgTIXIPb0LyZHNqW72pbKhAtOAC3ImC0 IsUzLEhHANRPSfAlRR7P2LNcN6mEsUA0YpbG7Kd4DpacjCN4GkU= =YC4T -----END PGP SIGNATURE----- --nextPart4015718.3Q9M2VvjI4-- From nobody Tue Jan 30 09:07:49 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 4TPK7r3n7nz58RSZ for ; Tue, 30 Jan 2024 09:07:52 +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 4TPK7q6sbwz43Xf; Tue, 30 Jan 2024 09:07:51 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706605672; 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=B/sp6rfnk7rttE3ZX7syToE4mYFvj3nv1ggXqr1181Q=; b=xwZkPV8BrbMlGZ0fSJIjfcdBM7ThApYxI9KU0yW+wklgEnTySLQJeOvrWpe7IKnA3zzMq7 e54kbecSPX1I2WbJ4OxCrw3HAQvirKkcnYWmQ6j88GiZAi6oMSde1zSLbUvsl10tdInN1G 3xsUAZuYoS/N0tSd2Nj2oUMp/buiyyW2bGASqPFL7BlWeNdH7WA2VvrHTRBk88KTkt53Qp kF7WCAIDzuusNMqeZQnkEr4oKJAvLA0A/XAFK3/ftN2N+XntjXTfenaD866MkH8pPNmz+S KqUpdNp365DrKXRK9SGEj7lJVw0URJvE6bVea81UtN+Kx8wCnDevZtfdiqElfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706605672; 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=B/sp6rfnk7rttE3ZX7syToE4mYFvj3nv1ggXqr1181Q=; b=R74GfFGUrhkFN0LzA80vnrXU7Bbv4YFDYj48+GAMW00/vN5Qf+GBW4mIfNtYekcyveZYYK hj26lf2CGAn/gttrcma3cm4yL57QlfZbyBz8BazJ85lwD6guvcWKGJ0XyhxzNtf2+W+IXL 78nyG4R39cP04wgheslnaX/uOLp2aSTPBzSIL5yLlvEk6qCCib0AeHu7JucWnEClc13pX3 E/UCkOIzLVM90ypzrTYv9uNXzDZmbxytNxsW7nlfYgKI8SK7//uK7hvEXvWwbpzKbW1hjR 3as+0TF+8E+gspJ1zPS8+MAPk3g3WurbW4I2yZFBpUQ6ApweBiMrGFlTMmynKQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706605672; a=rsa-sha256; cv=none; b=mkxfHV1BWePwRPBjk+NS7xOTeLqoRtEo4uNgY1JQ2SFIoQ1aCN43CcNvjp4P22lFEwtLOo fN32w35BBovnHO9uLqPBQr9S2RbOes8Ua9rFBTZ00ubanLwFSm6SJ75Ge8dLSy49Dhx36y wzhOAZOVjO1WNRUBCFB0Pq/nolBAQ8OM/W+jT3ebAxXuRJuDFyydfTgcqeBPSSwL07Nipq tQVQz4NV/HlebbBlN+3lK6zXU7NDURV2pyRIqMgdr0CeGXAZ9G2k7TAijSvv6MReatrEH4 PBMySelDOCIKS5DgL4Osi5I18Ihq5AXYAZE/EAcsH56K1uGv/LffJ8/l7h+QqA== 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 4TPK7q2k3Lz1ZK9; Tue, 30 Jan 2024 09:07:51 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Warner Losh Cc: Mike Karels , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 10:07:49 +0100 Message-ID: <17777319.KQ3ihp37Q7@ravel> In-Reply-To: <1732771.R3xgXyqmLP@ravel> References: <1732771.R3xgXyqmLP@ravel> 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="nextPart1777891.0TZVoiEtlt"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1777891.0TZVoiEtlt Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Warner Losh Cc: Mike Karels , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 10:07:49 +0100 Message-ID: <17777319.KQ3ihp37Q7@ravel> In-Reply-To: <1732771.R3xgXyqmLP@ravel> MIME-Version: 1.0 > In the current situation, I can back using '/etc/fstab', or probably better, '/usr/local/etc/fstab' to hold default mount options, but I'm strongly opposing a pure userland implementation as long as my objections above are not addressed properly. Typo, '/usr/local/etc/fstab' should read '/etc/defaults/fstab'. -- Olivier Certner --nextPart1777891.0TZVoiEtlt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmW4vGUACgkQjKEwQJce Jico1A//XowLevCu2UQTlPLx8Nj454J9ajejc2ijndO64CUcopTOn+SbL43Sxqz1 4fGKRWRHVcNHAPjWqnG2qxxJxiJ1kLGnDaGAX38K5fMfHmq9k1CJ0s3YytFfY1h/ iA/wXMfq+BuYFJLczQTegCkBtgp1XhyA1dlN/wuwzGLW8JYC/qFrDFNucjsJAOB2 b4qq/9pOXsWLjcBDhiYDGVAsotZvClYHZSX1MnBfdmt/DwqHKksPVkv8FsWqVWSt pP96uN6px1kqbHG/T0/09YB9d5Zcw0+MJhtR9efQK3fiF6RMygZh8XBVE3CikqCp B0/AXmhzn4vX7FzWjQi58D9HX7j5emNdLFqqlUhLUqZ1AHQinf1HC9VNNs/8aX9h Xq1Zc6lsW+XWZglxGrMl1IXlltVz/cxg0SaEDU25X80z8EMPVlGm4gnueQMoaEQZ mbry3Jvdi90NZBTnnc21//5aoY2vjzturTvADv/uUj8qEdoeJwAsoupVHnVjaQGX TRJCB6iqO3UUVIXC2RLt49PRhN0EUUVVYwKI7HUarX0rlIpXEWUmSBp/EacV5TGx lb3FZ9Wtl3ZHgktvz1APB2Kak4zyrHtLrjLth3CAOY1OC5cZwmjR6mhv63d1IfWU x3Ss3Pb8vrp5y0wQBK3b/Sskxw/uMldE8gQ/ztNVgP+Ha8OATMY= =QNL/ -----END PGP SIGNATURE----- --nextPart1777891.0TZVoiEtlt-- From nobody Tue Jan 30 14:49:32 2024 X-Original-To: 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 4TPSk75Nz9z58yWf for ; Tue, 30 Jan 2024 14:49:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPSk63MF0z4qg2 for ; Tue, 30 Jan 2024 14:49:34 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.17.1) with ESMTP id 40UEnW5a031135 for ; Tue, 30 Jan 2024 14:49:32 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40UEnWpt031134 for current@freebsd.org; Tue, 30 Jan 2024 06:49:32 -0800 (PST) (envelope-from david) Date: Tue, 30 Jan 2024 06:49:32 -0800 From: David Wolfskill To: current@freebsd.org Subject: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XCTnwOABrisMOSZl" Content-Disposition: inline X-Spamd-Bar: / X-Spamd-Result: default: False [-0.23 / 15.00]; REPLYTO_EQ_TO_ADDR(5.00)[]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.963]; NEURAL_HAM_MEDIUM(-0.87)[-0.870]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; FREEFALL_USER(0.00)[david]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[catwhisker.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org] X-Rspamd-Queue-Id: 4TPSk63MF0z4qg2 --XCTnwOABrisMOSZl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The machines where I track head (& stable/14) daily get powered off once they have finished their work for the day; this is done via "poweroff". I noticed (this morning) that one of them never actually powered off yesterday. After today's exercises (including the reboot & subsequent poweroff), I saw on the (serial) console: | ... | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3A (S5) | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3B (S5) | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3C (S5) | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3D (S5) |=20 | The operating system has halted. | Please press any key to reboot. So I hit "Enter" and then saw: |=20 | acpi0: Powering system off (and heard the fans stop spinning). And that recurred this morning. So I believe that the issue arose in the transition from what the machine had built on Sunday: FreeBSD 15.0-CURRENT #36 main-n267808-197944948e62: Sun Jan 28 16:22:34 UTC= 2024 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/= sys/GENERIC amd64 1500012 1500012 to what it built on Monday: FreeBSD 15.0-CURRENT #37 main-n267841-0b3f9e435f2b: Mon Jan 29 12:17:47 UTC= 2024 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/= sys/GENERIC amd64 1500012 1500012 Glancing at the typescript from Monday's update/build (197944948e62..0b3f9e435f2b), it looks to me as if there was a fair amount of "churn" in boot-related code, so I will look further into that as time permits. Peace, david --=20 David H. Wolfskill david@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. --XCTnwOABrisMOSZl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbkMfF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5cF8AQDzal8WVvq43G1cMKzj2o6Ek1igF2tkxi73M7ACytBUogEAzPNUJKOsP0/7 PiZLu67m6QKtaMf4FtGMnYI7ljprfg8= =Lm3S -----END PGP SIGNATURE----- --XCTnwOABrisMOSZl-- From nobody Tue Jan 30 14:56:16 2024 X-Original-To: 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 4TPSt74QP6z5903v for ; Tue, 30 Jan 2024 14:56:31 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPSt70f9Nz4s23 for ; Tue, 30 Jan 2024 14:56:31 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-dc68150f46fso2091773276.3 for ; Tue, 30 Jan 2024 06:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1706626590; x=1707231390; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hGa9UbgGl0C2vPXhaPfGIDnwJjfXmo7SKFZ+2alUigo=; b=OhhO8K8xOxB9KbJXJZljZj6mwGoW2NCw0M7eheBeJ0BoAcSwEQXujVKT30QH7WGBPV rNkzz/rkZU0L0MHt2uHLa745M9SG6Hk0kQYfINLgFvnjgHvj7tk+63Fr1XlT0zDwY6DP Qbv/AbYAMlO+ZDG/A7r8podCbOTxLSU4ZjZcfCrcTVTp2x7doe/S8hTqwepQj/Bk61xI OZ9uqh1dyLI0gacv02Xm+CK9qR5HqIpk1/ROl6DZp0ZYOfQLWk4S348zoJDCLnn7Fejp YSFM1EXBjJ2XG9cFicozhPUAalTInZgz2qkF7zXCAVzyIOvloVtKEGc7HUUb+3M0jr7t orWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706626590; x=1707231390; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hGa9UbgGl0C2vPXhaPfGIDnwJjfXmo7SKFZ+2alUigo=; b=sDLy/tug/ZoAsv4xTYAxDl9Rs7gjPvasD+1cZjbJpaBEI18s0rLkP38g6Wql1pwRbM tRLowBoT+gqLIRI/OfWK9rooq3kBx/fUTVdX2kA0xjigNHOHCcEu4G9W9cZc6tQz0Y7z Y4QC4qDfNzV8bF4TeUFep1hdKMofVjCiSXvA6YDLFxrj5rJBSVBGrldPl8p0lG1+bLtE dz8Bh7ugQdaF6D/px1U4k964ZPfdt/ASYwTbYWTkAA+S9jcg4fqMO+FDN7MuQ8Z2u/th VW+Q2Ani0p1WorITwhz2ilU3FL0Sra+P3ylsKQ5EPDpif9Qd5gq6SJBSEAVpSXEYxiBH iqjQ== X-Gm-Message-State: AOJu0YxNoMyLEDu5AwQ0ck0oI6NqwITU8y1jCIn5eZiljZyElUA3578y kg9fuSATGyoTsHH0V1t/Lws+nLeR1qVgruOqyr6Q18yRmvD4GLUJtw0Ama44mhuCfWFwYCakzjs = X-Google-Smtp-Source: AGHT+IEHG4MaBFkHn4JMe7PkVWFIVqqA4/8ikjfmgY0+VWy38R1e240UNvGciunYSOXQMUNnQ/Y0Qg== X-Received: by 2002:a05:6902:260c:b0:dbe:9e31:35f6 with SMTP id dw12-20020a056902260c00b00dbe9e3135f6mr7665019ybb.59.1706626589954; Tue, 30 Jan 2024 06:56:29 -0800 (PST) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id r12-20020a0de80c000000b005f900790763sm3246307ywe.49.2024.01.30.06.56.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jan 2024 06:56:29 -0800 (PST) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-5ff847429d4so47497797b3.1 for ; Tue, 30 Jan 2024 06:56:29 -0800 (PST) X-Received: by 2002:a0d:d287:0:b0:5ff:532e:f3c with SMTP id u129-20020a0dd287000000b005ff532e0f3cmr7919871ywd.15.1706626588796; Tue, 30 Jan 2024 06:56:28 -0800 (PST) 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 References: In-Reply-To: From: Tomek CEDRO Date: Tue, 30 Jan 2024 15:56:16 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b To: current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TPSt70f9Nz4s23 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jan 30, 2024 at 3:49=E2=80=AFPM David Wolfskill wrote: > The machines where I track head (& stable/14) daily get powered off once > they have finished their work for the day; this is done via "poweroff". > > I noticed (this morning) that one of them never actually powered off > yesterday. After today's exercises (including the reboot & subsequent > poweroff), I saw on the (serial) console: Have you tried hw.efi.poweroff=3D0 in /boot/loader.conf ? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Tue Jan 30 15:10:45 2024 X-Original-To: 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 4TPTBk2gHkz590w2 for ; Tue, 30 Jan 2024 15:10:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPTBk0zGhz4v6h for ; Tue, 30 Jan 2024 15:10:54 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.17.1) with ESMTP id 40UFAjv1031587; Tue, 30 Jan 2024 15:10:45 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40UFAjiv031586; Tue, 30 Jan 2024 07:10:45 -0800 (PST) (envelope-from david) Date: Tue, 30 Jan 2024 07:10:45 -0800 From: David Wolfskill To: Tomek CEDRO Cc: current@freebsd.org Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Tomek CEDRO References: 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PV9vq+Q3LhYzdakt" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TPTBk0zGhz4v6h X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] --PV9vq+Q3LhYzdakt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote: > On Tue, Jan 30, 2024 at 3:49=E2=80=AFPM David Wolfskill wrote: > > The machines where I track head (& stable/14) daily get powered off once > > they have finished their work for the day; this is done via "poweroff". > > > > I noticed (this morning) that one of them never actually powered off > > yesterday. After today's exercises (including the reboot & subsequent > > poweroff), I saw on the (serial) console: >=20 > Have you tried hw.efi.poweroff=3D0 in /boot/loader.conf ? :-) > .... No; I don't mess with /boot/*.conf without a (plausibly good) reason. :-) But I can experiment... so I'm trying it now. =2E.. Hmm... I don't see any difference in behavior. These systems each boot using BIOS (vs. UEFI), in case that's relevant. Peace, david --=20 David H. Wolfskill david@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. --PV9vq+Q3LhYzdakt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbkRdV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5d+kAP4tSlRVPsRuUfUOuTPKeSFiqFfED9yzpU7JcF54EEi2ewEA7YLzNMlVFwOB UT5R3zR/mUmhkf8IwGfmh/2JOnF3NgQ= =7dQ/ -----END PGP SIGNATURE----- --PV9vq+Q3LhYzdakt-- From nobody Tue Jan 30 15:49:54 2024 X-Original-To: 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 4TPV5444m1z594Jd for ; Tue, 30 Jan 2024 15:51:04 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPV540kHJz41DZ for ; Tue, 30 Jan 2024 15:51:03 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1706629796; x=1707234596; i=garyj@gmx.de; bh=isgXxNgiLApj7afnPWibC382T40QZUoKhs0E9cGOnLc=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References: Reply-To; b=bkwkaJJx3Ou/DvisGb8ogdmVD131Jei1DDNdgYARXkT2DxlQBFLcm23jiVBDm0Of w76/dmckmNMHMYqnKdSLjyUDPDveYvvKxO5OeTrAYK1DOldq8alnDya0ntvOvt+qM fSDd1VGNRQpHe5gK71QHGf3++yCppBqSuniFqNOOznyFsTzCVHQXucwB52i2mYg6F b3gafvxVt2Zysdpakh6JITGn6dIcaw8gLj2TtueVNItMZTWb2mX2gccHGdoNKDKyH R0doLQn8GZuUWfdW9zP8YdDoHxoqY8pi8G2bmH+GyaCAHoMu9otMZleXIK2tnZk2P uSPcRfHKxHvPpl6K2w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.59.224.160]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N6siz-1qzRFM11vr-018NOa; Tue, 30 Jan 2024 16:49:55 +0100 Date: Tue, 30 Jan 2024 15:49:54 +0000 From: Gary Jennejohn To: David Wolfskill Cc: current@freebsd.org, Tomek CEDRO Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Message-ID: <20240130164954.65b784f4@ernst.home> In-Reply-To: References: Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:jlQfyK2P42gLbrj89iBVG8M4VI5eRa/psB1GwIHBFOAVT659aG9 bugy7RtirPaskxGuBK87PSHd8dMScKbzMtaHFGeDY7U+sj/mQl4cSVJzZuqUnpszieoy7yw hhlJuEuUswqMiPpRUBNLsyV0mX3pGoJMLlKGfIOx0jtuMKIbOhQjFETdmNKWQmReOC/wL0D RUolQZr70rOFL9zs+naog== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:rAzohoIijOY=;DA73y9k1dOciilEmMQ3oBAVKPFS vDLt1RffFD9/m1oDcRbBEHuWROepOHsOOZ0Alc1HtNddtnkeyXn5gi1luxybcA0eg9QHmECqE rvyKiZnrpIiAG7LH9f6maB/1MN2CEmvcaOn6beN+gd3tfD+k7kZsc2JFmrBf8Udq2sTZ9Nn/p Gh4obH5W1rvv2unrYKRq7FIL8S6tIvuWq+KaWNXn2oVNWx+v2viBL6EpYS55NWU/Cu2E+xW4K XJrR7qARTOMXLoM+n99MMZWsKbqnpsILq3prpW3xAdAd+GFKnDNr2/0dFuPWq0yS37i3r6Nsg ohDsrfjMj+/nLT3LuqM4SLQWUukzp2jkc0N7paS+jnX4e1uczfLDICgZ1gRdPaxxex4vkLatO 4IOHtZOOWUWR8hAUlDQCz0mIjQO555ts0Gr/VrTiYHcPtAmTirbaBgQYc4i6XUcwt/Sw5u5sD x88Cn2DULLUhStpdUIEiSVgukIkRAH9niG1t5Bm+YEPYo56iO8OypsR0y1KDB1UKTKMRjw/Wn BN1JuIh6EF1J6cP0U9hkGK0aeYR3mbfVNY4FuO2fhzVwfDY/T6KkS8t4w4zlQ4mOrxXB/UVOq JZhxNwcBbbsE+J4OkKtwLl7Gns8x/ihcCTh4PLnx1QKA2DyXsyDUuXf3zcPznFI4t3/nW7G8u ss+dGBfkj/XcNbyppfZn03RfZjGzfs5Gdm+AEUYu7XhvVEcE/Cwm53n+gYcQ7zHLHE+rt8L0h Sv00BROwaUm/GwKdD3T9LZxfu92jHnCUGDSiv4iCzqX8B7HJF+42FZjFBSj3qN35Rkqzsaunw TbY7xYCVZVnXoW8YnCi2cK1DSMajGIu09ea+EQW10tMRTFzh9ptLCtFu9HgiqnqmgzQWexuyz VpsQT7zQzrajXZ+/ZOx91rYmXkTkU0B1wEwe0ZU3r7kaAiN46kAfLXlDYvbICD8ZikQRFK3oN N9bgQQ== X-Rspamd-Queue-Id: 4TPV540kHJz41DZ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] On Tue, 30 Jan 2024 07:10:45 -0800 David Wolfskill wrote: > On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote: > > On Tue, Jan 30, 2024 at 3:49?PM David Wolfskill wrote: > > > The machines where I track head (& stable/14) daily get powered off = once > > > they have finished their work for the day; this is done via "powerof= f". > > > > > > I noticed (this morning) that one of them never actually powered off > > > yesterday. After today's exercises (including the reboot & subseque= nt > > > poweroff), I saw on the (serial) console: > > > > Have you tried hw.efi.poweroff=3D0 in /boot/loader.conf ? :-) > > .... > > No; I don't mess with /boot/*.conf without a (plausibly good) reason. := -) > > But I can experiment... so I'm trying it now. > ... > Hmm... I don't see any difference in behavior. > > These systems each boot using BIOS (vs. UEFI), in case that's relevant. > I use 'shutdown -p now' and it's never failed to power down my computers. =2D- Gary Jennejohn From nobody Tue Jan 30 16:12:23 2024 X-Original-To: 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 4TPVYl4JYHz596Dd for ; Tue, 30 Jan 2024 16:12:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPVYk6rqWz43sP for ; Tue, 30 Jan 2024 16:12:26 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.17.1) with ESMTP id 40UGCNMn032317; Tue, 30 Jan 2024 16:12:23 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40UGCNQ2032316; Tue, 30 Jan 2024 08:12:23 -0800 (PST) (envelope-from david) Date: Tue, 30 Jan 2024 08:12:23 -0800 From: David Wolfskill To: Gary Jennejohn Cc: current@freebsd.org, Tomek CEDRO Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Message-ID: Mail-Followup-To: David Wolfskill , Gary Jennejohn , current@freebsd.org, Tomek CEDRO References: <20240130164954.65b784f4@ernst.home> 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2ZMu73upmv5ugwIb" Content-Disposition: inline In-Reply-To: <20240130164954.65b784f4@ernst.home> X-Rspamd-Queue-Id: 4TPVYk6rqWz43sP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] --2ZMu73upmv5ugwIb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2024 at 03:49:54PM +0000, Gary Jennejohn wrote: > ... > I use 'shutdown -p now' and it's never failed to power down my computers. > .... I could say the same about "poweroff", up to the main-n267808-197944948e62 -> main-n267841-0b3f9e435f2b transition. And I probably wouldn't have mentioned anything, except that each of the 3 machines (one headless build machine; 2 laptops) I tested exhibited the same change. Note, too, from src/sbin/shutdown/shutdown.c: /* * Test for the special case where the utility is called as * "poweroff", for which it runs 'shutdown -p now'. */ if ((p =3D strrchr(argv[0], '/')) =3D=3D NULL) p =3D argv[0]; else ++p; if (strcmp(p, "poweroff") =3D=3D 0) { if (getopt(argc, argv, "") !=3D -1) usage((char *)NULL); argc -=3D optind; argv +=3D optind; if (argc !=3D 0) usage((char *)NULL); dopower =3D 1; offset =3D 0; (void)time(&shuttime); goto poweroff; (So I believe we are referring to the same code paths, whether by "shutdown -p now" or "poweroff".) Peace, david --=20 David H. Wolfskill david@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. --2ZMu73upmv5ugwIb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbkf518UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5SZ3AP9vdL5wjPYxxxYfSrGv5fJjKBcO5MoD3sz1dOi/EOdKoQD/a8sg+9GGoESq yjtL3e+VQlHAZY2uT071K8ipfZEdGgk= =hM3w -----END PGP SIGNATURE----- --2ZMu73upmv5ugwIb-- From nobody Tue Jan 30 16:31:55 2024 X-Original-To: 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 4TPW1h3pzyz597YP for ; Tue, 30 Jan 2024 16:33:12 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPW1h0J6Bz46FJ for ; Tue, 30 Jan 2024 16:33:11 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1706632316; x=1707237116; i=garyj@gmx.de; bh=bg0/La0+axav5mm6ANeSLsXCoH5Hz/Xm1nix4qXUlew=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References: Reply-To; b=t5vYd8KHiT1+ACD1AkQ5zKiUYj0Wx5Ve+zWyzewPe7eizPnI+0VldefkVtKofAN0 +wlc9NtGO9aNRRBLmXjjadvr6Kpv2sUKje7Yd21pcFA7R6nATN0BMvE17FNBxUkQc goId6UtTiLy+RJKiW7bacCYbKc2xEPvvdKTNGlSfZQzxfjuwZDKz3wch3GumgK/YQ xmTYQa2T8g3BoqcwjH1nve+MXGJ5mXNWpm3hSMPiKul5o1aEIgeXFLZifOcz7KXXn FbUocM7sT4qeo78csGxdwYhOArF+TCAquPVlEA1oqYo+U5bq0S6Gllx5YrnqriAGq LYXXSNZuqo0/xLXKAg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.59.224.160]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTRMi-1rcalU1ETs-00Thxg; Tue, 30 Jan 2024 17:31:56 +0100 Date: Tue, 30 Jan 2024 16:31:55 +0000 From: Gary Jennejohn To: David Wolfskill Cc: current@freebsd.org, Tomek CEDRO Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Message-ID: <20240130173155.45a2bc88@ernst.home> In-Reply-To: References: <20240130164954.65b784f4@ernst.home> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:wKBtUtgj7Q51YYxv6QVnb0NvF6oGEHJ258r/RvmHcibY5QtVJ8V Oy0KP6NThJ2JZsHaGWA7VE0wjrJpYmWVOZ+qjr2ZlEAd/g/r4AEfBlVi+9Z3UEuQR1sHwBQ enOp6wZNyFViP3igdsBAxqW0HODktKEfiroq+nWAc9gPIoy+ZujgAxyWBX/E7llGQHVqhTq Y7ssRr/TdiB6K7sDFsgSg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:8LNDhZHSKdw=;joy06tztGkT43cFr1lWZnKGxky5 LFx5RYmT5fVocOMx6UDrIc46wP7rTd31uaUEpUsDZ6K90D5+wZB4Eb1/cvqfeMjajZeHDvbDq /rjEbD455AprmbzScXZPo11nYapZIOaoMIJ39OxGhCk/5iiRnhTuz8xAXikc//zRHNCZrpwXo reX4IMOz2w944yEAgM2trcZdexEXxIknkNRNiY3DKHzeeGmEX8aUBp71EibEfNRDEdmVZ+922 H6Q8N28NRi+I3AsuSD2rIcydaJeYv0+DQKhzJzPlar4xifpKL/9Pq5HTu9OW1szkIwqJuEZSK oCQko5uwhfpy/SoEyeu+26zd8jeY5S8ywO63dDN25y8kRX4yA92kuGSyHdd/26qQFWN3B5TKz XVSfpsT7EWVWCp48tztbaOUr3uTS9nwP0JTyNDnfIwV1MueQ9V9OMqP9NeiWsKRt/s88dgmd8 AzVxCuRsVaPadE/w9R36YY+qSxXku4eGZ8yQFBPkPpvvSAPRoyn7UKpckgu9y9omxFCqTE78q 3YP5xXfmKPqEtmnUMjHYJU6sGks76t1R89mRa9KwO9tQwILZCfokHb2piqhgrQlZ/jp1IQMz6 4XsRrDGGlRTo7ccD9qRqPPJMOJe3P3rNb1vf217RY6fseAmvW8xPf3t5Bu0qYmEpCx6FpSlFv Uxi2tcWNdOXj8HNl9MzgnDQ/zYIkNQwaBTeXDbboMu+yHDyq6rtrh61XT2+44rdlj66lwPJdy lzhljGf+VvVSFIqfqRkKASr6BQLfdyW9IK5s2ZKF0BG8X7WbBygdwQoRwjq12vyigTrP/AgSG QYhHpPKsUcVByxF30ZWY15PcNZg1l7rcw+OR/9YDTui88NpJlWlm6CZXFaC/3sgSj5HiYLyp+ HGX3pyGL49X1pcNfT7r4RHSa25qC3+FKFJJ0UpCFdLQJqjdBxEG/BxydhO2eaiCiUXmXpPz/6 yucUL3VPqbbM9yWz07rN9wbxA/E= X-Rspamd-Queue-Id: 4TPW1h0J6Bz46FJ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] On Tue, 30 Jan 2024 08:12:23 -0800 David Wolfskill wrote: > On Tue, Jan 30, 2024 at 03:49:54PM +0000, Gary Jennejohn wrote: > > ... > > I use 'shutdown -p now' and it's never failed to power down my compute= rs. > > .... > > I could say the same about "poweroff", up to the main-n267808-197944948e= 62 > -> main-n267841-0b3f9e435f2b transition. And I probably wouldn't > have mentioned anything, except that each of the 3 machines (one > headless build machine; 2 laptops) I tested exhibited the same change. > > Note, too, from src/sbin/shutdown/shutdown.c: > > /* > * Test for the special case where the utility is called as > * "poweroff", for which it runs 'shutdown -p now'. > */ > if ((p =3D strrchr(argv[0], '/')) =3D=3D NULL) > p =3D argv[0]; > else > ++p; > if (strcmp(p, "poweroff") =3D=3D 0) { > if (getopt(argc, argv, "") !=3D -1) > usage((char *)NULL); > argc -=3D optind; > argv +=3D optind; > if (argc !=3D 0) > usage((char *)NULL); > dopower =3D 1; > offset =3D 0; > (void)time(&shuttime); > goto poweroff; > > (So I believe we are referring to the same code paths, whether by > "shutdown -p now" or "poweroff".) > Interesting, I wasn't aware of this. Reading shutdown(8) I see that poweroff is equivalent to shutdown -p now. Thanks! =2D- Gary Jennejohn From nobody Tue Jan 30 18:49:22 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 4TPZ2z00Tfz59MCk for ; Tue, 30 Jan 2024 18:49:31 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPZ2y5Cchz4VWs; Tue, 30 Jan 2024 18:49:30 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40UInNme095113; Tue, 30 Jan 2024 12:49:23 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1706640563; bh=XJiLchbM3/NLWSM1L0nIPuRZ7ppxcrh3OhK0sjrXJ0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=b/6DwUYiALtKuGibk5LWiLKHuy/cl7PuIItwezBndzGZOoqF+CYYA3R9DWP17/ulC r4H1PUOvQ7r6c7JHeYeUBe8MgssgJdReKvJitU6p/0tjG57BBX4N0TIsigPp17g/rR Tp0zm1JuRNqoSe890X0a506AVAKIGAb/mOhlcv7TewlQOh8FbdiIedEEAL/hsz0ipB 5UPVjAxtUS9xc11eO/NEAdk4Ij7/DtHJo0qN2quTB3Q3FnpdHcq9tqbXZcj3j4KiSa Ms6z+7n/gVpnPoaDsIKLz/u4mjNPxtETMdGlsot5t5ujTeSNpZz4Kn1rier9ii/DG1 rnDTJYYHi6jDw== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id fgoaFLNEuWWHcwEAs/W3XQ (envelope-from ); Tue, 30 Jan 2024 12:49:23 -0600 From: Mike Karels To: Olivier Certner Cc: Warner Losh , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 12:49:22 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: In-Reply-To: <1732771.R3xgXyqmLP@ravel> References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> 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: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TPZ2y5Cchz4VWs X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 30 Jan 2024, at 3:00, Olivier Certner wrote: > Hi Warner, > >> I strongly oppose this notion to control this from loader.conf. Root i= s >> mounted read-only, so it doesn't matter. That's why I liked Mike's >> suggestion: root isn't special. > > Then in fact there is nothing to oppose. You've just said yourself tha= t root is mounted first read-only. As Mike already said, it is remounted= r/w in userland later in the boot process. I just re-checked the code, = because I only had a vague recollection of all this, and can confirm. > > I mentioned the need to modify '/etc/loader.conf' as a possible consequ= ence, not as a goal. Given what we have established, there is no need to= change it at all. > > The root FS is thus in no way more special in the sysctl proposal than = with Mike's (assuming it doesn't rely on sysctl), this is an independent = property due to the boot process design. With the possible exception that the sysctl mechanism might then have to apply to mount update. >>>> It also seems undesirable to add a sysctl to control a value that th= e >>>> kernel doesn't use. >>> >>> The kernel has to use it to guarantee some uniform behavior irrespect= ive >>> 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 wi= th >>> nmount(2), I would have to check (I seem to remember that, a long tim= e ago, >>> when nmount(2) was introduced as an enhancement over mount(2), the st= ance >>> was that applications should use mount(8) and not nmount(2) directly)= =2E >>> Even if there were no obvious callers of nmount(2), I would be a bit >>> uncomfortable with this discrepancy in behavior. Based on a quick git grep, it looks like most of the things in base use nmount(2), not mount(2). If they use mount(8), then it's not a problem because mount(8) would be the first thing to get things right. If, by mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= ) uses them rather than the reverse. I also don't remember any admonition not to use nmount(2). mount(8) has a limited set of file system types th= at it handles directly. >> I disagree. I think Mike's suggestion was better and dealt with POLA a= nd >> POLA breaking in a sane way. If the default is applied universally in = user >> space, then we need not change the kernel at all. > > I think applying the changes to userland only is really a bad idea. I'= ve already explained why, but going to do it again in case you missed tha= t. If you have counter-arguments, fine, but I would like to see them. > > Changing userland only causes a discrepancy between mount(8) and nmount= (2). Even if the project would take a stance that nmount(2) is not a pub= lic API and mount(8) must always be used, the system call will still be t= here. And if it's not supposed to be used, what's the problem with chang= ing it as well? I don't think that stance has been taken; nmount(2) is certainly document= ed. But I think that user level changes are required in both cases. First, f= or the kernel to do the right thing, it needs to know if either noatime or a= time has been specified explicitly, or if the default should apply. Otherwise= , the kernel can only force noatime to be used in all cases or none, which I be= lieve is a non-starter. Second, for anything using mount(2), the flags include= only MNT_NOATIME, which can only include two options, not the required three. = It would be possible to add another flag meaning to actually use the state o= f the MNT_NOATIME flag, but that would require user-level changes. Third, if I= understand correctly, mount(8) parses the options and condenses the stand= ard boolean options like {,no}atime into a bit, preserving the last option specified. E.g. if the fstab lists noatime for a file system, and "mount= -o atime ..." is given on the command line, noatime will not be included in the kernel options. The kernel can't tell why, whether nothing was speci= fied or the option was explicit. In theory, three states can be encoded using= nmount; options could include "atime", "noatime", or neither. But that's= not what the current user level does, so changes are required. Given tha= t, it makes the most sense to have mount(8) and others to incorporate the default into their operation, and just give the kernel the answer. btw, see mntopts(3) for where this code would go. > Second, we can control what is in the base system, but not other applic= ations, so we can't really prevent nmount(2) to be used. > > Some of the goals of my proposal include to simplifying things, both in= terms of administration but also in terms of the amount of code, and to = provide reliable behavior. My current evaluation is that changing userla= nd will require more code changes than the sysctl I propose, and it has a= ll the drawbacks I've just mentioned. I think that all of the user code needs changes in any case, for the reas= ons above, so there is no need to change the kernel. > What I find great in Mike's proposal is to use '/etc/fstab' to control = filesystem defaults, because '/etc/fstab' is already the go-to place for = filesystems and already holds options to apply to particular mounts. But= again, this is independent of where the mechanism is actually implemente= d. Encoding the default as I proposed would make it awkward to communicate t= o the kernel. A startup script that ran early enough could parse it and tu= rn it into a sysctl, but the encoding works better for C programs that use the fstab parsing code in mount(8). >> We lose all the chicken and egg problems and the non-linearness of the= sysctl idea. > > As already said above, there is in the end no such problem, and it wasn= 't linked at all with the sysctl idea. I disagree, for the reasons above. > On the contrary, with the '/etc/fstab' proposal, if there is no kernel = backing, the loader must be modified to parse default options, and then p= ass them to the kernel (via 'vfs.root.mountfrom.options'), or the script = remounting r/w be modified to apply the proper options (or 'mount -u' its= elf changed to do so). The loader doesn't need the defaults. My proposal assumed that mount -u would implement the default mechanism, just like mount without -u. >> If it's in fstab as default, then it would be read by whatever updates= >> things in user space. As described. > It's very unlikely that applications would not need modifications in th= is regard. Mike even said that he wouldn't have getfsent() return such e= ntries to avoid confusing existing programs. Needing specific code makes= this point moot (if you have to modify a program to read and process the= special lines in '/etc/fstab', you can as well modify it to use sysctl(8= )). A sysctl would implement the default, but not per-filesystem options. "mount -o atime /var/mail" should not be setting sysctls. > The real advantage is direct modifications in a text file by an adminis= trator, and this is why I like the '/etc/fstab' idea. > >> It obviates the need for the sysctl entirely. > > It doesn't obviate the need for a kernel mechanism (sysctl(8) or else),= see argument on mount(8) and nmount(2) above. And once you need a kerne= l mechanism, sysctl(8) is most probably the best candidate for tunables (= why re-invent the wheel?). Again, I disagree that having the kernel involved is necessary or desirable. >> It gets around the need to update loader.conf as well. > > You keep repeating that, but it's false as explained above. > >> It concentrates the change in one place and does so in a way that's no= t at all atime focused: It could also be >> generalized so that the FSTYPE could have different settings for diffe= rent types of filesystem (maybe unique flags that some file systems don't= >> understand). > > You can also have this with a properly designed sysctl(8) hierarchy. That's yet more mechanism that we don't need. >> I don't like this, because it is atime focused. atime is a trivial lit= tle >> optimization that really isn't worth the effort for the vast majority = of >> things. > > Others have disagreed, not going to summarize all the previous mails, t= here are for anyone to read. > >> However, it would be nice to have some way to specify another layer >> of defaults, like we do for rc variables, loader variables, etc. mount= is >> currently missing that generality. One could also put it in >> /etc/defaults/fstab too and not break POLA since that's the pattern we= use >> elsewhere. > > I also think having the defaults in '/etc/defaults/fstab' would be bett= er because more in line with what we're doing for rc(8) and loader(8). T= his would be at the expense of discoverability for adopters, but it seems= to be worth it given it applies to other things and has some logic. The disadvantage of using /etc/defaults/fstab is that it hides the defaul= ts in a file that didn't previously exist, so people won't know to look ther= e. /etc/fstab is better in that it is most obvious. >> I don't think the case for sysctl has been made. It's a big, inelegant= >> hammer that can be solved more elegantly like Mike suggested. > > I think it's the exact opposite. As explained above, the change in def= aults must be implemented in the kernel. The inelegancy of the pure user= land solution will become apparent in terms of the necessary changes' con= tent, its higher number of lines of code and its intrinsic unreliability = in the face of external applications using nmount(2). I disagree that the kernel can, or should, implement the change in defaul= ts without modifying user level. External programs that use nmount(2) can't= do the right thing *and* follow the defaults, because they don't tell the ke= rnel how they arrived at the options they provide. >> It follows the 'tools not rules' philosophy the project has had for de= cades. > > FreeBSD is far from being the only project having it. Anyway, I've nev= er proposed anything not in these lines. Can you really argue that the s= ysctl proposal goes against that? > >> Anyway, I've said my piece. I agree with Mike that there's consensus f= or >> this from the installer, and after that consensus falls away. Mike's i= dea >> is one that I can get behind since it elegantly solves the general pro= blem. > > In the current situation, I can back using '/etc/fstab', or probably be= tter, '/usr/local/etc/fstab' to hold default mount options, but I'm stron= gly opposing a pure userland implementation as long as my objections abov= e are not addressed properly. We disagree. Mike > Thanks and regards. > > -- = > Olivier Certner From nobody Tue Jan 30 21:12:34 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 4TPdDL5rZcz57bsk for ; Tue, 30 Jan 2024 21:12:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPdDL41XBz4qDn; Tue, 30 Jan 2024 21:12:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-290d59df3f0so3387795a91.2; Tue, 30 Jan 2024 13:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706649169; x=1707253969; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ngm/KP76svoAzxeIeSltHMHDt3QrIZ/uMUqZgiCr8Ag=; b=ERtEqP9S2okZUNHvHsjtuFIpZUQnkjxscziEChGpRUo5LHg/aj+57omEPBmkXDzQNA eG2cLMx593/UEGut7LrT7HLcWmOnNOuds59HCCfmF6dyQN3vLpbVMKL2/BoYhdSuRqb6 y8DPDLf38bY0bBJont2PPKzKH7IVxCbOFfMSKTGoyTwCVsHSqG1z1lx0CqBYgLz3ZtI0 x/4EuZW93UbCPiEhEqF6a0HeXsvoZBUx63YY5mEU8mVgi3JW0xRyroiovam2kYSa/hwi ornWPrlcO19e2o6SXOCSM6ZsLBR1hMCsSd8ZKol9DXm8xhrRZaCi74I9l7FI4zeLCHWh Blkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706649169; x=1707253969; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ngm/KP76svoAzxeIeSltHMHDt3QrIZ/uMUqZgiCr8Ag=; b=Em/g37FruKGQaeGPwAkkdT44UVAI9A1C9zzOA12XMKUnnEognBztYXea6hDcE7qrcH a0UXkKQvCgs4Yzw1f1zXyDOJBY8PJ44riCRqy1OPEDxbGvZsq6SAqWrqm3zIc6iqdWq2 NtCgYbfAlWZVzT+H4WuS7PHTp++m6KVCxBrncyuETE88GCFOaHS1w1wTiaQPnmKCPwdU ZBgo9226C/ERldtY+olKI7NiSHjso+IV3p953vBGFYA7+1lnPKZIzkw/gbRv8dDoqk5O 29svLXfZgIOD/psjZO6jNGYZVL6Pu4WPxNw/af66IdPGA0ec1OikTgnYu9sSBjTO8ZN9 w/hQ== X-Gm-Message-State: AOJu0YzwqwbvoOYvZE2Z81eXm5IfBRNMAlh+KO3k0wGszJgzLcAc//Wx vdMDUr+Bk0lR9fgDPg1im1Ay3EVFTmL6h71qYbOuqZTE26JkyhLxypLPbsAOmv7yDLiLOhfcVZM PoP7naE5/Gn8mCHKJ56GBJ/Tcpg== X-Google-Smtp-Source: AGHT+IHfX75Oeh1HQdAXPQGnyG2K+58XiF5RZ/KOp4Sx6ndtHRSqdN8rMBF1MsPlVUiM6flaKgpC8hiucvLbEo0wk7k= X-Received: by 2002:a17:90a:9f91:b0:290:1f0c:b742 with SMTP id o17-20020a17090a9f9100b002901f0cb742mr7050922pjp.28.1706649168448; Tue, 30 Jan 2024 13:12:48 -0800 (PST) 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 References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> In-Reply-To: From: Rick Macklem Date: Tue, 30 Jan 2024 13:12:34 -0800 Message-ID: Subject: Re: noatime on ufs2 To: Mike Karels Cc: Olivier Certner , Warner Losh , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TPdDL41XBz4qDn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot= e: > > On 30 Jan 2024, at 3:00, Olivier Certner wrote: > > > Hi Warner, > > > >> I strongly oppose this notion to control this from loader.conf. Root i= s > >> mounted read-only, so it doesn't matter. That's why I liked Mike's > >> suggestion: root isn't special. > > > > Then in fact there is nothing to oppose. You've just said yourself tha= t root is mounted first read-only. As Mike already said, it is remounted r= /w in userland later in the boot process. I just re-checked the code, beca= use I only had a vague recollection of all this, and can confirm. > > > > I mentioned the need to modify '/etc/loader.conf' as a possible consequ= ence, not as a goal. Given what we have established, there is no need to c= hange it at all. > > > > The root FS is thus in no way more special in the sysctl proposal than = with Mike's (assuming it doesn't rely on sysctl), this is an independent pr= operty due to the boot process design. > > With the possible exception that the sysctl mechanism might then have to > apply to mount update. > > >>>> It also seems undesirable to add a sysctl to control a value that th= e > >>>> kernel doesn't use. > >>> > >>> The kernel has to use it to guarantee some uniform behavior irrespect= ive > >>> 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 wi= th > >>> nmount(2), I would have to check (I seem to remember that, a long tim= e ago, > >>> when nmount(2) was introduced as an enhancement over mount(2), the st= ance > >>> 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. > > Based on a quick git grep, it looks like most of the things in base use > nmount(2), not mount(2). If they use mount(8), then it's not a problem > because mount(8) would be the first thing to get things right. If, by > mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= ) > uses them rather than the reverse. I also don't remember any admonition > not to use nmount(2). mount(8) has a limited set of file system types th= at > it handles directly. > > >> I disagree. I think Mike's suggestion was better and dealt with POLA a= nd > >> POLA breaking in a sane way. If the default is applied universally in = user > >> space, then we need not change the kernel at all. > > > > I think applying the changes to userland only is really a bad idea. I'= ve already explained why, but going to do it again in case you missed that.= If you have counter-arguments, fine, but I would like to see them. > > > > Changing userland only causes a discrepancy between mount(8) and nmount= (2). Even if the project would take a stance that nmount(2) is not a publi= c API and mount(8) must always be used, the system call will still be there= . And if it's not supposed to be used, what's the problem with changing it= as well? > > I don't think that stance has been taken; nmount(2) is certainly document= ed. > But I think that user level changes are required in both cases. First, f= or > the kernel to do the right thing, it needs to know if either noatime or a= time > has been specified explicitly, or if the default should apply. Otherwise= , the > kernel can only force noatime to be used in all cases or none, which I be= lieve > is a non-starter. Second, for anything using mount(2), the flags include= only > MNT_NOATIME, which can only include two options, not the required three. = It > would be possible to add another flag meaning to actually use the state o= f the > MNT_NOATIME flag, but that would require user-level changes. Third, if I > understand correctly, mount(8) parses the options and condenses the stand= ard > boolean options like {,no}atime into a bit, preserving the last option > specified. E.g. if the fstab lists noatime for a file system, and "mount= -o > atime ..." is given on the command line, noatime will not be included in > the kernel options. The kernel can't tell why, whether nothing was speci= fied > or the option was explicit. In theory, three states can be encoded using > nmount; options could include "atime", "noatime", or neither. But that's > not what the current user level does, so changes are required. Given tha= t, > it makes the most sense to have mount(8) and others to incorporate the > default into their operation, and just give the kernel the answer. btw, > see mntopts(3) for where this code would go. These days most mount options are parsed in the kernel via vfs_getopts(), but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in userspace via the getmntopts() function that lives in /usr/src/sbin/mount/getmntopts.c. I think this is mostly cruft left over from the mount(2)->nmount(2) convers= ion, for generic options that cover all file systems. Personally, I like the idea of the addition of a defaults line in fstab(5), but am not sure what needs to be done for things like auto mounting? I'll admit I do not see what the default value of "(no)atime" is, so long a= s it can be overridden on a per mount basis. A change to what the installer sets= , seems fine to me. rick > > > Second, we can control what is in the base system, but not other applic= ations, so we can't really prevent nmount(2) to be used. > > > > Some of the goals of my proposal include to simplifying things, both in= terms of administration but also in terms of the amount of code, and to pr= ovide reliable behavior. My current evaluation is that changing userland w= ill require more code changes than the sysctl I propose, and it has all the= drawbacks I've just mentioned. > > I think that all of the user code needs changes in any case, for the reas= ons > above, so there is no need to change the kernel. > > > What I find great in Mike's proposal is to use '/etc/fstab' to control = filesystem defaults, because '/etc/fstab' is already the go-to place for fi= lesystems and already holds options to apply to particular mounts. But aga= in, this is independent of where the mechanism is actually implemented. > > Encoding the default as I proposed would make it awkward to communicate t= o > the kernel. A startup script that ran early enough could parse it and tu= rn > it into a sysctl, but the encoding works better for C programs that use > the fstab parsing code in mount(8). > > >> We lose all the chicken and egg problems and the non-linearness of the= sysctl idea. > > > > As already said above, there is in the end no such problem, and it wasn= 't linked at all with the sysctl idea. > > I disagree, for the reasons above. > > > On the contrary, with the '/etc/fstab' proposal, if there is no kernel = backing, the loader must be modified to parse default options, and then pas= s them to the kernel (via 'vfs.root.mountfrom.options'), or the script remo= unting r/w be modified to apply the proper options (or 'mount -u' itself ch= anged to do so). > > The loader doesn't need the defaults. My proposal assumed that mount -u > would implement the default mechanism, just like mount without -u. > > >> If it's in fstab as default, then it would be read by whatever updates > >> things in user space. > > As described. > > > It's very unlikely that applications would not need modifications in th= is regard. Mike even said that he wouldn't have getfsent() return such ent= ries to avoid confusing existing programs. Needing specific code makes thi= s point moot (if you have to modify a program to read and process the speci= al lines in '/etc/fstab', you can as well modify it to use sysctl(8)). > > A sysctl would implement the default, but not per-filesystem options. > "mount -o atime /var/mail" should not be setting sysctls. > > > The real advantage is direct modifications in a text file by an adminis= trator, and this is why I like the '/etc/fstab' idea. > > > >> It obviates the need for the sysctl entirely. > > > > It doesn't obviate the need for a kernel mechanism (sysctl(8) or else),= see argument on mount(8) and nmount(2) above. And once you need a kernel = mechanism, sysctl(8) is most probably the best candidate for tunables (why = re-invent the wheel?). > > Again, I disagree that having the kernel involved is necessary or > desirable. > > >> It gets around the need to update loader.conf as well. > > > > You keep repeating that, but it's false as explained above. > > > >> It concentrates the change in one place and does so in a way that's no= t at all atime focused: It could also be > >> generalized so that the FSTYPE could have different settings for diffe= rent types of filesystem (maybe unique flags that some file systems don't > >> understand). > > > > You can also have this with a properly designed sysctl(8) hierarchy. > > That's yet more mechanism that we don't need. > > >> I don't like this, because it is atime focused. atime is a trivial lit= tle > >> optimization that really isn't worth the effort for the vast majority = of > >> things. > > > > Others have disagreed, not going to summarize all the previous mails, t= here are for anyone to read. > > > >> However, it would be nice to have some way to specify another layer > >> of defaults, like we do for rc variables, loader variables, etc. mount= is > >> currently missing that generality. One could also put it in > >> /etc/defaults/fstab too and not break POLA since that's the pattern we= use > >> elsewhere. > > > > I also think having the defaults in '/etc/defaults/fstab' would be bett= er because more in line with what we're doing for rc(8) and loader(8). Thi= s would be at the expense of discoverability for adopters, but it seems to = be worth it given it applies to other things and has some logic. > > The disadvantage of using /etc/defaults/fstab is that it hides the defaul= ts > in a file that didn't previously exist, so people won't know to look ther= e. > /etc/fstab is better in that it is most obvious. > > >> I don't think the case for sysctl has been made. It's a big, inelegant > >> hammer that can be solved more elegantly like Mike suggested. > > > > I think it's the exact opposite. As explained above, the change in def= aults must be implemented in the kernel. The inelegancy of the pure userla= nd solution will become apparent in terms of the necessary changes' content= , its higher number of lines of code and its intrinsic unreliability in the= face of external applications using nmount(2). > > I disagree that the kernel can, or should, implement the change in defaul= ts > without modifying user level. External programs that use nmount(2) can't= do > the right thing *and* follow the defaults, because they don't tell the ke= rnel > how they arrived at the options they provide. > > >> It follows the 'tools not rules' philosophy the project has had for de= cades. > > > > FreeBSD is far from being the only project having it. Anyway, I've nev= er proposed anything not in these lines. Can you really argue that the sys= ctl proposal goes against that? > > > >> Anyway, I've said my piece. I agree with Mike that there's consensus f= or > >> this from the installer, and after that consensus falls away. Mike's i= dea > >> is one that I can get behind since it elegantly solves the general pro= blem. > > > > In the current situation, I can back using '/etc/fstab', or probably be= tter, '/usr/local/etc/fstab' to hold default mount options, but I'm strongl= y opposing a pure userland implementation as long as my objections above ar= e not addressed properly. > > We disagree. > > Mike > > > Thanks and regards. > > > > -- > > Olivier Certner > From nobody Tue Jan 30 21:48: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 4TPf1C2WJPz57gFK for ; Tue, 30 Jan 2024 21:48:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPf1B3DZHz4y3p; Tue, 30 Jan 2024 21:48:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id UtE1r6OLRGAIJUvxlrCV7L; Tue, 30 Jan 2024 21:48:13 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id UvxjrXz0EWhyfUvxkrBoJZ; Tue, 30 Jan 2024 21:48:13 +0000 X-Authority-Analysis: v=2.4 cv=MenPuI/f c=1 sm=1 tr=0 ts=65b96e9d a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=1QTDH3R-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YwoGRumlfV3EDiC4sgoA:9 a=CjuIK1q_8ugA:10 a=A7PbjfUNzwAiWwc5k9lq:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 6DCA81299; Tue, 30 Jan 2024 13:48:11 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 622C91B0; Tue, 30 Jan 2024 13:48:11 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Mike Karels , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-reply-to: References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> Comments: In-reply-to Rick Macklem message dated "Tue, 30 Jan 2024 13:12:34 -0800." 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: text/plain; charset=us-ascii Date: Tue, 30 Jan 2024 13:48:11 -0800 Message-Id: <20240130214811.622C91B0@slippy.cwsent.com> X-CMAE-Envelope: MS4xfERAhZeBN+oZ3etkJuVLGbH9JwfMqonlDpy8N3gqTuz51ZORxcnIMhnD3aOcUFOTAdwm2Y/YD3cmcxMS1EOTeEoGWXFEFuoc3dBQtMcDUeMYnJTar37n Rfm7vdqFB8/VqFNHjRvn5ea+5UKEllnHm6x6BFVNRuFXZXJg1h1aOr+F89UQSPlf+BH7CXWamVw9mXhTOCBbrcsr2uSET0k70+CDA7Y3EIw6IFA9tabJWRqV breopdTW6xl0pjRKC0Ol4c/M1Q086TiIfvE2LHDYe74i7+4zVlTIhbjuvj3nCDWz9kKqJ7bXnNamIH2S9B2gmg== X-Spamd-Bar: / X-Spamd-Result: default: False [-0.18 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[cschubert.com]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4TPf1B3DZHz4y3p In message , Rick Macklem writes: > On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot= > e: > > > > On 30 Jan 2024, at 3:00, Olivier Certner wrote: > > > > > Hi Warner, > > > > > >> I strongly oppose this notion to control this from loader.conf. Root i= > s > > >> mounted read-only, so it doesn't matter. That's why I liked Mike's > > >> suggestion: root isn't special. > > > > > > Then in fact there is nothing to oppose. You've just said yourself tha= > t root is mounted first read-only. As Mike already said, it is remounted r= > /w in userland later in the boot process. I just re-checked the code, beca= > use I only had a vague recollection of all this, and can confirm. > > > > > > I mentioned the need to modify '/etc/loader.conf' as a possible consequ= > ence, not as a goal. Given what we have established, there is no need to c= > hange it at all. > > > > > > The root FS is thus in no way more special in the sysctl proposal than = > with Mike's (assuming it doesn't rely on sysctl), this is an independent pr= > operty due to the boot process design. > > > > With the possible exception that the sysctl mechanism might then have to > > apply to mount update. > > > > >>>> It also seems undesirable to add a sysctl to control a value that th= > e > > >>>> kernel doesn't use. > > >>> > > >>> The kernel has to use it to guarantee some uniform behavior irrespect= > ive > > >>> 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 wi= > th > > >>> nmount(2), I would have to check (I seem to remember that, a long tim= > e ago, > > >>> when nmount(2) was introduced as an enhancement over mount(2), the st= > ance > > >>> 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. > > > > Based on a quick git grep, it looks like most of the things in base use > > nmount(2), not mount(2). If they use mount(8), then it's not a problem > > because mount(8) would be the first thing to get things right. If, by > > mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= > ) > > uses them rather than the reverse. I also don't remember any admonition > > not to use nmount(2). mount(8) has a limited set of file system types th= > at > > it handles directly. > > > > >> I disagree. I think Mike's suggestion was better and dealt with POLA a= > nd > > >> POLA breaking in a sane way. If the default is applied universally in = > user > > >> space, then we need not change the kernel at all. > > > > > > I think applying the changes to userland only is really a bad idea. I'= > ve already explained why, but going to do it again in case you missed that.= > If you have counter-arguments, fine, but I would like to see them. > > > > > > Changing userland only causes a discrepancy between mount(8) and nmount= > (2). Even if the project would take a stance that nmount(2) is not a publi= > c API and mount(8) must always be used, the system call will still be there= > And if it's not supposed to be used, what's the problem with changing it= > as well? > > > > I don't think that stance has been taken; nmount(2) is certainly document= > ed. > > But I think that user level changes are required in both cases. First, f= > or > > the kernel to do the right thing, it needs to know if either noatime or a= > time > > has been specified explicitly, or if the default should apply. Otherwise= > , the > > kernel can only force noatime to be used in all cases or none, which I be= > lieve > > is a non-starter. Second, for anything using mount(2), the flags include= > only > > MNT_NOATIME, which can only include two options, not the required three. = > It > > would be possible to add another flag meaning to actually use the state o= > f the > > MNT_NOATIME flag, but that would require user-level changes. Third, if I > > understand correctly, mount(8) parses the options and condenses the stand= > ard > > boolean options like {,no}atime into a bit, preserving the last option > > specified. E.g. if the fstab lists noatime for a file system, and "mount= > -o > > atime ..." is given on the command line, noatime will not be included in > > the kernel options. The kernel can't tell why, whether nothing was speci= > fied > > or the option was explicit. In theory, three states can be encoded using > > nmount; options could include "atime", "noatime", or neither. But that's > > not what the current user level does, so changes are required. Given tha= > t, > > it makes the most sense to have mount(8) and others to incorporate the > > default into their operation, and just give the kernel the answer. btw, > > see mntopts(3) for where this code would go. > These days most mount options are parsed in the kernel via vfs_getopts(), > but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in > userspace via the getmntopts() function that lives in > /usr/src/sbin/mount/getmntopts.c. > > I think this is mostly cruft left over from the mount(2)->nmount(2) convers= > ion, > for generic options that cover all file systems. > > Personally, I like the idea of the addition of a defaults line in > fstab(5), but am > not sure what needs to be done for things like auto mounting? automountd will require addition of of options to existing configuration. am-utils users can add a default line. Or an addition of a "default" specification, which would make it incompatible with Linux and Solaris. Currently our autofs is 100% compatible (minus the /net bug) with both. > > I'll admit I do not see what the default value of "(no)atime" is, so long a= > s it > can be overridden on a per mount basis. A change to what the installer sets= > , > seems fine to me. > > rick > [...] -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Jan 30 22:57:20 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 4TPgY12YFgz57ncb for ; Tue, 30 Jan 2024 22:57:25 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPgY10jD6z57Bw; Tue, 30 Jan 2024 22:57:25 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40UMvLr0096469; Tue, 30 Jan 2024 16:57:21 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1706655442; bh=WjYN3M/+FNFuLebD5OGgANkf8BGLVnrpKxg0aFqGpY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=k3yJU4+itHLpvWSM4ZMBEh/t8mWS1dJmz4BAhyLCRCPtvWk96CipdClmINPBhPErr KU08Xq1Pwe1yu3DMuPDOhSsMs/mzf04KtroA/6xNuSeAMhOkQW+y4Ly9FBjSRiYFyB gVe1kT2/uC9LuDITtiMjNKmxNxOaqif6GbtCThNK/IRdnsjiRL1jOrdtGgCxRON0vi 3JCvCneNrd4TKhzjSSilpHlBTfdTqAI7yXR4/LFg+2ISpU8qJtD6Xi35Typz3vxJe0 3hsa4JcHRekAudzLoU+1IOvwbFSH2IHQfq+RvHrb032O+2M5H8l93M7zN36KW+Dzgn ATfM2yzShYDfA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id lAoIJ9F+uWXTeAEAs/W3XQ (envelope-from ); Tue, 30 Jan 2024 16:57:21 -0600 From: Mike Karels To: Cy Schubert Cc: Rick Macklem , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 30 Jan 2024 16:57:20 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> In-Reply-To: <20240130214811.622C91B0@slippy.cwsent.com> References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> <20240130214811.622C91B0@slippy.cwsent.com> 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: text/plain X-Rspamd-Queue-Id: 4TPgY10jD6z57Bw X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 30 Jan 2024, at 15:48, Cy Schubert wrote: > In message om> > , Rick Macklem writes: >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot= >> e: >>> >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote: >>> >>>> Hi Warner, >>>> >>>>> I strongly oppose this notion to control this from loader.conf. Root i= >> s >>>>> mounted read-only, so it doesn't matter. That's why I liked Mike's >>>>> suggestion: root isn't special. >>>> >>>> Then in fact there is nothing to oppose. You've just said yourself tha= >> t root is mounted first read-only. As Mike already said, it is remounted r= >> /w in userland later in the boot process. I just re-checked the code, beca= >> use I only had a vague recollection of all this, and can confirm. >>>> >>>> I mentioned the need to modify '/etc/loader.conf' as a possible consequ= >> ence, not as a goal. Given what we have established, there is no need to c= >> hange it at all. >>>> >>>> The root FS is thus in no way more special in the sysctl proposal than = >> with Mike's (assuming it doesn't rely on sysctl), this is an independent pr= >> operty due to the boot process design. >>> >>> With the possible exception that the sysctl mechanism might then have to >>> apply to mount update. >>> >>>>>>> It also seems undesirable to add a sysctl to control a value that th= >> e >>>>>>> kernel doesn't use. >>>>>> >>>>>> The kernel has to use it to guarantee some uniform behavior irrespect= >> ive >>>>>> 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 wi= >> th >>>>>> nmount(2), I would have to check (I seem to remember that, a long tim= >> e ago, >>>>>> when nmount(2) was introduced as an enhancement over mount(2), the st= >> ance >>>>>> 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. >>> >>> Based on a quick git grep, it looks like most of the things in base use >>> nmount(2), not mount(2). If they use mount(8), then it's not a problem >>> because mount(8) would be the first thing to get things right. If, by >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= >> ) >>> uses them rather than the reverse. I also don't remember any admonition >>> not to use nmount(2). mount(8) has a limited set of file system types th= >> at >>> it handles directly. >>> >>>>> I disagree. I think Mike's suggestion was better and dealt with POLA a= >> nd >>>>> POLA breaking in a sane way. If the default is applied universally in = >> user >>>>> space, then we need not change the kernel at all. >>>> >>>> I think applying the changes to userland only is really a bad idea. I'= >> ve already explained why, but going to do it again in case you missed that.= >> If you have counter-arguments, fine, but I would like to see them. >>>> >>>> Changing userland only causes a discrepancy between mount(8) and nmount= >> (2). Even if the project would take a stance that nmount(2) is not a publi= >> c API and mount(8) must always be used, the system call will still be there= >> And if it's not supposed to be used, what's the problem with changing it= >> as well? >>> >>> I don't think that stance has been taken; nmount(2) is certainly document= >> ed. >>> But I think that user level changes are required in both cases. First, f= >> or >>> the kernel to do the right thing, it needs to know if either noatime or a= >> time >>> has been specified explicitly, or if the default should apply. Otherwise= >> , the >>> kernel can only force noatime to be used in all cases or none, which I be= >> lieve >>> is a non-starter. Second, for anything using mount(2), the flags include= >> only >>> MNT_NOATIME, which can only include two options, not the required three. = >> It >>> would be possible to add another flag meaning to actually use the state o= >> f the >>> MNT_NOATIME flag, but that would require user-level changes. Third, if I >>> understand correctly, mount(8) parses the options and condenses the stand= >> ard >>> boolean options like {,no}atime into a bit, preserving the last option >>> specified. E.g. if the fstab lists noatime for a file system, and "mount= >> -o >>> atime ..." is given on the command line, noatime will not be included in >>> the kernel options. The kernel can't tell why, whether nothing was speci= >> fied >>> or the option was explicit. In theory, three states can be encoded using >>> nmount; options could include "atime", "noatime", or neither. But that's >>> not what the current user level does, so changes are required. Given tha= >> t, >>> it makes the most sense to have mount(8) and others to incorporate the >>> default into their operation, and just give the kernel the answer. btw, >>> see mntopts(3) for where this code would go. >> These days most mount options are parsed in the kernel via vfs_getopts(), >> but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in >> userspace via the getmntopts() function that lives in >> /usr/src/sbin/mount/getmntopts.c. >> >> I think this is mostly cruft left over from the mount(2)->nmount(2) convers= >> ion, >> for generic options that cover all file systems. >> >> Personally, I like the idea of the addition of a defaults line in >> fstab(5), but am >> not sure what needs to be done for things like auto mounting? > > automountd will require addition of of options to existing configuration. > am-utils users can add a default line. Or an addition of a "default" > specification, which would make it incompatible with Linux and Solaris. > Currently our autofs is 100% compatible (minus the /net bug) with both. It looks like automountd already has defaults in place, by class (net, media). The commented-out media line has noatime already, and net may not matter. Our nfs client does not support atime; I don't know about smbfs. Or am I misreading the default auto_master file? Personally, I'm fine with using a different configuration mechanism in automountd. Mike >> >> I'll admit I do not see what the default value of "(no)atime" is, so long a= >> s it >> can be overridden on a per mount basis. A change to what the installer sets= >> , >> seems fine to me. >> >> rick >> > > [...] > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 From nobody Tue Jan 30 23:31:52 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 4TPhJq4kSMz57rNp for ; Tue, 30 Jan 2024 23:31:55 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPhJq2zfFz3xKn; Tue, 30 Jan 2024 23:31:55 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id UswZrX3cjxDxGUxa6rGAoJ; Tue, 30 Jan 2024 23:31:54 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id Uxa4r4qmRZ0jDUxa5rgcQw; Tue, 30 Jan 2024 23:31:54 +0000 X-Authority-Analysis: v=2.4 cv=P8GZhTAu c=1 sm=1 tr=0 ts=65b986ea a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=1QTDH3R-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=kN6B0tGZ_ZzeHCB1OZoA:9 a=CjuIK1q_8ugA:10 a=A7PbjfUNzwAiWwc5k9lq:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 38C0B13EC; Tue, 30 Jan 2024 15:31:52 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 2131F218; Tue, 30 Jan 2024 15:31:52 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mike Karels cc: Cy Schubert , Rick Macklem , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-reply-to: <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> <20240130214811.622C91B0@slippy.cwsent.com> <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> Comments: In-reply-to Mike Karels message dated "Tue, 30 Jan 2024 16:57:20 -0600." 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: text/plain; charset=us-ascii Date: Tue, 30 Jan 2024 15:31:52 -0800 Message-Id: <20240130233152.2131F218@slippy.cwsent.com> X-CMAE-Envelope: MS4xfEidp/oiBeWWxJfzJ7LrP+eeNnnh/pakPTAjOvwQfc08EGbvQB4c1gSplr5Pb+LsFv2e+UU2xWkKUF3zrqm8S4dH17qMckwgm9PDPno1D0tQR5x2zhWJ YPIN4dKtgWeu3P0qZ5r5+xTytwWXE7qyfwYtgVydrEbfPahTDTJeU11XHswKmJFwdST3aMaA5zEpHVTWjV5PII8oIPhNn5nrOqvCkJks5ven+15/UV6+IXFj Me2weTdZyu6zLWGsGFvvSD2I416qhIrctnUq3DZcS3RCxwoU8W1xBKKtcXq4zIMTca/JRZgTTxwMQSdZtlxmIA== X-Rspamd-Queue-Id: 4TPhJq2zfFz3xKn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] In message <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net>, Mike Karels write s: > On 30 Jan 2024, at 15:48, Cy Schubert wrote: > > > In message c > > om> > > , Rick Macklem writes: > >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wro > t= > >> e: > >>> > >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote: > >>> > >>>> Hi Warner, > >>>> > >>>>> I strongly oppose this notion to control this from loader.conf. Root i= > >> s > >>>>> mounted read-only, so it doesn't matter. That's why I liked Mike's > >>>>> suggestion: root isn't special. > >>>> > >>>> Then in fact there is nothing to oppose. You've just said yourself tha= > >> t root is mounted first read-only. As Mike already said, it is remounted > r= > >> /w in userland later in the boot process. I just re-checked the code, bec > a= > >> use I only had a vague recollection of all this, and can confirm. > >>>> > >>>> I mentioned the need to modify '/etc/loader.conf' as a possible consequ= > >> ence, not as a goal. Given what we have established, there is no need to > c= > >> hange it at all. > >>>> > >>>> The root FS is thus in no way more special in the sysctl proposal than = > >> with Mike's (assuming it doesn't rely on sysctl), this is an independent p > r= > >> operty due to the boot process design. > >>> > >>> With the possible exception that the sysctl mechanism might then have to > >>> apply to mount update. > >>> > >>>>>>> It also seems undesirable to add a sysctl to control a value that th= > >> e > >>>>>>> kernel doesn't use. > >>>>>> > >>>>>> The kernel has to use it to guarantee some uniform behavior irrespect= > >> ive > >>>>>> 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 wi= > >> th > >>>>>> nmount(2), I would have to check (I seem to remember that, a long tim= > >> e ago, > >>>>>> when nmount(2) was introduced as an enhancement over mount(2), the st= > >> ance > >>>>>> 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. > >>> > >>> Based on a quick git grep, it looks like most of the things in base use > >>> nmount(2), not mount(2). If they use mount(8), then it's not a problem > >>> because mount(8) would be the first thing to get things right. If, by > >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8 > = > >> ) > >>> uses them rather than the reverse. I also don't remember any admonition > >>> not to use nmount(2). mount(8) has a limited set of file system types th > = > >> at > >>> it handles directly. > >>> > >>>>> I disagree. I think Mike's suggestion was better and dealt with POLA a= > >> nd > >>>>> POLA breaking in a sane way. If the default is applied universally in = > >> user > >>>>> space, then we need not change the kernel at all. > >>>> > >>>> I think applying the changes to userland only is really a bad idea. I'= > >> ve already explained why, but going to do it again in case you missed that > .= > >> If you have counter-arguments, fine, but I would like to see them. > >>>> > >>>> Changing userland only causes a discrepancy between mount(8) and nmount= > >> (2). Even if the project would take a stance that nmount(2) is not a publ > i= > >> c API and mount(8) must always be used, the system call will still be ther > e= > >> And if it's not supposed to be used, what's the problem with changing it > = > >> as well? > >>> > >>> I don't think that stance has been taken; nmount(2) is certainly document > = > >> ed. > >>> But I think that user level changes are required in both cases. First, f > = > >> or > >>> the kernel to do the right thing, it needs to know if either noatime or a > = > >> time > >>> has been specified explicitly, or if the default should apply. Otherwise > = > >> , the > >>> kernel can only force noatime to be used in all cases or none, which I be > = > >> lieve > >>> is a non-starter. Second, for anything using mount(2), the flags include > = > >> only > >>> MNT_NOATIME, which can only include two options, not the required three. > = > >> It > >>> would be possible to add another flag meaning to actually use the state o > = > >> f the > >>> MNT_NOATIME flag, but that would require user-level changes. Third, if I > >>> understand correctly, mount(8) parses the options and condenses the stand > = > >> ard > >>> boolean options like {,no}atime into a bit, preserving the last option > >>> specified. E.g. if the fstab lists noatime for a file system, and "mount > = > >> -o > >>> atime ..." is given on the command line, noatime will not be included in > >>> the kernel options. The kernel can't tell why, whether nothing was speci > = > >> fied > >>> or the option was explicit. In theory, three states can be encoded using > >>> nmount; options could include "atime", "noatime", or neither. But that's > >>> not what the current user level does, so changes are required. Given tha > = > >> t, > >>> it makes the most sense to have mount(8) and others to incorporate the > >>> default into their operation, and just give the kernel the answer. btw, > >>> see mntopts(3) for where this code would go. > >> These days most mount options are parsed in the kernel via vfs_getopts(), > >> but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in > >> userspace via the getmntopts() function that lives in > >> /usr/src/sbin/mount/getmntopts.c. > >> > >> I think this is mostly cruft left over from the mount(2)->nmount(2) conver > s= > >> ion, > >> for generic options that cover all file systems. > >> > >> Personally, I like the idea of the addition of a defaults line in > >> fstab(5), but am > >> not sure what needs to be done for things like auto mounting? > > > > automountd will require addition of of options to existing configuration. > > am-utils users can add a default line. Or an addition of a "default" > > specification, which would make it incompatible with Linux and Solaris. > > Currently our autofs is 100% compatible (minus the /net bug) with both. > > It looks like automountd already has defaults in place, by class (net, media) > . > The commented-out media line has noatime already, and net may not matter. net doesn't work anyway. On my todo list. > Our nfs client does not support atime; I don't know about smbfs. Or am I > misreading the default auto_master file? Personally, I'm fine with using > a different configuration mechanism in automountd. IMO the only reason to mount all filesystems noatime would be to reduce wear on SSD devices. ZFS is easy. Local filesystems in fstab should be easy today without source changes. A simple script or ansible playbook can easily handle this. I've done this locally on my laptop, the only machine here with an SSD. Regarding network filesystems such as NFS and CIFS, that would be the responsibility of that machine's admin for application to that machine's local mounts. Network filesystems need not have such facility. I suppose any mounts performed through devd would also need to be handled. Considering all the different places we'd need to add support for defaults I'm beginning to see the point of a global knob. Regarding the utility of atime, some apps are sensitive to atime, which is why Veritas NetBackup by default tries to maintain atime after backing up (reading) files. (With a config option to disable this in lieu of maintaining correct ctime.) I think regardless of what we do implement a default mechanism we need to be cognizant to not change the out-of-the-box default. And to reiterate, I'd prefer fewer distinct changes with an isolated change. Less to go wrong and less to miss during implementation. I.E. cheaper on developer resources. Simple is better. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed Jan 31 13:18:47 2024 X-Original-To: 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 4TQ2g84yTpz58WPP for ; Wed, 31 Jan 2024 13:19:00 +0000 (UTC) (envelope-from olivier@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 4TQ2g84SKgz4fMd for ; Wed, 31 Jan 2024 13:19:00 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706707140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o8rge9tO+SwP/BXsxxJglTTjt7ZtZ3V1lVNBPpvyK/I=; b=XaF73/acNfM4fSkxCJ3wq9oux4jihoIpZJt6zpTd7u2SeVJipQkSsYKImHeUeAqNMASYo8 NkRV3gSlHjaDvuuuuPmkBo/hJXuVcF6ajCunRQ7U9loSPH4uDURLjnOhAiI6TOvV+E4pUF kGq7eIQTScWfvFXzbJN913yWm8w8ZHaDPipi0PjM9O4AY+oMU4gxMJYlcNswfwfz6qKGl1 mghd7OnLTUcgDUROrF9NF3ti2ZixpS/Xqc5FM+NjtZ94BUEux9rMUmD6hiDOtwGMesMzaF Y5nmoK3g4K2V8cBSKworsirXZGh/haQ1o4NHnBbCbLQUtZPEf9r8FESMep044A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706707140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o8rge9tO+SwP/BXsxxJglTTjt7ZtZ3V1lVNBPpvyK/I=; b=Qrtw9t/I6QG7tACyGmvC05XfIQs41WVrBUk3cWMyokmvWgB5YvkonQfuNN180Wg8mpMtPY cIUCYOtWHjQchWwCPg5RqQO2Zq2Z8ndRffSzHYSrPhxd7jc+LBz/D6JWqPlpy8p6T9Mtrp TlpNkqrv9PkbXkQMekGtGeSprHWtrheJh3hANSr3RhbgTScCwTpFPvbr5BtPJFY09gUvJh 3zF0W9E6zuCmBFVb+zs8C+97NPaX1WdiRRAbZe33/K/KvdcADqO80JVNFuPbgXhrQqqCTL Vhh/IHjuoKnohUqBr3uTxn1WEY715K80iVW0qAjY6NysFP4oRPXvkXuEdCRfyg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706707140; a=rsa-sha256; cv=none; b=sWmpIQPNLSVw8doPCc7zLZqxg54q/AKZQ2HBKBpXKYHOIly19Xy6TKZQrxgmW9P0WBrlrZ 5dEHOEkvjHHVR9nj7cMScJLTnkiwd4Tf6ddF3O1JuC2T+suvr+h8tr3fGcCyrafuxjc673 WkaN4jSCwAKFPM1dYRN1+Z54e9REPmJM/S5e+ZvMnHrCEcbNB4j/Aif1kTVeTG69RATI1x Xs0oX4C9yM3fEonBphNabJdNflQNgnsGEKDChX+J+kDRE0n2SNqU1qmBlwFALdc5jJKOqY pxAz6Bv5miBcqCUtwRGdV7cpaDBvx2Dba8DFoxDbJyft/lY5UkzDPq/mKZhW7Q== Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQ2g83NkZzfMy for ; Wed, 31 Jan 2024 13:19:00 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-783e22a16d4so59922685a.0 for ; Wed, 31 Jan 2024 05:19:00 -0800 (PST) X-Gm-Message-State: AOJu0YweqUP5N0eYcO5JSkLLyUJJzf3qrM+stADSlJTFobRIbdUcybxA GEPaJ8N812HbUo0GA8NFHpXtiVdH5DXBbsCLUxsa82NP2O3ey6D6j86bmy712CybZS6GAi1WHw0 HA6gMRz2jR5wXmzSjfYBjne1+BSk= X-Google-Smtp-Source: AGHT+IFNDE7bSeV/dVdldXjBzJ4G40MBdiEelGhWy5jlIZkdjFVwd/dbS5LaVFECCAdNxyKLME9gghlfpYXbKvpB6a0= X-Received: by 2002:a0c:b39c:0:b0:681:7c9d:9f15 with SMTP id t28-20020a0cb39c000000b006817c9d9f15mr4400034qve.59.1706707139467; Wed, 31 Jan 2024 05:18:59 -0800 (PST) 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 References: In-Reply-To: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 31 Jan 2024 14:18:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b To: current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c8a7da06103db819" --000000000000c8a7da06103db819 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2024 at 3:50=E2=80=AFPM David Wolfskill wrote: > The machines where I track head (& stable/14) daily get powered off once > they have finished their work for the day; this is done via "poweroff". > > I noticed (this morning) that one of them never actually powered off > yesterday. After today's exercises (including the reboot & subsequent > poweroff), I saw on the (serial) console: > > Same problem here. --000000000000c8a7da06103db819 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jan 30, 2024 at 3= :50=E2=80=AFPM David Wolfskill <= david@catwhisker.org> wrote:
The machines where I track head (& stable/14) daily= get powered off once
they have finished their work for the day; this is done via "poweroff&= quot;.

I noticed (this morning) that one of them never actually powered off
yesterday.=C2=A0 After today's exercises (including the reboot & su= bsequent
poweroff), I saw on the (serial) console:


Same problem here.

--000000000000c8a7da06103db819-- From nobody Wed Jan 31 13:53:07 2024 X-Original-To: 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 4TQ3QY3fKgz58ZQ2 for ; Wed, 31 Jan 2024 13:53:09 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ3QY1zvRz4l2x; Wed, 31 Jan 2024 13:53:09 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40VDr8Ve001167; Wed, 31 Jan 2024 07:53:08 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1706709188; bh=lLSBp68DEz6EHmEC4q885SOTgRVWLi3sBloYduyFhzk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=W2bckpH4s8vA1r+I2IC2NEKlnyEGZNc0+c7aASHC8+wFaiQz4C+srC8NpLWIVx0Jg 8yuEdxbBSk3CyWvvBRNc1/xSU+AJQBRlTLx/sj8psG5ecaG+9RbQeqvvABtgYObwyj zG9pGQmK7GK0RVvjUzcnxcFhT4bhDEAjhWZd1T/AUWPa7fxHzg7nkgSGOB60OZxzjO Q4wwhAPmJVg4QYeYiFQ3WAoQ1YvdacvgTiL3xLMVv3qL7q5IzFdYbq7cScvqcdC1K+ ssGZ6zN+xpyCyC706uyvp1wZPxo+iS/cgz53ZpEiPThPgrwx1srMaDsTE3KmA6clDN m7HbC6Hz3gTCQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id HuWXBcRQumWNBAAAs/W3XQ (envelope-from ); Wed, 31 Jan 2024 07:53:08 -0600 From: Mike Karels To: =?utf-8?q?=22Olivier_Cochard-Labb=C3=A9=22?= Cc: current@freebsd.org Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Date: Wed, 31 Jan 2024 07:53:07 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: In-Reply-To: References: 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/alternative; boundary="=_MailMate_855F3FCF-256C-464B-9192-9A375F33D1B1_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"plain":[58,458],"uuid":"57D4F6A6-2A9F-44C5-A2B6-57C4188B2C9F"}] X-Rspamd-Queue-Id: 4TQ3QY1zvRz4l2x X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] --=_MailMate_855F3FCF-256C-464B-9192-9A375F33D1B1_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote: > On Tue, Jan 30, 2024 at 3:50 PM David Wolfskill > wrote: > >> The machines where I track head (& stable/14) daily get powered off once >> they have finished their work for the day; this is done via "poweroff". >> >> I noticed (this morning) that one of them never actually powered off >> yesterday. After today's exercises (including the reboot & subsequent >> poweroff), I saw on the (serial) console: >> >> > Same problem here. I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed shutdown ordering. Mike --=_MailMate_855F3FCF-256C-464B-9192-9A375F33D1B1_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 31 Jan 2024, at 7= :18, Olivier Cochard-Labb=C3=A9 wrote:


On Tue, Jan 30, 2024 at 3:50=E2=80=AF= PM David Wolfskill <david@catw= hisker.org> wrote:
The machines where I = track head (& stable/14) daily get powered off once
they have finished their work for the day; this is done via "poweroff".
I noticed (this morning) that one of them never actually powered off
yesterday.  After today's exercises (including the reboot & subseque= nt
poweroff), I saw on the (serial) console:


Same problem here.


I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed
shutdown ordering.

Mike

--=_MailMate_855F3FCF-256C-464B-9192-9A375F33D1B1_=-- From nobody Wed Jan 31 14:01:35 2024 X-Original-To: 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 4TQ3cK5X4Bz58Zyq for ; Wed, 31 Jan 2024 14:01:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ3cK3nXsz4mF0; Wed, 31 Jan 2024 14:01:37 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.17.1) with ESMTP id 40VE1ZNg049231; Wed, 31 Jan 2024 14:01:35 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40VE1Zdt049230; Wed, 31 Jan 2024 06:01:35 -0800 (PST) (envelope-from david) Date: Wed, 31 Jan 2024 06:01:35 -0800 From: David Wolfskill To: Mike Karels Cc: =?iso-8859-1?Q?=22Olivier_Cochard-Labb=E9=22?= , current@freebsd.org Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Mike Karels , =?iso-8859-1?Q?=22Olivier_Cochard-Labb=E9=22?= References: 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; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TasYTi0UyF9D089R" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TQ3cK3nXsz4mF0 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] --TasYTi0UyF9D089R Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 31, 2024 at 07:53:07AM -0600, Mike Karels wrote: > On 31 Jan 2024, at 7:18, Olivier Cochard-Labb=E9 wrote: > ...=20 > > Same problem here. >=20 > I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed > shutdown ordering. > .... Yes; I have been corresponding with Andriy, and have confirmed that backing out that change restores the previous behavior. He's looking at some additional things, but he can speak to that. Peace, david --=20 David H. Wolfskill david@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. --TasYTi0UyF9D089R Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbpSv18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5Y6bAPkBWt3CSI9MgfoFhrS65f4VFCZDv8Iq24m4zUvfwn162QD8DjL+xoRTHyQ4 LMz1GNM+g3s87IXyeVmOS8Ldb0GfFAE= =6G5P -----END PGP SIGNATURE----- --TasYTi0UyF9D089R-- From nobody Wed Jan 31 14:03:03 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 4TQ3fK42Vhz58bHl for ; Wed, 31 Jan 2024 14:03:21 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ3fK1fmtz4nWh; Wed, 31 Jan 2024 14:03:21 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6dfb9594cd9so992038b3a.2; Wed, 31 Jan 2024 06:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706709799; x=1707314599; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aLuj6U45mG7cbkdmCG3WgDWqNm/0AJW9HXDDtiYP5Nc=; b=V1Q8VfaSuXHhRJPXPkzc0QhgrNDQKbbe9U0yjXCpkNc+yejRL2am2vN4wzXUxFYjSB 46Q141q8/IVwZAe4xpRrlwDLSmACyQv6oi8zyUUDrgGOuL3YJKh1fsESJeowIHEcsAW3 nIqw/+dbLP2+DqzxeYERWQxw5WZ/2FVvHJ/wKxDHSR7MnaWteVoeqR6eg8AEyhZWATq4 8kMil+tm9mcMMNPGNxZumfvf2znfBj85Vog/v+vGsG2ozSzMcPOROqGaAzXKDNQchB/R evzOmeO4/j7Nhz2Wqguvj5GrQvVI1so6MacxMrvOlBRD6Z7fbZFTuWRiEViD7l+Ekqgf 6vcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706709799; x=1707314599; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aLuj6U45mG7cbkdmCG3WgDWqNm/0AJW9HXDDtiYP5Nc=; b=HLigD2GjcZp4gKvU/ou9j2Gf7LGxw+OGJOho01MoZ24kUdj5Ocr5GdsSCiq8emn63/ GTD4iRuFxMKrJ/kTHN4gCEVIlZ9fS6+a+QoKYP1y2Xi8bEZYelUWh5Un4+VJiTTeHHbI 7476OTpv7ZZwzCSDYXY5WvifBjgSmbjTD2hSI7O4jvVDgz0fXaagWdLeXjL2OxeCyNQt zMZCBjoZMQamKOR6HpW/HUb+l+yqab6yS/HqbBcAgnq3m4aKkqclPweEATkYTOTP1uBH SdWJOMWLkmivvySNsgFRsHeGMVWA95nYbIoqeTPhZW+RzEhl2wwmaM5ALLa9ktUEqZy5 S4RQ== X-Gm-Message-State: AOJu0YwweZkMzBKJA94QEftYqlV4lu1va5XDe+WGdmhJq1Y+wtZ0PaLO W0XCaKgqwQHdG0j06/s5Tnm5F67Z0zmgNm0/jAsN3YANUwmd2H+ilxvHvi8UcW4JWE0OVklWBFD FrXXWF+MzEC6pHdv6MnRZioY5zod6NV0= X-Google-Smtp-Source: AGHT+IGwJHyecNF+FptAdhlrHAw1642B7NEeQSU/pxf90UbZ++nA4WAuavlSsjKrhxwQYs6PoB0HaXwtjBm/e1gnxM8= X-Received: by 2002:aa7:8110:0:b0:6de:4da:72c6 with SMTP id b16-20020aa78110000000b006de04da72c6mr1683871pfi.9.1706709799132; Wed, 31 Jan 2024 06:03:19 -0800 (PST) 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 References: <3896441.telDhacX5M@ravel> <1732771.R3xgXyqmLP@ravel> <20240130214811.622C91B0@slippy.cwsent.com> <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> In-Reply-To: <3F6CF45C-3D34-4DA6-9B81-337EB70BB328@karels.net> From: Rick Macklem Date: Wed, 31 Jan 2024 06:03:03 -0800 Message-ID: Subject: Re: noatime on ufs2 To: Mike Karels Cc: Cy Schubert , Olivier Certner , Warner Losh , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TQ3fK1fmtz4nWh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jan 30, 2024 at 2:57=E2=80=AFPM Mike Karels wrote= : > > On 30 Jan 2024, at 15:48, Cy Schubert wrote: > > > In message > om> > > , Rick Macklem writes: > >> On Tue, Jan 30, 2024 at 10:49=3DE2=3D80=3DAFAM Mike Karels wrot=3D > >> e: > >>> > >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote: > >>> > >>>> Hi Warner, > >>>> > >>>>> I strongly oppose this notion to control this from loader.conf. Roo= t i=3D > >> s > >>>>> mounted read-only, so it doesn't matter. That's why I liked Mike's > >>>>> suggestion: root isn't special. > >>>> > >>>> Then in fact there is nothing to oppose. You've just said yourself = tha=3D > >> t root is mounted first read-only. As Mike already said, it is remoun= ted r=3D > >> /w in userland later in the boot process. I just re-checked the code,= beca=3D > >> use I only had a vague recollection of all this, and can confirm. > >>>> > >>>> I mentioned the need to modify '/etc/loader.conf' as a possible cons= equ=3D > >> ence, not as a goal. Given what we have established, there is no need= to c=3D > >> hange it at all. > >>>> > >>>> The root FS is thus in no way more special in the sysctl proposal th= an =3D > >> with Mike's (assuming it doesn't rely on sysctl), this is an independe= nt pr=3D > >> operty due to the boot process design. > >>> > >>> With the possible exception that the sysctl mechanism might then have= to > >>> apply to mount update. > >>> > >>>>>>> It also seems undesirable to add a sysctl to control a value that= th=3D > >> e > >>>>>>> kernel doesn't use. > >>>>>> > >>>>>> The kernel has to use it to guarantee some uniform behavior irresp= ect=3D > >> ive > >>>>>> 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= wi=3D > >> th > >>>>>> nmount(2), I would have to check (I seem to remember that, a long = tim=3D > >> e ago, > >>>>>> when nmount(2) was introduced as an enhancement over mount(2), the= st=3D > >> ance > >>>>>> was that applications should use mount(8) and not nmount(2) direct= ly)=3D > >> . > >>>>>> Even if there were no obvious callers of nmount(2), I would be a b= it > >>>>>> uncomfortable with this discrepancy in behavior. > >>> > >>> Based on a quick git grep, it looks like most of the things in base u= se > >>> nmount(2), not mount(2). If they use mount(8), then it's not a probl= em > >>> because mount(8) would be the first thing to get things right. If, b= y > >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mou= nt(8=3D > >> ) > >>> uses them rather than the reverse. I also don't remember any admonit= ion > >>> not to use nmount(2). mount(8) has a limited set of file system type= s th=3D > >> at > >>> it handles directly. > >>> > >>>>> I disagree. I think Mike's suggestion was better and dealt with POL= A a=3D > >> nd > >>>>> POLA breaking in a sane way. If the default is applied universally = in =3D > >> user > >>>>> space, then we need not change the kernel at all. > >>>> > >>>> I think applying the changes to userland only is really a bad idea. = I'=3D > >> ve already explained why, but going to do it again in case you missed = that.=3D > >> If you have counter-arguments, fine, but I would like to see them. > >>>> > >>>> Changing userland only causes a discrepancy between mount(8) and nmo= unt=3D > >> (2). Even if the project would take a stance that nmount(2) is not a = publi=3D > >> c API and mount(8) must always be used, the system call will still be = there=3D > >> And if it's not supposed to be used, what's the problem with changin= g it=3D > >> as well? > >>> > >>> I don't think that stance has been taken; nmount(2) is certainly docu= ment=3D > >> ed. > >>> But I think that user level changes are required in both cases. Firs= t, f=3D > >> or > >>> the kernel to do the right thing, it needs to know if either noatime = or a=3D > >> time > >>> has been specified explicitly, or if the default should apply. Other= wise=3D > >> , the > >>> kernel can only force noatime to be used in all cases or none, which = I be=3D > >> lieve > >>> is a non-starter. Second, for anything using mount(2), the flags inc= lude=3D > >> only > >>> MNT_NOATIME, which can only include two options, not the required thr= ee. =3D > >> It > >>> would be possible to add another flag meaning to actually use the sta= te o=3D > >> f the > >>> MNT_NOATIME flag, but that would require user-level changes. Third, = if I > >>> understand correctly, mount(8) parses the options and condenses the s= tand=3D > >> ard > >>> boolean options like {,no}atime into a bit, preserving the last optio= n > >>> specified. E.g. if the fstab lists noatime for a file system, and "m= ount=3D > >> -o > >>> atime ..." is given on the command line, noatime will not be included= in > >>> the kernel options. The kernel can't tell why, whether nothing was s= peci=3D > >> fied > >>> or the option was explicit. In theory, three states can be encoded u= sing > >>> nmount; options could include "atime", "noatime", or neither. But th= at's > >>> not what the current user level does, so changes are required. Given= tha=3D > >> t, > >>> it makes the most sense to have mount(8) and others to incorporate th= e > >>> default into their operation, and just give the kernel the answer. b= tw, > >>> see mntopts(3) for where this code would go. > >> These days most mount options are parsed in the kernel via vfs_getopts= (), > >> but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME i= n > >> userspace via the getmntopts() function that lives in > >> /usr/src/sbin/mount/getmntopts.c. > >> > >> I think this is mostly cruft left over from the mount(2)->nmount(2) co= nvers=3D > >> ion, > >> for generic options that cover all file systems. > >> > >> Personally, I like the idea of the addition of a defaults line in > >> fstab(5), but am > >> not sure what needs to be done for things like auto mounting? > > > > automountd will require addition of of options to existing configuratio= n. > > am-utils users can add a default line. Or an addition of a "default" > > specification, which would make it incompatible with Linux and Solaris. > > Currently our autofs is 100% compatible (minus the /net bug) with both. > > It looks like automountd already has defaults in place, by class (net, me= dia). > The commented-out media line has noatime already, and net may not matter. > Our nfs client does not support atime; I don't know about smbfs. Or am I > misreading the default auto_master file? Personally, I'm fine with using > a different configuration mechanism in automountd. I think the only time (no pun intended;-) this will matter for NFS is if Fr= eeBSD were to adopt support of "relatime", which could be implemented over NFS fairly efficiently. rick > > Mike > >> > >> I'll admit I do not see what the default value of "(no)atime" is, so l= ong a=3D > >> s it > >> can be overridden on a per mount basis. A change to what the installer= sets=3D > >> , > >> seems fine to me. > >> > >> rick > >> > > > > [...] > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e^(i*pi)+1=3D0 From nobody Wed Jan 31 14:09:23 2024 X-Original-To: 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 4TQ3nY52H7z58bvH for ; Wed, 31 Jan 2024 14:09:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ3nY3MX6z4pW0 for ; Wed, 31 Jan 2024 14:09:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2d051fb89fbso37323971fa.2 for ; Wed, 31 Jan 2024 06:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706710175; x=1707314975; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ri7KkPx99BRBqXU6HZJxarV8sn9SvlaJTQw4htJxNDs=; b=Nn2OnSGuaD87+cr+/m6QJDl2wOLCrqCO7j1Ws0/sdTAc/4rKbbqK5fQ1qG910UX8kf j2Kiu2PjhdxVX6gf5/VcTfoiGVaSq5YjZhONVRjXOJ/UQNjL1q2i1tboATLX1xzd805/ AjolQ0V8QRx1a3VH5wc533uXynT5a6TDEE9zKWLlXWokDbH5fD0fW53tCVbK6TfL1sNP iLY7I6t9dhTSxOjZwlGWL4oUZNXhKxOmhguuXnFwWAVt+m18gXMgjfDLb7Vb66lpO6+k 5ZLbm0ORUNp/o7Zur/wNJCIu6Nedk0AXkxOEYQwzSntNon1wXm5zfxVOMPpjJHb2CTCx lwoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706710175; x=1707314975; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ri7KkPx99BRBqXU6HZJxarV8sn9SvlaJTQw4htJxNDs=; b=RHL3oWNA7ZVckYIeTru3SrDEmp53/fB9oAxt2UAL5I79M0kssr5l5VKgHP0Jpw62Xa 4FKBG1dADaypsxEj7LGCdVJaZOPACwadJVlS8jyAKAuhgFL8PXKpXgvb8lHSgitSBUXm 3xa/Tzm23aqCYdcPo0AZm+bTTgw7K4ptBNetDder0tPv+/VBDxizWetuPl3LKZA3x9X7 JOt5ekiv557QEiqp58s72knhzgWioDg3tBQI+ohsSFEwpcUqk8SW7tlDOnsu7Ldd+TkY sL2G84ntuEZ9BEb9FRZO4V9bmUgHA9v1rCDqz5fXdF5H1T33iiuGnzo9kHyb0Ka+pQal IyVQ== X-Gm-Message-State: AOJu0Yzay/X9Jo7+G6gvhkS8WIHDNutKwu/WKaUSqoi0N+EFzJiUIkXG PRsEQ0V+xTtAmD35xwe0+L03x2y+klzIIVRtxEnmPJ8MjESZCsnm04r/bWnLDeRvqAl6g6W+YxV aJUGWpLamdsBU8ZE4ceyXECIACgqZgESFkgcSXg== X-Google-Smtp-Source: AGHT+IHMegeqgHjuHJJh9J797qvNkclxnpUFXABbuPUSYS9fOraCMugvMnoac+Iv0GIaagZAMiixSJmmqgF4uqcGrAs= X-Received: by 2002:a05:651c:200b:b0:2d0:526e:f1ca with SMTP id s11-20020a05651c200b00b002d0526ef1camr1225779ljo.11.1706710175367; Wed, 31 Jan 2024 06:09:35 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Wed, 31 Jan 2024 07:09:23 -0700 Message-ID: Subject: Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b To: Mike Karels Cc: =?UTF-8?B?Ik9saXZpZXIgQ29jaGFyZC1MYWJiw6ki?= , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000bcd55406103e6d71" X-Rspamd-Queue-Id: 4TQ3nY3MX6z4pW0 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000bcd55406103e6d71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 31, 2024, 6:53=E2=80=AFAM Mike Karels wrote: > > > On 31 Jan 2024, at 7:18, Olivier Cochard-Labb=C3=A9 wrote: > > > On Tue, Jan 30, 2024 at 3:50=E2=80=AFPM David Wolfskill > wrote: > >> The machines where I track head (& stable/14) daily get powered off once >> they have finished their work for the day; this is done via "poweroff". >> >> I noticed (this morning) that one of them never actually powered off >> yesterday. After today's exercises (including the reboot & subsequent >> poweroff), I saw on the (serial) console: >> >> > Same problem here. > > > I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed > shutdown ordering > Yea. Almost certainly. I think David is testing a patch from A --000000000000bcd55406103e6d71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 31, 2024, 6:53=E2=80=AFAM Mike Ka= rels <mike@karels.net> wrote:


On 31 Jan 2024, at 7:18, Olivier Cochard-Labb=C3= =A9 wrote:


On Tue, Jan 30, 2024 at 3:50=E2=80=AF= PM David Wolfskill <david@catwhisker.org> wrote:
=
The machines where I trac= k head (& stable/14) daily get powered off once
they have finished their work for the day; this is done via "poweroff&= quot;.

I noticed (this morning) that one of them never actually powered off
yesterday.=C2=A0 After today's exercises (including the reboot & su= bsequent
poweroff), I saw on the (serial) console:


Same problem here.


I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed
shutdown ordering


Yea. Almost certainly. I think David is testin= g a patch from A
--000000000000bcd55406103e6d71-- From nobody Thu Feb 1 00:31:58 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 4TQKbj0nX3z58d5B for ; Thu, 1 Feb 2024 00:32:01 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TQKbj0F4dz4L7p for ; Thu, 1 Feb 2024 00:32:01 +0000 (UTC) (envelope-from gshapiro@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706747521; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=pj5RVe6++r7OvrAD+vuKckOq+JJ/Ji8dKGW3LDGgBEc=; b=uvRAG385UQZLGtunDiv/VzWju+IB0rGLJQ4eniPXV8IKYavqXvcBcCQzod/l8FEBOhSi/t 5f+ACqNrL3FodON3fWMPOuKrjipO8aeNxR2Ugfx/M66AwwEfaAyQRjhAHg0+30Av6Uaiqy dkywKqFhvV61UN2FGOAf0vtZqgA7K5zSCQG8xS7M3vnW0xIsDSIn3PbB/0GOlSbEEgD+mf j7JLNt9w20JfCocvxwO0DUqodZd1gz2BJuFS1B/DbxWNQ1ite7IazElNHkayIQlo3OzdwS M18bTpnEAxr0lGEsKdkAal38FinEwO79E1sDCHH36bAwRK4L33kqQzI2nOaMBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706747521; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=pj5RVe6++r7OvrAD+vuKckOq+JJ/Ji8dKGW3LDGgBEc=; b=V4rGVplFebhK3vbIsRwuva/fFUtnjB1Im6RttsgXmQZsg3fkeqHZAL+4ZBG7lEzxhfTJdn 9tLauIiNXVKbCoUgID1iuMnNKTCqQ+ndjuLvEtznx/w9R1TefrCNHJNvl8DgmnNE4YtQ+B 0IbeWG9LCv49cyOatQe4EYopG87uKjY4yogY6sOHrj9J6KvEH67fMkIz0IhI7fvZKhLpiR /qYbR9j7RPD+ij+6yVpG2GJKjxe5wqmzGlkbutwaumzo2t2+8LcrN9MSNpY1Utuo0r/rKB 8U3QOauUPNS8wwMx5vvaDOCebEd8/edpKrRLvJxbE9sM2NJxc8lnsV+QnqhmUg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706747521; a=rsa-sha256; cv=none; b=JCoNcr9dgXiNQUfLwIvhixyuDblCmxnevv1v2dt7GELlYh9GDqxf4b+lpXyOQWgFryV/3G D5bfvTlzZO5VG0hYndQvJj/w6yNgnAYmF+gwqfDv7oD+dPTtI3rJwHNcL86BSfZ2xxoCSU XsOY4mLwpf+OIsn/S4RbsT9aETaLWCqTImNbmuiXWz1uRrn5vEf2NUFYuXL35ZkiWvTD2+ Raes4apEAq3HdWVsZcM6jyeGZP+exYBm7i8cD8QupLK5eflg/McT54ZjkMlnHv22XH0rsw QtCPpK6IIny55phGzcxVqF6u/oM93rRfSebF8o1EyVsnfto444/dWz1oJZ7o8w== Received: from thornystick.local (76-14-135-169.rk.wavecable.com [76.14.135.169]) (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: gshapiro) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TQKbh4KQ8z16xs for ; Thu, 1 Feb 2024 00:32:00 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Date: Wed, 31 Jan 2024 16:31:58 -0800 From: Gregory Shapiro To: freebsd-current@freebsd.org Subject: sendmail 8.18.1 imported and merged Message-ID: <43fequx3alugcau6poki5igxkgiicvx2txrc2mq34iftum6x5r@4b4eouf776wh> 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: text/plain; charset=us-ascii Content-Disposition: inline As noted in UPDATING: 20240201: sendmail 8.18.1 has been imported and merged. This version enforces stricter RFC compliance by default, especially with respect to line endings. This may cause issues with receiving messages from non-compliant MTAs; please see the first 8.18.1 release note in contrib/sendmail/RELEASE_NOTES for mitigations. Here is that release note entry: 8.18.1/8.18.1 2024/01/31 sendmail is now stricter in following the RFCs and rejects some invalid input with respect to line endings and pipelining: - Prevent transaction stuffing by ensuring SMTP clients wait for the HELO/EHLO and DATA response before sending further SMTP commands. This can be disabled using the new srv_features option 'F'. Issue reported by Yepeng Pan and Christian Rossow from CISPA Helmholtz Center for Information Security. - Accept only CRLF . CRLF as end of an SMTP message as required by the RFCs, which can disabled by the new srv_features option 'O'. - Do not accept a CR or LF except in the combination CRLF (as required by the RFCs). These checks can be disabled by the new srv_features options 'U' and 'G', respectively. In this case it is suggested to use 'u2' and 'g2' instead so the server replaces offending bare CR or bare LF with a space. It is recommended to only turn these protections off for trusted networks due to the potential for abuse. From nobody Fri Feb 2 20:07:35 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 4TRRds4J5xz589ZR for ; Fri, 2 Feb 2024 20:07:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRRdr0Rbbz4vCF; Fri, 2 Feb 2024 20:07:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=troutmask.apl.washington.edu header.s=troutmask header.b=BXiYyIyw; dmarc=fail reason="No valid SPF" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 412K7Z9h016907; Fri, 2 Feb 2024 12:07:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 412K7Z9h016907 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706904455; bh=dWrNm5GMnUonNJirJBrjRCf1FRX/BBVMSQgwSA2HmEA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=BXiYyIywOKg8w+kfBZbgzUQ8+Zbm5Snepv9aQ9TRL21j0PG5yGL+yadV6brUnvxRv CywRuCVVngyJNeqMU6BS5cT48/e95+j+l3LqDxcI/hrQTKtSVfjHKvxLOL0Z1yxh5X WFUHVckR0JFiJCjnLooC2sZhWCjVYXR5d4rhxhvT35+GpjOEwNX75/MXt82Aquz8/u 3hy+4edbvSOAJzDQTVVfkMM9L4zEPmhQIlGMAA2kOW6vdG9viX1haRMzgsARGge4K/ LdMP4RklIB+qfzant14s08PMkjzXK3BR2z06Ez6/I8m9YFzSV8NvjmoSpVEW7y5MqT C3W6k4+R4qN7A== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 412K7Zs5016906; Fri, 2 Feb 2024 12:07:35 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Feb 2024 12:07:35 -0800 From: Steve Kargl To: Konstantin Belousov Cc: Mike Karels , Dimitry Andric , FreeBSD CURRENT Subject: Re: llvm ld vs binutils ld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.63 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; NEURAL_HAM_SHORT(-0.90)[-0.901]; NEURAL_HAM_LONG(-0.77)[-0.765]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF,none]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_PERMFAIL(0.00)[troutmask.apl.washington.edu:s=troutmask]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_NA(0.00)[no SPF record]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[troutmask.apl.washington.edu:~]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4TRRdr0Rbbz4vCF On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote: > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote: > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote: > > > On 27 Jan 2024, at 18:08, Steve Kargl wrote: > > > > > > > > In an attempt to cleanup a bit of src/lib/msun, I ran into > > > > a small issue that I cannot explain at the moment. If I have > > > > /usr/bin/ld in my path prior to /usr/local/bin/ld everything > > > > works > > > > > > > > % which ld > > > > /usr/bin/ld > > > > % make clean && make cleandepend > > > > % make > > > > > > > > and I have a libm.so.5. But if /usr/local/bin/ld is found, I > > > > see > > > > > > > > % cd msun > > > > % make clean && make cleandepend > > > > % make > > > > .. > > > > ld: error: version script assignment of 'FBSD_1.0' to symbol 'fabs' \ > > > > failed: symbol not defined > > > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > > > *** Error code 1 > > > > > > > > Stop. > > > > make: stopped in /usr/src/lib/msun > > > > > > > > % grep fabs /usr/src/lib/msun/Symbol.map > > > > fabs; > > > > fabsf; > > > > fabsl; > > > > > > > > But, if one looks in msun/Makefile, one see > > > > > > > > # FreeBSD's C library supplies these functions: > > > > #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c > > > > > > > > so fabs is not built with libm. > > > > > > > > % nm --dynamic /lib/libc.so.7 | grep fabs > > > > 00000000000ba600 T fabs > > > > % nm --dynamic /lib/libm.so.5 | grep fabs > > > > 000000000001fa90 T fabsf > > > > 00000000000252e0 T fabsl > > > > > > > > > > > > Is this a known issue? Should fabs be removed from Symbol.map? > > > > > > Yes, fabs is excluded in msun's Makefile: > > > > > > # FreeBSD's C library supplies these functions: > > > #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c > > > > Thanks for the quick response. I knew this, but > > > > > so it should not have been in Symbol.map at all. > > > > it has been this way for a very long time. > > > > > The comment is also > > > incorrect, since s_frexp.c and s_isnan.c *are* actually in COMMON_SRCS, > > > see lines 79 and 80 of the Makefile. (They are indeed also in libc, so > > > which one is chosen is only known by the linker. :) > > > > I would it depends on the search order of the libraries. For > > static linking, it's the order on the commandline. For rtld, > > it's the order of the libraries in the cache. > > > > % nm --dynamic /lib/libc.so.7 | grep snan > > 00000000000ace30 T __isnan@@FBSD_1.0 > > 00000000000ace60 T __isnanf@@FBSD_1.0 > > 00000000000ace30 W isnan@@FBSD_1.0 > > 00000000000ace60 W isnanf@@FBSD_1.0 > > % nm --dynamic /lib/libm.so.5 | grep snan > > 00000000000220a0 T __isnanf@@FBSD_1.2 > > 00000000000220d0 T __isnanl@@FBSD_1.0 > > 00000000000220a0 W isnanf@@FBSD_1.0 > > > > Not quite. isnan is in libc but libm. isnanf seems to be > > in both, and isnanl is only in libm. Does FBSD_1.2 trump > > FBSD_1.0 for __isnanf? > No, the binary specifies which version of the symbol it wants, either > __isnanf@FBSD_1.2 or __isnanf@FBSD_1.0, and the dynamic linker binds to > the version. > > Which version is recorded into the consumer binary, is up to the static > linker (ld), and there it is normally defined by the order of the libraries > specified on the command line. Thanks for the explanation, but I think I now have a conundrum. Suppose I have two shared libraries libfoo.so and libbar.so, and suppose bah@@XXX_1.0 is in libbar.so's symbol map. If my main program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar', then the linker finds bah@XXX_1.0. Now suppose a developer adds a new procedure to libfoo.so and she just so happens to name her new function bah() with a symbol map entry of bah@YYY_a.b. Which bah@ is linked when rebuilding or loading 'z'? Does it depend on the search order for ld-config.so.1? -- Steve From nobody Fri Feb 2 20:48:54 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 4TRSYW3rKzz58FQt for ; Fri, 2 Feb 2024 20:49:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRSYV5wb5z52MP; Fri, 2 Feb 2024 20:49:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 412KmtX7055398; Fri, 2 Feb 2024 22:48:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 412KmtX7055398 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 412Kmsoe055397; Fri, 2 Feb 2024 22:48:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 2 Feb 2024 22:48:54 +0200 From: Konstantin Belousov To: Steve Kargl Cc: Mike Karels , Dimitry Andric , FreeBSD CURRENT Subject: Re: llvm ld vs binutils ld Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TRSYV5wb5z52MP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote: > On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote: > > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote: > > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote: > > > > On 27 Jan 2024, at 18:08, Steve Kargl wrote: > > > > > > > > > > In an attempt to cleanup a bit of src/lib/msun, I ran into > > > > > a small issue that I cannot explain at the moment. If I have > > > > > /usr/bin/ld in my path prior to /usr/local/bin/ld everything > > > > > works > > > > > > > > > > % which ld > > > > > /usr/bin/ld > > > > > % make clean && make cleandepend > > > > > % make > > > > > > > > > > and I have a libm.so.5. But if /usr/local/bin/ld is found, I > > > > > see > > > > > > > > > > % cd msun > > > > > % make clean && make cleandepend > > > > > % make > > > > > .. > > > > > ld: error: version script assignment of 'FBSD_1.0' to symbol 'fabs' \ > > > > > failed: symbol not defined > > > > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > > > > *** Error code 1 > > > > > > > > > > Stop. > > > > > make: stopped in /usr/src/lib/msun > > > > > > > > > > % grep fabs /usr/src/lib/msun/Symbol.map > > > > > fabs; > > > > > fabsf; > > > > > fabsl; > > > > > > > > > > But, if one looks in msun/Makefile, one see > > > > > > > > > > # FreeBSD's C library supplies these functions: > > > > > #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c > > > > > > > > > > so fabs is not built with libm. > > > > > > > > > > % nm --dynamic /lib/libc.so.7 | grep fabs > > > > > 00000000000ba600 T fabs > > > > > % nm --dynamic /lib/libm.so.5 | grep fabs > > > > > 000000000001fa90 T fabsf > > > > > 00000000000252e0 T fabsl > > > > > > > > > > > > > > > Is this a known issue? Should fabs be removed from Symbol.map? > > > > > > > > Yes, fabs is excluded in msun's Makefile: > > > > > > > > # FreeBSD's C library supplies these functions: > > > > #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c > > > > > > Thanks for the quick response. I knew this, but > > > > > > > so it should not have been in Symbol.map at all. > > > > > > it has been this way for a very long time. > > > > > > > The comment is also > > > > incorrect, since s_frexp.c and s_isnan.c *are* actually in COMMON_SRCS, > > > > see lines 79 and 80 of the Makefile. (They are indeed also in libc, so > > > > which one is chosen is only known by the linker. :) > > > > > > I would it depends on the search order of the libraries. For > > > static linking, it's the order on the commandline. For rtld, > > > it's the order of the libraries in the cache. > > > > > > % nm --dynamic /lib/libc.so.7 | grep snan > > > 00000000000ace30 T __isnan@@FBSD_1.0 > > > 00000000000ace60 T __isnanf@@FBSD_1.0 > > > 00000000000ace30 W isnan@@FBSD_1.0 > > > 00000000000ace60 W isnanf@@FBSD_1.0 > > > % nm --dynamic /lib/libm.so.5 | grep snan > > > 00000000000220a0 T __isnanf@@FBSD_1.2 > > > 00000000000220d0 T __isnanl@@FBSD_1.0 > > > 00000000000220a0 W isnanf@@FBSD_1.0 > > > > > > Not quite. isnan is in libc but libm. isnanf seems to be > > > in both, and isnanl is only in libm. Does FBSD_1.2 trump > > > FBSD_1.0 for __isnanf? > > No, the binary specifies which version of the symbol it wants, either > > __isnanf@FBSD_1.2 or __isnanf@FBSD_1.0, and the dynamic linker binds to > > the version. > > > > Which version is recorded into the consumer binary, is up to the static > > linker (ld), and there it is normally defined by the order of the libraries > > specified on the command line. > > Thanks for the explanation, but I think I now have a conundrum. > Suppose I have two shared libraries libfoo.so and libbar.so, and > suppose bah@@XXX_1.0 is in libbar.so's symbol map. If my main > program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar', > then the linker finds bah@XXX_1.0. > > Now suppose a developer adds a new procedure to libfoo.so and she > just so happens to name her new function bah() with a symbol map > entry of bah@YYY_a.b. > > Which bah@ is linked when rebuilding or loading 'z'? Does it > depend on the search order for ld-config.so.1? In the 'z' binary either bah@XXX_1.0 or bah@YYY_1.0 is specified as the symbol to resolve at the call site. Dynamic linker searches for corresponding versioned symbol in the global namespace, typically. So now the question is reduced to what version of the symbol bah get recorded into the 'z' binary. It is done by static linker, which looks up symbols linearly in the order of object files and libraries specified on the command line (*). If you did 'cc -o z main.c -lfoo -lbar', and both libfoo.so and libbar.so provided the bah symbol, the first found definition is recorded, together with its version. The final answer is lookup finds bah in libfoo.so and bah@YYY_1.0 is recorded. * There are many ways to direct static linker to find specific version of the symbol, changing the default behavior. From nobody Fri Feb 2 21:10:02 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 4TRT1n6F7Vz58HDN for ; Fri, 2 Feb 2024 21:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRT1n3QTgz55CQ; Fri, 2 Feb 2024 21:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 412LA32n017234; Fri, 2 Feb 2024 13:10:03 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 412LA32n017234 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706908203; bh=Cbuf1dWaTExmec1JkXgKhPjvYT7jHkM8+xm/uEAovHU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=T+WrbCYDgw9CkQna59zcDIWtICQUzv8NmAwURHUVxY/HPawDFteqKkjl4ZDyAKnA8 DRXmWKv26d4y5jc7+b6y5znnZbLV04XmsZ951hFDHXTnoDPFmzHyKUzB3FAzCWXwxc ge1ZJdaDv1QDZEwxqbiTmGJqpdVx3IguOvwXA//nDwBf77qCleJplXgC0MbPtxn2RV e7KC5mdaW//TB7uEh3L6d7oVqBBF8Uk2NEwiyRoJWn1iHK6HhikrHiu/zI+wQis6C3 SzHpiwvuyXceccw5JU79FN7G27SF/KiTu0pZn1GERb6zdCnwXyO8KgWmIFS52u6NMF fibZj4FuS+rnw== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 412LA2hC017233; Fri, 2 Feb 2024 13:10:02 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Feb 2024 13:10:02 -0800 From: Steve Kargl To: Konstantin Belousov Cc: Mike Karels , Dimitry Andric , FreeBSD CURRENT Subject: Re: llvm ld vs binutils ld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TRT1n3QTgz55CQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] On Fri, Feb 02, 2024 at 10:48:54PM +0200, Konstantin Belousov wrote: > On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote: > > > > Thanks for the explanation, but I think I now have a conundrum. > > Suppose I have two shared libraries libfoo.so and libbar.so, and > > suppose bah@@XXX_1.0 is in libbar.so's symbol map. If my main > > program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar', > > then the linker finds bah@XXX_1.0. > > > > Now suppose a developer adds a new procedure to libfoo.so and she > > just so happens to name her new function bah() with a symbol map > > entry of bah@YYY_a.b. > > > > Which bah@ is linked when rebuilding or loading 'z'? Does it > > depend on the search order for ld-config.so.1? > > In the 'z' binary either bah@XXX_1.0 or bah@YYY_1.0 is specified as > the symbol to resolve at the call site. Dynamic linker searches for > corresponding versioned symbol in the global namespace, typically. > > So now the question is reduced to what version of the symbol bah get > recorded into the 'z' binary. It is done by static linker, which looks > up symbols linearly in the order of object files and libraries specified > on the command line (*). If you did 'cc -o z main.c -lfoo -lbar', and > both libfoo.so and libbar.so provided the bah symbol, the first found > definition is recorded, together with its version. The final answer > is lookup finds bah in libfoo.so and bah@YYY_1.0 is recorded. > > * There are many ways to direct static linker to find specific version > of the symbol, changing the default behavior. Thank you. This essentially confirms my fears. -- Steve From nobody Fri Feb 2 22:31:43 2024 X-Original-To: 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 4TRVr727dbz58QWk for ; Fri, 2 Feb 2024 22:31:51 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRVr64Bppz41dQ for ; Fri, 2 Feb 2024 22:31:50 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 084E23C019A; Fri, 2 Feb 2024 22:31:44 +0000 (UTC) Date: Fri, 2 Feb 2024 22:31:43 +0000 From: Brooks Davis To: current@freebsd.org Subject: libc/libsys split coming soon Message-ID: 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: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.61 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; ONCE_RECEIVED(0.10)[]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.01)[-0.010]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[brooks]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FROM_HAS_DN(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TRVr64Bppz41dQ TL;DR: The implementation of system calls is moving to a seperate library (libsys). No changes are required to existing software (except to ensure that libsys is present when building custom disk images). Code: https://github.com/freebsd/freebsd-src/pull/908 After nearly a decade of intermittent work, I'm about to land a series of patches which moves system calls, vdso support, and libc's parsing of the ELF auxiliary argument vector into a separate library (libsys). I plan to do this early next week (February 5th). This change serves three primary purposes: 1. It's easier to completely replace system call implementations for tracing or compartmentalization purposes. 2. It simplifies the implementation of restrictions on system calls such as those implemented by OpenBSD's msyscall(2) (https://man.openbsd.org/msyscall.2). 3. It allows language runtimes to link with libsys for system call implementations without requiring libc. libsys is an auxiliary filter for libc. This means that for any symbol defined by both, the libsys version takes precedence at runtime. For system call implementations, libc contains empty stubs. For others it contains copies of the functions (this could be further refined at a later date). The statically linked libc contains the full implementations so linking libsys is not required. Additionally, libthr is now linked with libsys to provide _umtx_op_err(). The overall implementation follows https://reviews.freebsd.org/D14609, but is redone from scratch as multiple commits to facilitate review and assist git's rename detection. Testing: - Boot testing on amd64, aarch64, and riscv - make tinderbox (prior version, final run in progress) - exp-run: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276391 - Kyua tests in poudriere amd64 jails: same 359 failures as with the latest freebsdci build Thanks to Ali Mashtizadeh and Tal Garfinkel for D14609 and many apologies for not landing this in a timely manner. Additional thanks to kib@ for many rounds of review, markj@ and kib@ for debugging rtld issues exposed by this patch, and antoine@ for exp-runs. Future work: - Purely functional interfaces to system calls (no errorno). Unfortunately there isn't an obvious way to do this without significant (possibly generated) assembly code. - Investigate msyscall(2) and pinsyscalls(2). - Reduce the size of stubs in libc. I’ve errored on the side of not touching the copies that end up in libc to keep diff size down. We might want to generate empty stubs instead. See also: - Solaris Linker and Libraries Guide: https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html -- Brooks From nobody Fri Feb 2 23:35:12 2024 X-Original-To: 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 4TRXFP1FkMz58WlH for ; Fri, 2 Feb 2024 23:35:21 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRXFN6DGwz4CMP; Fri, 2 Feb 2024 23:35:20 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none Date: Sat, 03 Feb 2024 00:35:12 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Brooks Davis Cc: current@freebsd.org Subject: Re: libc/libsys split coming soon Message-ID: <20240202233512.DTulx4sD@steffen%sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Brooks Davis , current@freebsd.org User-Agent: s-nail v14.9.24-596-g7894190075 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4TRXFN6DGwz4CMP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] 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 Brooks Davis wrote in : |TL;DR: The implementation of system calls is moving to a seperate |library (libsys). No changes are required to existing software (except |to ensure that libsys is present when building custom disk images). ... [vvvv] |This change serves three primary purposes: | 1. It's easier to completely replace system call implementations for | tracing or compartmentalization purposes. | 2. It simplifies the implementation of restrictions on system calls such | as those implemented by OpenBSD's msyscall(2) | (https://man.openbsd.org/msyscall.2). | 3. It allows language runtimes to link with libsys for system call | implementations without requiring libc. That is so cool. Much love for 3.! .. |After nearly a decade of intermittent work, I'm about to land a series |of patches which moves system calls, vdso support, and libc's parsing of |the ELF auxiliary argument vector into a separate library (libsys). I |plan to do this early next week (February 5th). Congratulations. Thanks for all your efforts. All FreeBSD! Oh i had a mail in the queue for another list, and whereas i admire all efforts, how i love this one! Thank you, and nice weekend i wish from Germany! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Feb 3 09:04:33 2024 X-Original-To: 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 4TRmtb6w5bz58yTn for ; Sat, 3 Feb 2024 09:04:55 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRmtb4MLyz4Std; Sat, 3 Feb 2024 09:04:55 +0000 (UTC) (envelope-from dch@skunkwerks.at) Authentication-Results: mx1.freebsd.org; none Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 73B045C00C1; Sat, 3 Feb 2024 04:04:54 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Sat, 03 Feb 2024 04:04:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1706951094; x=1707037494; bh=fz99druo891jeV/pQmSfMgghfLg1+vL1 COfvynEFkE4=; b=BeLZrkRiPETmEmBZtm8l8gyn0ZcqDavuDhstGv70y6aiGJXU S7UQz38xY4bjlZO7w71MGkNCiuUnzWIhjnco25APpTsFNolr2CWJ5/YnIvaEIvao a1FhqKKWFu6h0CpQynuGZIlt0zs6sI3hKrotSFqU/xjIQ5BCGI8OeXBfh6on8cH2 l3Kgk5D6Es+KXakltTE+M4o+zo7XRFJ44HE2tBuabzQPu09ny147y6Qmv086Jsua 5tLanjbq4wJFHg+ZOX+HoT78Es6grThulRsW6ZuOge9nwsWCrUkthCHg/sz4weAj gfW6oflVl0jOOFaouTw2zWOykDw5LAOJcLAjZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706951094; x= 1707037494; bh=fz99druo891jeV/pQmSfMgghfLg1+vL1COfvynEFkE4=; b=W s5vos9dJLz3cnMVT3UnMo76aRsB7OYncKRGOJfpjp1zck2jafXwI0W//jV1jWfUq o39RlBup5Zq8voAChsCEmPBv6MZHsE4Mjjs9zrO2pCt6LfNfIfNvP15CNFYegAz7 /LkTd022htO+NExvkQhvCFDUmlM4LsscVqjus91hvqcYpkG74GAdg6C4fbSBdxWU G8ASDK/lLtAcNpPn35FWvkSo80u99frNMOyYL2qCLuyDw5qiDGcJMAyH6jbJlWq3 KD9pi4JCoymhPw5FW/5LPjPjQRnbuLMT7ao/YkruWZ6uKprn7Wxg4HLMTB8NzCkR Yk3m9QKdvN6bgGFOVUbwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduhedguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf ffgrvhgvucevohhtthhlvghhuhgsvghrfdcuoegutghhsehskhhunhhkfigvrhhkshdrrg htqeenucggtffrrghtthgvrhhnpeffuefgteehteetfeevfefhvdfhgefhvddvheduvdfh gefgffefvedtieffueetveenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhophgvnh gsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrth X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0E95536A0076; Sat, 3 Feb 2024 04:04:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 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 Message-Id: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> In-Reply-To: References: Date: Sat, 03 Feb 2024 10:04:33 +0100 From: "Dave Cottlehuber" To: "Brooks Davis" Cc: current@freebsd.org Subject: Re: libc/libsys split coming soon Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TRmtb4MLyz4Std X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote: > TL;DR: The implementation of system calls is moving to a seperate > library (libsys). No changes are required to existing software (except > to ensure that libsys is present when building custom disk images). > > Code: https://github.com/freebsd/freebsd-src/pull/908 > > After nearly a decade of intermittent work, I'm about to land a series > of patches which moves system calls, vdso support, and libc's parsing = of > the ELF auxiliary argument vector into a separate library (libsys). I > plan to do this early next week (February 5th). > > This change serves three primary purposes: > 1. It's easier to completely replace system call implementations for > tracing or compartmentalization purposes. > 2. It simplifies the implementation of restrictions on system calls = such > as those implemented by OpenBSD's msyscall(2) > (https://man.openbsd.org/msyscall.2). > 3. It allows language runtimes to link with libsys for system call > implementations without requiring libc. Awesome! So (3) is generally considered ideal for languages like zig[1],= rust or go, to use directly? What=E2=80=99s the appropriate mechanism for such a language to know whi= ch version of FreeBSD it=E2=80=99s talking to, to ensure syscall table m= atches the languages expectations? It would be nice to hear about any experiments in (2) and how that compa= res to things such as capsicum. [1]: https://github.com/ziglang/zig/issues/165 A+ Dave From nobody Sat Feb 3 09:15:09 2024 X-Original-To: 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 4TRn6S51gSz590qm for ; Sat, 3 Feb 2024 09:15:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRn6S2wFnz4W3G; Sat, 3 Feb 2024 09:15:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-6e0f43074edso1772530a34.1; Sat, 03 Feb 2024 01:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706951710; x=1707556510; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i/q1jJ3aV/iP7WaCFKsQYKyDAZlrkUVHqqE0Zo807aA=; b=PaylmUAMHzQqRPfQFQvrXyru56XeimPAnSbz9itu2QHe+hsgrgWr8SQdwYGCF6kTvE vYvrn6vwYIQ8KHaA7Dty/8eFKHre2NmvxSPBbWbZg0WPQE+6Mb/sld6V7YwsZ27PlNxZ WLria2N1PEXkSEt6FDrC8cLosRwFwCsBSrj0M2d8gbLSKIm/2hWo72JIvmwbX5U1NNMp qiJL5crBHlB+4Mtjz0B9LHeJEtqkdQuJWp3EGiA+gopw277HpYTjpOS+I+JsFW82eozE 1SC9cmRcKEwcEgiIVXq8uwwovU79Tuqcw/+1mhOBRXbcSlrCaNLTaN7qWFuUhUJpY7Zw hyZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706951710; x=1707556510; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i/q1jJ3aV/iP7WaCFKsQYKyDAZlrkUVHqqE0Zo807aA=; b=tUeGmrGJesbQBsWJd4wBXrBtZX7Wn/vDa1/fg+1D6rI+1GXxB+JqS9QbaIfCmCWAwV GYnt2//Drn7KABPmSG5iPQNtvS5/9raSunZx4ZboAZlzDoXuChvkuZrIcDvFHfZoU9WO Jf/UIH4kRTWXLcjQ3U7f9yOWVPrbiMySdDdQ3TDRK/KxzTPcDVKOAA4UNQkEzhGLh5uR nDNiZuKD5zt3mnElHhd6SNMUgu4JX2DRS1aLVoB4t27Ky37kfD/q1zxRIQbghDuxbPB4 2801q3NHbifb72TITYsec0O6uCNFyq1ur6IgCkRnhLJ2MU8PmvWJGaZvyYibsnzd6hTg 3cTQ== X-Gm-Message-State: AOJu0YwyDr/0xrQpnZcxiO9A6l7KeSsmDHUSnLL+OmNGnbYozR3kzAB8 fgarq/SjiaU5+N37hx3fYmNhKwgILSH6KpTzEsNVlj5jbAkFA7cMEezFpPyFKMVFVbM7cZRm9jA swW8B1xNhd0bqB5vuVMu8cCaI+2Gs6zMV X-Google-Smtp-Source: AGHT+IE5cNkE3GLVBhyMqOFpPUQvgOwkp/K2sJ2g+lHKLhgn+AF8CVo25doC63+Ryy/Ak/XUk/6nG1wjZDv4SE+/imM= X-Received: by 2002:a9d:631a:0:b0:6dd:e134:935c with SMTP id q26-20020a9d631a000000b006dde134935cmr4361088otk.28.1706951710096; Sat, 03 Feb 2024 01:15:10 -0800 (PST) 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 Received: by 2002:ac9:4645:0:b0:517:6330:dd0f with HTTP; Sat, 3 Feb 2024 01:15:09 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Sat, 3 Feb 2024 10:15:09 +0100 Message-ID: Subject: Re: libc/libsys split coming soon To: Brooks Davis Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4TRn6S2wFnz4W3G X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On 2/2/24, Brooks Davis wrote: > TL;DR: The implementation of system calls is moving to a seperate > library (libsys). No changes are required to existing software (except > to ensure that libsys is present when building custom disk images). > > Code: https://github.com/freebsd/freebsd-src/pull/908 > > After nearly a decade of intermittent work, I'm about to land a series > of patches which moves system calls, vdso support, and libc's parsing of > the ELF auxiliary argument vector into a separate library (libsys). I > plan to do this early next week (February 5th). > > This change serves three primary purposes: > 1. It's easier to completely replace system call implementations for > tracing or compartmentalization purposes. > 2. It simplifies the implementation of restrictions on system calls such > as those implemented by OpenBSD's msyscall(2) > (https://man.openbsd.org/msyscall.2). > 3. It allows language runtimes to link with libsys for system call > implementations without requiring libc. > > libsys is an auxiliary filter for libc. This means that for any symbol > defined by both, the libsys version takes precedence at runtime. For > system call implementations, libc contains empty stubs. For others it > contains copies of the functions (this could be further refined at a > later date). The statically linked libc contains the full > implementations so linking libsys is not required. > Do I read it correctly that everything dynamically linked will also be linked to libsys, as in executing such a binary will now require loading one extra .so? Binary startup is very slow, for example execve of a hello world binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 compared to a native one. As such perf-wise this looks like a step in the wrong direction. Is there a problem making it so that libc ends up unchanged, but all the bits are available separately in libsys if one does not want libc? -- Mateusz Guzik From nobody Sat Feb 3 10:16:56 2024 X-Original-To: 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 4TRpTx1Rcqz595S7 for ; Sat, 3 Feb 2024 10:17:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TRpTx0ry5z4bqZ; Sat, 3 Feb 2024 10:17:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706955429; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JRzLUkvPGp6X4k0WsUwNgkK/oe8u+9mlHT1zrcBQZlI=; b=HCEW7CTxTIUx6/TCHDPH9hHfIjQDQYUpbt7klq5g564a0klL5zdVAgXM11kUaqleAmTLQo fxZvRuzloAk5sN09+o+uEJ6GxsF73J1nUfbw3FM8TuUXNXr6kC9pGS9xMnBffSNNQZo6aT 2QtUKsfwHnm2+Xlqtp/8jZk+VRMhN6hWOcRAzZOwsr70AcOeduk1hdSQHGoQtA00Lqdvjr m6XWfSNF4R3SCZWDAhrnVDHvveTrTexm+XymUyPhwP4WjShS1eZF6x+oDyslfIoMbDHet/ wUNVeA92VE4W+tBiWsATWWVxexPwmjzPgpT4/eOevqdHPrvb9Xs3P1GWMg5kvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706955429; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JRzLUkvPGp6X4k0WsUwNgkK/oe8u+9mlHT1zrcBQZlI=; b=g5ODZNRah5BWgBmsnOXqo4cuRGUsQNmYLlkAAIyF8aeGGcsqoX1QdNHGJ/qIIGIiXWucCw 1d3vfbHm+W7XpJZazTvm5H2cXmOZKbMb1EFGfioYVFMnmZ1MCh89ruPzdOU/Hr2PfRn9IX KQzuDd5IV4efj2H1Eg3WxO8DtVL4OWguUiEG8Tz+pVlqTncuVUCx3+/+D2ynKz8PWfxqxu 3hanpZ+Xr7YPtBqwxTkOX5kuvazDzQBZTkcTwMLVcEScO3xbKalEBi3ZF/H+ZxztcfQAFA Xzo/idEu2QKOO+ALSIH90gtGr/491GZb62oJ6f0/BVcbWGyuUvJoK1Mkhuhy7A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706955429; a=rsa-sha256; cv=none; b=cyBfUXqfPZDkeUZqr/7aHyl2wB6dB/mTdg0bwb/xVd/bC3QfH6dHIoII1x7gNq7CCbHwYo csToiwlY07Ki4OwGpAFN63UAgp3msKfdUpbbeFIY9WryqwaHZERAVXbGbQp0MTJF8tmvhI 6huQ0Ts+dYavJJM8RFewiWk1Pq0MQT43DzHiTCy9gnOmMFWtRQpQoStXci9dB/2EwKIYqq m3r8aYsF9U4y0UNJ5Z+WmTwGgYeStbh7uIe92Mhhxdot2eSLurVwhmSSruFMbd1+3Q9fIc IM7vYNxrE+D73MIsSRG/8xxQNc8EpYSmo5shdH8uR4CzhiU+CgOC7+3EFSjrGA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TRpTw6wr7z1Gml; Sat, 3 Feb 2024 10:17:08 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-131-178-116.range86-131.btcentralplus.com [86.131.178.116]) by smtp.theravensnest.org (Postfix) with ESMTPSA id DAA061062C; Sat, 3 Feb 2024 10:17:07 +0000 (GMT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: libc/libsys split coming soon From: David Chisnall In-Reply-To: Date: Sat, 3 Feb 2024 10:16:56 +0000 Cc: Brooks Davis , current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7E8133B7-4BD5-42AB-8B16-A10F59295F28@FreeBSD.org> References: To: Mateusz Guzik X-Mailer: Apple Mail (2.3774.200.91.1.1) On 3 Feb 2024, at 09:15, Mateusz Guzik wrote: >=20 > Binary startup is very slow, for example execve of a hello world > binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 > compared to a native one. As such perf-wise this looks like a step in > the wrong direction. Have you profiled this? Is the Linux version using BIND_NOW (which = comes with a load of problems, but it often the default for Linux = systems and reduces the number of slow-path entries into rtld)? Do they = trigger the same number of CoW faults? Is there a path in rtld that=E2=80= =99s slower than the equivalent ld-linux.so path? David= From nobody Sat Feb 3 11:12:35 2024 X-Original-To: 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 4TRqjx4C0kz599n2 for ; Sat, 3 Feb 2024 11:12:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRqjx26L2z4hnc; Sat, 3 Feb 2024 11:12:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x333.google.com with SMTP id 46e09a7af769-6e12d0af927so2068989a34.0; Sat, 03 Feb 2024 03:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706958756; x=1707563556; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4FM5witnUdqX57JJ82lAIAkjvJ2W2V+jV2IMqLJWk1c=; b=COw0hdM5MuixDroKE3aFHRWVAPy9T7s6N/oHXDr/calIbLjfiKzx3ortBYnkxyZheG YCKNXZKVWPjmV9/1yrhcXlRL6sq9fL9VGTpTT+P2yd1FzgzH5jnlF11baaOg4GvnTyxo XoSWqOb/Z4Y4hrvoXS9Ep9JI5uk/1ieJj9BcG7IMdEgJ/q1UP0BtOI8aNpmFgkwKxkJl wpH+AS372iOIH2Qc/xrac0DAqACVsRuT/1seX6T64zuOv25ixlsSCUjVasG0IlTCmd71 xXbzT8iCFSSfTSezQSpZs7PISjbvSr7rN/YGQXFNd7G8fjOKtOO3OyWuCsSIoG3csZs8 5lwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706958756; x=1707563556; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4FM5witnUdqX57JJ82lAIAkjvJ2W2V+jV2IMqLJWk1c=; b=HnHZgjAwXPNzIrJ4BmLB2QGFflIRDIVsqeAv9QsmAHhgAHKRQKZdOaaedqTBFCdlvt saGuNkfx2teIVzs/qMhgIQvaYwANahjKg2itzmutK2W7rwRVxNQe66SN6cKhNTFXNGHK KQ5DYkNtostvPEWgKEkhal3txnSSYmutWO/VVpCwuBYscdrl19W8Tm4eEaXw1BaVCMu3 K11wAHAP97gwG6kqDgavRxanl4PbNpCslCAsfVeEi2Zbn8H7ZC5e0wPDvNzEbUOljMDs GkQnOZATRrs7y8pV6H2L0vE2IcrCHi4MuicCduMEK16F/ZkFba5o7dexkmLrF8rIrGzl 2NZw== X-Gm-Message-State: AOJu0YwEghSPgF65V7bpfQSlKNunwXeri+2KemGc/MvZoqIjekgwr+wz 0quFgYHrYnjZG6t8hR5Fql8uxeslhvTR/6Dj7/G4/EAoNfL+VF8IXkioymEta6c/jkILWGC0pS8 8OzAFF7hMQVyhKyXDLlEW6VxMW1pxO+kH X-Google-Smtp-Source: AGHT+IHjJVfoIZcEHnxUEOtv5rDFBXK/axlKnHE7oOmoil7dy0PvOmR0HK6ouNU9kPdP4lkRKPCaMvdrFrFl+T105wk= X-Received: by 2002:a05:6830:87:b0:6dc:5e1:3d89 with SMTP id a7-20020a056830008700b006dc05e13d89mr11016641oto.17.1706958755757; Sat, 03 Feb 2024 03:12:35 -0800 (PST) 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 Received: by 2002:ac9:4645:0:b0:517:6330:dd0f with HTTP; Sat, 3 Feb 2024 03:12:35 -0800 (PST) In-Reply-To: <7E8133B7-4BD5-42AB-8B16-A10F59295F28@FreeBSD.org> References: <7E8133B7-4BD5-42AB-8B16-A10F59295F28@FreeBSD.org> From: Mateusz Guzik Date: Sat, 3 Feb 2024 12:12:35 +0100 Message-ID: Subject: Re: libc/libsys split coming soon To: David Chisnall Cc: Brooks Davis , current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TRqjx26L2z4hnc X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On 2/3/24, David Chisnall wrote: > On 3 Feb 2024, at 09:15, Mateusz Guzik wrote: >> >> Binary startup is very slow, for example execve of a hello world >> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 >> compared to a native one. As such perf-wise this looks like a step in >> the wrong direction. > > Have you profiled this? Is the Linux version using BIND_NOW (which comes > with a load of problems, but it often the default for Linux systems and > reduces the number of slow-path entries into rtld)? Do they trigger the > same number of CoW faults? Is there a path in rtld that=E2=80=99s slower= than the > equivalent ld-linux.so path? > I only profiled FreeBSD, it was 4 years ago. I have neither time nor interest in working on this. Relevant excerpts from profiling an fexecve loop: Sampling what syscalls was being executed when in kernel mode (or trap): syscalls: pread 108 fstat 162 issetugid 250 sigprocmask 303 read 310 mprotect 341 open 380 close 1547 mmap 2787 trap 5421 [snip] In userspace most of the time is spent here: ld-elf.so.1`memset 406 ld-elf.so.1`matched_symbol 431 ld-elf.so.1`strcmp 1078 ld-elf.so.1`reloc_non_plt 1102 ld-elf.so.1`symlook_obj 1102 ld-elf.so.1`find_symdef 1439 find_symdef iterates a linked list, which I presume induces strcmp calls due to unwanted entries. [snip] Full profile user: libc.so.7`__je_extent_heap_new 71 libc.so.7`__vdso_clock_gettime 73 libc.so.7`memset 75 ld-elf.so.1`_rtld 83 ld-elf.so.1`getenv 85 libc.so.7`__je_malloc_mutex_boot 132 ld-elf.so.1`reloc_plt 148 ld-elf.so.1`__crt_malloc 163 ld-elf.so.1`symlook_default 166 ld-elf.so.1`digest_dynamic1 184 libc.so.7`__je_malloc_mutex_init 205 ld-elf.so.1`symlook_global 281 ld-elf.so.1`memset 406 ld-elf.so.1`matched_symbol 431 ld-elf.so.1`strcmp 1078 ld-elf.so.1`reloc_non_plt 1102 ld-elf.so.1`symlook_obj 1102 ld-elf.so.1`find_symdef 1439 kernel: kernel`vm_reserv_alloc_page 89 kernel`amd64_syscall 95 kernel`0xffffffff80 102 kernel`vm_page_alloc_domain_after 114 kernel`vm_object_deallocate 117 kernel`vm_map_pmap_enter 122 kernel`pmap_enter_object 140 kernel`uma_zalloc_arg 148 kernel`vm_map_lookup_entry 148 kernel`pmap_try_insert_pv_entry 156 kernel`vm_fault_dirty 168 kernel`pagecopy 177 kernel`vm_fault 260 kernel`get_pv_entry 265 kernel`pagezero_erms 367 kernel`pmap_enter_quick_locked 380 kernel`pmap_enter 432 kernel`0xffffffff80 1126 kernel`0xffffffff80 2017 kernel`trap 2097 syscalls: pread 108 fstat 162 issetugid 250 sigprocmask 303 read 310 mprotect 341 open 380 close 1547 mmap 2787 trap 5421 Counting fexecve: dtrace -n 'fbt::sys_fexecve:entry { @[count] =3D stack(); } tick-30s { exit= (0); }' dtrace script, can be run as: dtrace -w -x aggsize=3D128M -s script.d assumes binary name is a.out syscall::fexecve:entry { self->inexec =3D 1; } syscall::fexecve:return { self->inexec =3D 0; } fbt::trap:entry { self->trap =3D 1; } fbt::trap:return { self->trap =3D 0; } profile:::profile-4999 /execname =3D=3D "a.out" && arg1 && self->inexec =3D=3D 0/ { @user[usym(arg1)] =3D count(); } profile:::profile-4999 /execname =3D=3D "a.out" && arg0 && self->inexec =3D=3D 0 && self->trap =3D= =3D 0/ { @kernel[sym(arg0)] =3D count(); @kernel_syscall[stringof(`syscallnames[curthread->td_sa.code])] =3D count(); } profile:::profile-4999 /execname =3D=3D "a.out" && arg0 && self->inexec =3D=3D 0 && self->trap =3D= =3D 1/ { @kernel[sym(arg0)] =3D count(); @kernel_syscall["trap"] =3D count(); } tick-5s { system("clear"); trunc(@user, 20); trunc(@kernel, 20); printa("%40A %@16d\n", @user); printa("%40a %@16d\n", @kernel); clear(@user); clear(@kernel); trunc(@kernel_syscall, 10); printf("\t\t\tsyscalls:\n"); printa("%40s %@16d\n", @kernel_syscall); clear(@kernel_syscall); } fexecve-loop.c: #include #include #include #include #include #include #include int main(int argc, char **argv) { char buf[8]; char *cargv[3]; int fd; switch (argc) { case 1: fd =3D open(argv[0], O_EXEC); if (fd =3D=3D -1) err(1, "open"); cargv[0] =3D argv[0]; cargv[1] =3D buf; sprintf(cargv[1], "%d", fd); cargv[2] =3D NULL; break; case 2: fd =3D atoi(argv[1]); cargv[0] =3D argv[0]; cargv[1] =3D argv[1]; cargv[2] =3D NULL; break; default: printf("invalid argc %d\n", argc); exit(1); } fexecve(fd, cargv, NULL); err(1, "fexecve"); --=20 Mateusz Guzik From nobody Sat Feb 3 12:17:03 2024 X-Original-To: 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 4TRs8S73Dfz59H5Y for ; Sat, 3 Feb 2024 12:17:12 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (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 (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRs8S2glcz4qFH; Sat, 3 Feb 2024 12:17:12 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.17.1/8.17.1) with ESMTPS id 413CH3uw061581 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Feb 2024 13:17:04 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.17.1/8.17.1/Submit) id 413CH3gj061580; Sat, 3 Feb 2024 13:17:03 +0100 (CET) (envelope-from fuz) Date: Sat, 3 Feb 2024 13:17:03 +0100 From: Robert Clausecker To: Mateusz Guzik Cc: Brooks Davis , current@freebsd.org Subject: Re: libc/libsys split coming soon Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TRs8S2glcz4qFH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] Am Sat, Feb 03, 2024 at 10:15:09AM +0100 schrieb Mateusz Guzik: > Do I read it correctly that everything dynamically linked will also be > linked to libsys, as in executing such a binary will now require > loading one extra .so? > > Binary startup is very slow, for example execve of a hello world > binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 > compared to a native one. As such perf-wise this looks like a step in > the wrong direction. I wonder if we could follow the steps of musl libc and just integrate libsys/libc into rtld, as basically all dynamically linked programs link these libraries anyway. Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From nobody Sat Feb 3 16:05:10 2024 X-Original-To: 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 4TRyCr0X48z59djt for ; Sat, 3 Feb 2024 16:05:28 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRyCq5wMMz4Nh5; Sat, 3 Feb 2024 16:05:27 +0000 (UTC) (envelope-from eischen@vigrid.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.16.1/8.15.1/NETPLEX) with ESMTPSA id 413FdWSq055759 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Feb 2024 10:39:32 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Sat, 03 Feb 2024 10:39:33 -0500 (EST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Daniel Eischen 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 (1.0) Subject: Re: libc/libsys split coming soon Date: Sat, 3 Feb 2024 11:05:10 -0500 Message-Id: <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> Cc: current@freebsd.org, Dave Cottlehuber In-Reply-To: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> To: Brooks Davis X-Mailer: iPhone Mail (21D50) X-Rspamd-Queue-Id: 4TRyCq5wMMz4Nh5 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6062, ipnet:204.213.176.0/20, country:US] Will this break binary compatibility with older programs expecting those sym= bols in libc and not linked to libsys? > On Feb 3, 2024, at 3:39=E2=80=AFAM, Dave Cottlehuber w= rote: >=20 > =EF=BB=BFOn Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote: >> TL;DR: The implementation of system calls is moving to a seperate >> library (libsys). No changes are required to existing software (except >> to ensure that libsys is present when building custom disk images). >>=20 >> Code: https://github.com/freebsd/freebsd-src/pull/908 >>=20 >> After nearly a decade of intermittent work, I'm about to land a series >> of patches which moves system calls, vdso support, and libc's parsing of >> the ELF auxiliary argument vector into a separate library (libsys). I >> plan to do this early next week (February 5th). >>=20 >> This change serves three primary purposes: >> 1. It's easier to completely replace system call implementations for >> tracing or compartmentalization purposes. >> 2. It simplifies the implementation of restrictions on system calls such= >> as those implemented by OpenBSD's msyscall(2) >> (https://man.openbsd.org/msyscall.2). >> 3. It allows language runtimes to link with libsys for system call >> implementations without requiring libc. >=20 > Awesome! So (3) is generally considered ideal for languages like zig[1], r= ust or go, to use directly? >=20 > What=E2=80=99s the appropriate mechanism for such a language to know which= version of FreeBSD it=E2=80=99s talking to, to ensure syscall table matches= the languages expectations? >=20 > It would be nice to hear about any experiments in (2) and how that compare= s to things such as capsicum. >=20 > [1]: https://github.com/ziglang/zig/issues/165 >=20 > A+ > Dave >=20 >=20 From nobody Sat Feb 3 16:11:42 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 4TRyM65vNgz59fBB for ; Sat, 3 Feb 2024 16:11:46 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRyM614gfz4QT5 for ; Sat, 3 Feb 2024 16:11:46 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=MtZehiXN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-40fccd09082so8047615e9.2 for ; Sat, 03 Feb 2024 08:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706976704; x=1707581504; darn=freebsd.org; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=EmIO7VmnW4Owd43AsoCsu6SF8kDNWHmCvYOfJ/c9bb4=; b=MtZehiXN49UjAGo/BFSixdicl6Xb+bB5jn/U5zWlhsbkCJyxRHlANkD4XRnQGHC+xp RKgL6aiZjCRLovFMECy08rY7G32QTabAm4LGlDzyL1Qw+qAqfuJ4N97rncbXKZWaclA8 PjE7BHGWQoxrzwkRbh7biop64I78L35ZS7j+PppzuxYO796N3KsRZ/55V1XGvJqSLikR seH1iLejd7fk5sIGqwzORv0CnyBDhnEfzOLd3NrEgYJD48S49FTe7rEn3YCncgpzSKN5 q8ucWTPLwg5BCipJZ3BnEG2VSn4pxs9LBLZnKa+3wVqLIo9EmdlohOiQjO2bIe3dTwN4 l9yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706976704; x=1707581504; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=EmIO7VmnW4Owd43AsoCsu6SF8kDNWHmCvYOfJ/c9bb4=; b=jDZq7xZwJDCNrI+KA4RbAApvXkQBNQFyo5yN7YYMnjTwHYOB5Vh7GR8c2hC06y/E24 y7JWhCIJURDYsOS0xjntvugesxbLfFzwXfRY555dgn8XhbG9iPJWDdfl0OxM4pIgIMDU zFeVGLOhYzdXFBEa+oJjy0gb+c6W/2bwaoKu824qlDH4WIMInqODojYRK3cmtx5+CHni 007QUelfYH/PhaWUPqC65D4OF4I7KiSBBnS1xP9mVd7stbu3BOyYGXwtwopfRT7/ONZp YHSNvXvN9CWUCKIh8UWqP96/Du1ygYMJizqfvv5tjN7ag0GQ3QwmUd35MzL4L+CneGd1 P7Lw== X-Gm-Message-State: AOJu0Ywrqf41UDmP1xm6xUNxnZELbZtCiNv+QHH9JDtS9JbEohF5Px0H Lc1kh9a27OlOB6SM0aHEq0W2z/ixIxYpLtN5ECOIxNqNz48jwMh2lGQEMMZR X-Google-Smtp-Source: AGHT+IE81GeYAQISjmYbB/ui5YwgFv92CvpX7f+091uIDpzTh3DZzA3HkIE906o5LoIsDWNwfVDUtA== X-Received: by 2002:a05:600c:5104:b0:40f:d1e4:606d with SMTP id o4-20020a05600c510400b0040fd1e4606dmr897494wms.3.1706976703671; Sat, 03 Feb 2024 08:11:43 -0800 (PST) Received: from [192.168.1.19] ([147.161.183.29]) by smtp.gmail.com with ESMTPSA id l16-20020a05600c4f1000b0040ecdd672fasm3269540wmq.13.2024.02.03.08.11.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Feb 2024 08:11:43 -0800 (PST) Content-Type: multipart/alternative; boundary="------------Lzv0HbUPiLaqwaTtWCEXAQwd" Message-ID: <8a34573d-4a6c-4d5d-a771-b39279059547@gmail.com> Date: Sat, 3 Feb 2024 17:11:42 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: libc/libsys split coming soon To: freebsd-current@freebsd.org References: Content-Language: en-US From: Paul Floyd In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from] X-Rspamd-Queue-Id: 4TRyM614gfz4QT5 This is a multi-part message in MIME format. --------------Lzv0HbUPiLaqwaTtWCEXAQwd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/02/2024 23:31, Brooks Davis wrote: > TL;DR: The implementation of system calls is moving to a seperate > library (libsys). No changes are required to existing software (except > to ensure that libsys is present when building custom disk images). > > Code:https://github.com/freebsd/freebsd-src/pull/908 > > After nearly a decade of intermittent work, I'm about to land a series > of patches which moves system calls, vdso support, and libc's parsing of > the ELF auxiliary argument vector into a separate library (libsys). I > plan to do this early next week (February 5th). > > This change serves three primary purposes: > 1. It's easier to completely replace system call implementations for > tracing or compartmentalization purposes. Will that affect code that makes syscalls without currently linking to libc? > 2. It simplifies the implementation of restrictions on system calls such > as those implemented by OpenBSD's msyscall(2) > (https://man.openbsd.org/msyscall.2). That's one to ignore for tools that make syscalls outside of the libc memory mapping. > 3. It allows language runtimes to link with libsys for system call > implementations without requiring libc. I see that pagesize is on the list of functions that are moving. There are a couple of other functions that might cause me problems if libc isn't linked. Could you do a quick test with an exe linked to libsys but not libc running under Valgrind memcheck, please? A+ Paul --------------Lzv0HbUPiLaqwaTtWCEXAQwd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 02/02/2024 23:31, Brooks Davis wrote:
TL;DR: The implementation of system calls is moving to a seperate
library (libsys).  No changes are required to existing software (except
to ensure that libsys is present when building custom disk images).

Code: https://github.com/freebsd/freebsd-src/pull/908

After nearly a decade of intermittent work, I'm about to land a series
of patches which moves system calls, vdso support, and libc's parsing of
the ELF auxiliary argument vector into a separate library (libsys).  I
plan to do this early next week (February 5th).

This change serves three primary purposes:
  1. It's easier to completely replace system call implementations for
     tracing or compartmentalization purposes.

Will that affect code that makes syscalls without currently linking to libc? 

  2. It simplifies the implementation of restrictions on system calls such
     as those implemented by OpenBSD's msyscall(2)
     (https://man.openbsd.org/msyscall.2).

That's one to ignore for tools that make syscalls outside of the libc memory mapping. 

  3. It allows language runtimes to link with libsys for system call
     implementations without requiring libc.

I see that pagesize is on the list of functions that are moving. There are a couple of other functions that might cause me problems if libc isn't linked.

Could you do a quick test with an exe linked to libsys but not libc running under Valgrind memcheck, please?

A+

Paul

--------------Lzv0HbUPiLaqwaTtWCEXAQwd-- From nobody Sat Feb 3 17:59:25 2024 X-Original-To: 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 4TS0lV2tw0z5857B for ; Sat, 3 Feb 2024 17:59:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS0lT1x24z4hxf; Sat, 3 Feb 2024 17:59:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 413HxP3H070768; Sat, 3 Feb 2024 19:59:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 413HxP3H070768 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 413HxPZK070767; Sat, 3 Feb 2024 19:59:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Feb 2024 19:59:25 +0200 From: Konstantin Belousov To: Mateusz Guzik Cc: David Chisnall , Brooks Davis , current@freebsd.org Subject: Re: libc/libsys split coming soon Message-ID: References: <7E8133B7-4BD5-42AB-8B16-A10F59295F28@FreeBSD.org> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TS0lT1x24z4hxf X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sat, Feb 03, 2024 at 12:12:35PM +0100, Mateusz Guzik wrote: > On 2/3/24, David Chisnall wrote: > > On 3 Feb 2024, at 09:15, Mateusz Guzik wrote: > >> > >> Binary startup is very slow, for example execve of a hello world > >> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 > >> compared to a native one. As such perf-wise this looks like a step in > >> the wrong direction. It is the right change to improve modularity and the structure of the code. > > > > Have you profiled this? Is the Linux version using BIND_NOW (which comes > > with a load of problems, but it often the default for Linux systems and > > reduces the number of slow-path entries into rtld)? Do they trigger the > > same number of CoW faults? Is there a path in rtld that’s slower than the > > equivalent ld-linux.so path? Linux version probably benefits from pre-linking, which might have the side-effect of breaking semantic into as if BIND_NOW is activated. > > > > I only profiled FreeBSD, it was 4 years ago. I have neither time nor > interest in working on this. > > Relevant excerpts from profiling an fexecve loop: > > Sampling what syscalls was being executed when in kernel mode > (or trap): > > syscalls: > pread 108 > fstat 162 > issetugid 250 > sigprocmask 303 > read 310 > mprotect 341 > open 380 > close 1547 > mmap 2787 > trap 5421 > [snip] > In userspace most of the time is spent here: > ld-elf.so.1`memset 406 > ld-elf.so.1`matched_symbol 431 > ld-elf.so.1`strcmp 1078 > ld-elf.so.1`reloc_non_plt 1102 > ld-elf.so.1`symlook_obj 1102 > ld-elf.so.1`find_symdef 1439 > > find_symdef iterates a linked list, which I presume induces strcmp calls > due to unwanted entries. > [snip] So strcmp() is almost 1:1 with reloc_non_plt and/or symlook_obj. It demonstrates that the ELF hash (perhaps GNU hash, but I do not remember how long do we have it) provides very good distribution. From nobody Sat Feb 3 18:01:51 2024 X-Original-To: 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 4TS0pQ3GV3z585qR for ; Sat, 3 Feb 2024 18:02:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS0pQ08D7z4k8M; Sat, 3 Feb 2024 18:02:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 413I1wGV071980; Sat, 3 Feb 2024 20:02:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 413I1wGV071980 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 413I1pum071978; Sat, 3 Feb 2024 20:01:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Feb 2024 20:01:51 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Brooks Davis , current@freebsd.org, Dave Cottlehuber Subject: Re: libc/libsys split coming soon Message-ID: References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TS0pQ08D7z4k8M X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote: > Will this break binary compatibility with older programs expecting those symbols in libc and not linked to libsys? As was mentioned, libc filters libsys. This means that libc exports all the same symbols as before, but forward the implementation to libsys. For apps nothing changes, the introduction of libsys is (should be) ABI compatible. More, I would state that no binaries wanting to state binary-compatble with future FreeBSD should link to libsys directly, at least for now. > > > On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber wrote: > > > > On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote: > >> TL;DR: The implementation of system calls is moving to a seperate > >> library (libsys). No changes are required to existing software (except > >> to ensure that libsys is present when building custom disk images). > >> > >> Code: https://github.com/freebsd/freebsd-src/pull/908 > >> > >> After nearly a decade of intermittent work, I'm about to land a series > >> of patches which moves system calls, vdso support, and libc's parsing of > >> the ELF auxiliary argument vector into a separate library (libsys). I > >> plan to do this early next week (February 5th). > >> > >> This change serves three primary purposes: > >> 1. It's easier to completely replace system call implementations for > >> tracing or compartmentalization purposes. > >> 2. It simplifies the implementation of restrictions on system calls such > >> as those implemented by OpenBSD's msyscall(2) > >> (https://man.openbsd.org/msyscall.2). > >> 3. It allows language runtimes to link with libsys for system call > >> implementations without requiring libc. > > > > Awesome! So (3) is generally considered ideal for languages like zig[1], rust or go, to use directly? > > > > What’s the appropriate mechanism for such a language to know which version of FreeBSD it’s talking to, to ensure syscall table matches the languages expectations? > > > > It would be nice to hear about any experiments in (2) and how that compares to things such as capsicum. > > > > [1]: https://github.com/ziglang/zig/issues/165 > > > > A+ > > Dave > > > > > > From nobody Sat Feb 3 18:10:14 2024 X-Original-To: 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 4TS1044G2jz586Nh for ; Sat, 3 Feb 2024 18:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS1042Ytqz4lkv for ; Sat, 3 Feb 2024 18:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-56001d49cc5so1556264a12.2 for ; Sat, 03 Feb 2024 10:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706983826; x=1707588626; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Tbv2B20jmNJ3pKqe+GZDJ/XSlRR5WRbCO1p0QYKK5K4=; b=WN+/5WwAGWU8SJJ8qpOEL4TRs8cWheiflGgeZ1/yufZH706V1UZqlwtbLBtKSDXZlV jqAn2yN3vMhKgjBJH4K1Fkkmqf4phVziMiPPPB00BrucZ90w4SabzxtQo/sPLIPGQ5Aa 7N9ApTgiHz3LRpCPLM7fjUT9DtuSH6aIDmBAdX8aaa0iJfCxa0T+jAVZkC8U16BYPRzh Eln+H9Dj5qPZlCZ/WfkXePVe0EO2bjqsvm/bqtBlLOHNcybun3t+GZDUEHTbJFVAzW0D DfT3QY5NPBvxIykE3yrR3D8sCRpfy8csB0Bg1cc/246S6ALQby4aLhgBiAyNZo9srGnZ cR9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706983826; x=1707588626; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Tbv2B20jmNJ3pKqe+GZDJ/XSlRR5WRbCO1p0QYKK5K4=; b=dTMnRks+H6COpX3dKXqhICRSYyZwmy9IffItcSq6G6vqZJS/k0OON0CcSrOrpQH6rf CDRR1rysw3xA/0GyjNYu7REORcxS0oPfDpY3tapfw5GNDUdhHDUsNJQ6btln2/E/Xk3F NyEZFMJ4MqpgTyVgrcEssVfIEmQbfrL872n+R18Mf9CIfKUg6Ukn3n6f+g8oQUcCzdpQ 85UR9XJdrcZHn0xNc57hFgdFRe+lE8KfYCQtB0j+QHqM+rBDJhz+VLR4CKgegGnIW3Ua hkXr1DFmSjptueLey7rPkdbvKVmiIfFp/XHBca5SftEYi10H+rZ66SVMvekB4dwXUp8y Bf3w== X-Gm-Message-State: AOJu0YytcJLPO29ZqbwSYG51MzPCyv8atYsX/0fsAByTJvmLy7hUTVlb REcZ/BGFfForlKLZ7+tCujoVryuz+o8eiFcX1gHx6V5ZwJVgulc1WUoetlZb9QJp9flJmI62dI8 LY1bxPE25ION1Vv5x5CuB8W1VBRroDsWJSXnroA== X-Google-Smtp-Source: AGHT+IFW8ktuvkiEQFEyNcEZUGdLyp727t8EHcgbfybeFdcMxGRw+iq3sDdxdkKhrNMhiJlJ1M7ulC5+/uAvf+Mtr+M= X-Received: by 2002:aa7:d804:0:b0:55d:3d64:3ba6 with SMTP id v4-20020aa7d804000000b0055d3d643ba6mr1959517edq.29.1706983826458; Sat, 03 Feb 2024 10:10:26 -0800 (PST) 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 References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> In-Reply-To: From: Warner Losh Date: Sat, 3 Feb 2024 11:10:14 -0700 Message-ID: Subject: Re: libc/libsys split coming soon To: Konstantin Belousov Cc: Daniel Eischen , Brooks Davis , FreeBSD Current , Dave Cottlehuber Content-Type: multipart/alternative; boundary="0000000000009d1e9706107e2491" X-Rspamd-Queue-Id: 4TS1042Ytqz4lkv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000009d1e9706107e2491 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 3, 2024, 11:02=E2=80=AFAM Konstantin Belousov wrote: > On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote: > > Will this break binary compatibility with older programs expecting thos= e > symbols in libc and not linked to libsys? > > As was mentioned, libc filters libsys. This means that libc exports all > the same symbols as before, but forward the implementation to libsys. > For apps nothing changes, the introduction of libsys is (should be) ABI > compatible. > > More, I would state that no binaries wanting to state binary-compatble > with future FreeBSD should link to libsys directly, at least for now. > How do you view Golang or Rust run times using this then? They try to avoid libc today. Warner Warner > > > > > On Feb 3, 2024, at 3:39=E2=80=AFAM, Dave Cottlehuber > wrote: > > > > > > =EF=BB=BFOn Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote: > > >> TL;DR: The implementation of system calls is moving to a seperate > > >> library (libsys). No changes are required to existing software > (except > > >> to ensure that libsys is present when building custom disk images). > > >> > > >> Code: https://github.com/freebsd/freebsd-src/pull/908 > > >> > > >> After nearly a decade of intermittent work, I'm about to land a seri= es > > >> of patches which moves system calls, vdso support, and libc's parsin= g > of > > >> the ELF auxiliary argument vector into a separate library (libsys). = I > > >> plan to do this early next week (February 5th). > > >> > > >> This change serves three primary purposes: > > >> 1. It's easier to completely replace system call implementations fo= r > > >> tracing or compartmentalization purposes. > > >> 2. It simplifies the implementation of restrictions on system calls > such > > >> as those implemented by OpenBSD's msyscall(2) > > >> (https://man.openbsd.org/msyscall.2). > > >> 3. It allows language runtimes to link with libsys for system call > > >> implementations without requiring libc. > > > > > > Awesome! So (3) is generally considered ideal for languages like > zig[1], rust or go, to use directly? > > > > > > What=E2=80=99s the appropriate mechanism for such a language to know = which > version of FreeBSD it=E2=80=99s talking to, to ensure syscall table match= es the > languages expectations? > > > > > > It would be nice to hear about any experiments in (2) and how that > compares to things such as capsicum. > > > > > > [1]: https://github.com/ziglang/zig/issues/165 > > > > > > A+ > > > Dave > > > > > > > > > > > > --0000000000009d1e9706107e2491 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Feb 3, 2024, 11:02=E2=80=AFAM Konstantin Belou= sov <kostikbel@gmail.com> = wrote:
On Sat, Feb 03, 2024 at 11:0= 5:10AM -0500, Daniel Eischen wrote:
> Will this break binary compatibility with older programs expecting tho= se symbols in libc and not linked to libsys?

As was mentioned, libc filters libsys.=C2=A0 This means that libc exports a= ll
the same symbols as before, but forward the implementation to libsys.
For apps nothing changes, the introduction of libsys is (should be) ABI
compatible.

More, I would state that no binaries wanting to state binary-compatble
with future FreeBSD should link to libsys directly, at least for now.

How do= you view Golang or Rust run times using this then? They try to avoid libc = today.

Warner

Warner
>
> > On Feb 3, 2024, at 3:39=E2=80=AFAM, Dave Cottlehuber <dch@skun= kwerks.at> wrote:
> >
> > =EF=BB=BFOn Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> >> TL;DR: The implementation of system calls is moving to a sepe= rate
> >> library (libsys).=C2=A0 No changes are required to existing s= oftware (except
> >> to ensure that libsys is present when building custom disk im= ages).
> >>
> >> Code: https://github.com/fre= ebsd/freebsd-src/pull/908
> >>
> >> After nearly a decade of intermittent work, I'm about to = land a series
> >> of patches which moves system calls, vdso support, and libc&#= 39;s parsing of
> >> the ELF auxiliary argument vector into a separate library (li= bsys).=C2=A0 I
> >> plan to do this early next week (February 5th).
> >>
> >> This change serves three primary purposes:
> >>=C2=A0 1. It's easier to completely replace system call im= plementations for
> >>=C2=A0 =C2=A0 =C2=A0tracing or compartmentalization purposes.<= br> > >>=C2=A0 2. It simplifies the implementation of restrictions on = system calls such
> >>=C2=A0 =C2=A0 =C2=A0as those implemented by OpenBSD's msys= call(2)
> >>=C2=A0 =C2=A0 =C2=A0(https://man.openbsd.o= rg/msyscall.2).
> >>=C2=A0 3. It allows language runtimes to link with libsys for = system call
> >>=C2=A0 =C2=A0 =C2=A0implementations without requiring libc. > >
> > Awesome! So (3) is generally considered ideal for languages like = zig[1], rust or go, to use directly?
> >
> > What=E2=80=99s the appropriate mechanism for such a language to k= now which version of FreeBSD it=E2=80=99s talking to, to ensure syscall tab= le matches the languages expectations?
> >
> > It would be nice to hear about any experiments in (2) and how tha= t compares to things such as capsicum.
> >
> > [1]: https://github.com/ziglang/zig/is= sues/165
> >
> > A+
> > Dave
> >
> >
>
>

--0000000000009d1e9706107e2491-- From nobody Sat Feb 3 18:33:11 2024 X-Original-To: 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 4TS1Vb3Bxdz588yt for ; Sat, 3 Feb 2024 18:33:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4TS1Vb0XqSz4qK2; Sat, 3 Feb 2024 18:33:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 413IXBZB079828; Sat, 3 Feb 2024 20:33:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 413IXBZB079828 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 413IXBfQ079827; Sat, 3 Feb 2024 20:33:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Feb 2024 20:33:11 +0200 From: Konstantin Belousov To: Warner Losh Cc: Daniel Eischen , Brooks Davis , FreeBSD Current , Dave Cottlehuber Subject: Re: libc/libsys split coming soon Message-ID: References: <458c2a3b-1139-4449-a4a9-f23782686dea@app.fastmail.com> <082DBB76-B8B0-4583-BDE4-B6DCD1DAD133@vigrid.com> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TS1Vb0XqSz4qK2 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sat, Feb 03, 2024 at 11:10:14AM -0700, Warner Losh wrote: > On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov > wrote: > > > On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote: > > > Will this break binary compatibility with older programs expecting those > > symbols in libc and not linked to libsys? > > > > As was mentioned, libc filters libsys. This means that libc exports all > > the same symbols as before, but forward the implementation to libsys. > > For apps nothing changes, the introduction of libsys is (should be) ABI > > compatible. > > > > More, I would state that no binaries wanting to state binary-compatble > > with future FreeBSD should link to libsys directly, at least for now. > > > > How do you view Golang or Rust run times using this then? They try to avoid > libc today. Goland runtime issues syscalls directly (using CPU instructions). I believe this is true even when Go-compiled binary is linked against libc to provide C FFI. Rust does use libc to get system services. No changes there. Or, is you question about switching Go and Rust to directly using libsys? Then Rust does not need that. For Go, indeed, using either libc or libsys instead of static linking and directly issuing syscalls would be better. Right now Go binary needs to understand all small details in the difference between C wrappers ABI and real syscalls. Also they re-wrote e.g. the gettime() code from vdso into their runtime. > > Warner > > Warner > > > > > > > > On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber > > wrote: > > > > > > > > On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote: > > > >> TL;DR: The implementation of system calls is moving to a seperate > > > >> library (libsys). No changes are required to existing software > > (except > > > >> to ensure that libsys is present when building custom disk images). > > > >> > > > >> Code: https://github.com/freebsd/freebsd-src/pull/908 > > > >> > > > >> After nearly a decade of intermittent work, I'm about to land a series > > > >> of patches which moves system calls, vdso support, and libc's parsing > > of > > > >> the ELF auxiliary argument vector into a separate library (libsys). I > > > >> plan to do this early next week (February 5th). > > > >> > > > >> This change serves three primary purposes: > > > >> 1. It's easier to completely replace system call implementations for > > > >> tracing or compartmentalization purposes. > > > >> 2. It simplifies the implementation of restrictions on system calls > > such > > > >> as those implemented by OpenBSD's msyscall(2) > > > >> (https://man.openbsd.org/msyscall.2). > > > >> 3. It allows language runtimes to link with libsys for system call > > > >> implementations without requiring libc. > > > > > > > > Awesome! So (3) is generally considered ideal for languages like > > zig[1], rust or go, to use directly? > > > > > > > > What’s the appropriate mechanism for such a language to know which > > version of FreeBSD it’s talking to, to ensure syscall table matches the > > languages expectations? > > > > > > > > It would be nice to hear about any experiments in (2) and how that > > compares to things such as capsicum. > > > > > > > > [1]: https://github.com/ziglang/zig/issues/165 > > > > > > > > A+ > > > > Dave > > > > > > > > > > > > > > > > > >