From nobody Sun Jan 14 23:08:15 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 4TCrY4202Rz56vxY for ; Sun, 14 Jan 2024 23:08:24 +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 4TCrY41GdRz4VLk; Sun, 14 Jan 2024 23:08:24 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705273704; 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=7aRLUNSbMcoYutn7p8xDxbaYcikAiDbN2YsSZPn4QIg=; b=ZC0RGZID/CEJycjg5PLk8VRm7HT3p7VZ7+XPHUirwCFn1HC9eM+A8jKWHtJXLGh+dENFGi W74mN+7L7nOWAyPpbB87O7iCyXQGwGQTZV0cMKu8MTfvTqOM4nmMDS336m+2nvv3CXyqu6 4rz0//kVikw1LMUJOXCtwlS85fd9E4zpvGQYyKtlPpnMJdrPaje6dewIxzBdKQdCTK3JNG Q8afKAGOtZ/hKGMrmxHHvCMqTn04gy2ER5JXDXpK3S9F8JXPXZs87vSm6SUAiox9aGceYS ysFBJby+UlOvsB4SS7BQty/YwqdyWLrtjb3/AWVk3Ck6CfPgVD2mBQRR4V1vYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705273704; 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=7aRLUNSbMcoYutn7p8xDxbaYcikAiDbN2YsSZPn4QIg=; b=XJVmgsT7pY1+gGOfcdbGqHqtjxcLcEPCom7o35oj97ebQsv5083WULJ+hkHmhEf2bEkkCp z4D14Va8xLBSQ1TvSqMWCoc4e7zUEfL5CdRwq5iY86jSH49UAkUcx1i9dafb516BO/fD96 9kgOYjC5BwM/N8Tc9OylQsXYx2IJkcZkmmsAej5tD8xSpz6fg7bTWXJdCqUGz1IiCYWaiP 8yi4zpZsyJ+UMVgH/XG5WnRHvESClSIYCFbEtLyU3rVIBilUFNxbSJG9cl9x7e9eC0vuxZ QLwfRjiKllDi0o1q+4r190AI3miAM6NlxfMPQNj8liDbSuD/L6uB56/l+yTfRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705273704; a=rsa-sha256; cv=none; b=THblt+dRJtqec3jjzed/RViPZ8Tfh+hsKT6VhCRaK/QqnBQDqwpzNeefyG1AgzQ1YdvuxR KEJvp3BxkzfQcbi+zKZ2jvK/DEirrmHfD7maaPz9jenNJslkje3iJKeS6sZSNu8ikfLAFM 1uaDJWy4JwYqowMlOaAzmTHPsxbwdqV3U5EviTViVSDQ+vkZo/cOTtLMuFdeS6AC59isHN Zkh9VBrJJJg4QqRVcw5tW8VE+pYKCaTQAI6Lh6yb8Ew9q4R2d8PmP7NS7gLmVcfVh2eSab 1oLwnH1/k52adjrJRMNN3MO7OAt0nd4slaAhfAY9QQ0H4im5hsI7502em5kO5w== 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 4TCrY33dPqz1CPn; Sun, 14 Jan 2024 23:08:23 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Warner Losh Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" , Rick Macklem , FreeBSD Current Subject: Re: noatime on ufs2 Date: Mon, 15 Jan 2024 00:08:15 +0100 Message-ID: <2798057.DSuhTWmZiM@ravel> 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/signed; boundary="nextPart3294561.CbG7YiG8N7"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart3294561.CbG7YiG8N7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Warner Losh Subject: Re: noatime on ufs2 Date: Mon, 15 Jan 2024 00:08:15 +0100 Message-ID: <2798057.DSuhTWmZiM@ravel> MIME-Version: 1.0 Hi Warner, > The consensus was we'd fix it in the installer. Isn't speaking about a "consensus", at least as a general response to the i= dea of making 'noatime' the default, a little premature? I have more to sa= y on this topic (see below). Also, I would not dismiss Lyndon's last mail = too quickly, and in particular the last paragraph. I'm as interested as he= is about possible answers for it. > We can't change ZFS easily, and discovery of the problem, should your > assertion be wrong, for UFS means metadata loss that can't be recovered. Why ZFS would need changing? If you're referring to an earlier objection f= rom Mark Millard, I don't think it stands, please see my response to him. = Else, I don't know what you're referring to. If I'm understanding you correctly, strictly speaking, it's true there woul= d be metadata loss (access times cease to be updated). As a reminder, this= only concerns people caring about access times, and who wouldn't notice th= e change in default despite it being publicized, so a small minority as we = can forecast for now. Furthermore, for the scenarios already presented, re= covering exact lost metadata is not necessary, their absence "only" complic= ates matters temporarily. To know which files/packages are used, you insta= ll them and then run your system for enough time (more or less arbitrary) b= efore checking the access times. Unless you're monitoring a very specific = access pattern that would be hard to reproduce, you can just repeat the exp= erience when access times are re-enabled. For backups, access times could = be used to know which files really matter, but then you have the option to = backup them all instead until you get the metadata for the next backup. Al= l that assuming, as said in an earlier mail, that nothing has messed up wit= h the access times in the meantime, which would ruin the feasibility of suc= h scenarios in the first place. > By pushing to the installer, most installations get most of benefits. And > people with special needs see the issue and can make an informed choice. I agree for those who use the installer. But I'm not sure which proportion= of users they represent, and especially for those who care about disabling= access times. As for me, I don't think I have used the installer in the p= ast 10 years (to be safe). Is this such an atypical behavior? Additionally, the installer doesn't cover other use cases: =2D Mounting filesystems by hand on USB keys or other removal medias (which= are not in '/etc/fstab'). This causes users to have to remember to add 'n= oatime' on the command-line. =2D Using auto-mounters. They have to be configured to use 'noatime'. =2D Desktop environments shipping a mount helper. Again, they have to be c= onfigured, if at all possible. So limiting action to the installer, while certainly a sensible and pragmat= ic step, still seems to miss a lot. > Though in all honesty, I've never been able to measure a speed difference. > Nor have I worn out a ssd due to the tiny increase in write amp. Old > (<100MB) SD and CF cards included. This includes my armv7 based dns server > that I ran for a decade on a 256MB SD card with no special settings and > full read/write and lots of logging. So the harm is minimal typically. I'm > sure there are cases that it matters more than my experience. And it is > good practice to enable noatime. Just that failure to do so typically has > only a marginal effect. It seemed to make a difference on slow USB keys (well, not just evenly slow= , but which could exhibit strange pauses while writing), but I didn't gathe= r enough hard data to call that "scientific". I sometimes manage to satura= te M2 SSD I/O bandwidth but then I always use 'noatime', so not sure how mu= ch a difference it makes. The "updatedb" scenario that runs 'find' causes = access time updates for all directories, causing spikes in the number of wr= ites which may affect the response time during the process. That said, it = is only run once a week by default. I would say that most of the value of having 'noatime' the default is in le= ss tweaking by most people, and one less thing to worry about (for them). I proposed in another mail having a sysctl which indicates the default ('no= atime' or 'atime') for all filesystems. This default would be used at moun= t time if neither 'atime' nor 'noatime' is explicitly specified. That way,= people wanting 'noatime' by default everywhere could just set it to that. = It may also convince reticent people to have the default (i.e., this sysct= l's default value) changed to 'noatime', by providing a very simple way to = revert to the old behavior. Thanks and regards. =2D-=20 Olivier Certner --nextPart3294561.CbG7YiG8N7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkaWAACgkQjKEwQJce Jid1fA/9GY6er1xPMtA6COTeFy77RHMlF4PfuZOH8uGjTDgqMEyhLI96VbE5R65e JJew7lixtYF+l96zUV4BMAb4LSOCL00XbHe0Nu0WPKiu85ALGHoCHF6Vf6MKtXjY xLMP/NofZvYzXsy4WH1tr8a+6yS+Fdsm6w15/ZmFdy1YvsiFsfAPDgKB4XcwOhHO W+BuyKaZrnpryKQP+aY3J+D4fsROHxO3MHmI6to5uAXuRi7DNh1jHW6CODh8qm2+ AiD/UysLmS+A60u3XXZ9tgtNw8IyZLqT0JE334Gf1qGMHcjYVO9q6WICSgmLlpM2 iujCaCql8v3WkW7O1JX+ubqmHEF4WImJ4C5nZfGW8QgFied9WhSHb04e0QQNKu83 UuShOk69r6XL0lrOjojp2Gd5E3ot5ebL8KdSld/mVkHjl9hA63QaiSjKcYJQNRcX gVeWsdF3frsiPb08egVqxOHBqjVK/+1So2Te8xhGQGthqLMMGU5N8X0F4iVqXFoQ vohjBDu+a6bmJN+YwsdAWZB8juOJB6il1hZF9VTVFEDretJJfo6xo5Jpff1QSkze 8x2VQX5DUIraUamB1hu51+gwVf3+2DRewhRzvUzuqfdUuz2gbzFEp9CGcAGfG5lA 9bZQDlOQPB8dahKMNDn2mAgfcIwv/6eDCSPLFp5wNIN6DmjV520= =NJYe -----END PGP SIGNATURE----- --nextPart3294561.CbG7YiG8N7--