From nobody Mon Jan 8 00:46: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 4T7b3d1tk6z56RKD for ; Mon, 8 Jan 2024 00:46:37 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4T7b3b16qYz4hFY; Mon, 8 Jan 2024 00:46:34 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:7400:8808:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 4080kLWm043904; Mon, 8 Jan 2024 00:46:21 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 4080kKjd043903; Mon, 8 Jan 2024 00:46:20 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401080046.4080kKjd043903@donotpassgo.dyslexicfish.net> Date: Mon, 08 Jan 2024 00:46:20 +0000 Organization: Dyslexic Fish To: jamie@catflap.org, imp@bsdimp.com Cc: junchoon@dec.sakura.ne.jp, freebsd-current@freebsd.org, brooks@freebsd.org, bakul@iitbombay.org Subject: Re: git repo port issues? References: <202401031913.403JDZBt028036@donotpassgo.dyslexicfish.net> <46C8698A-A004-4B5F-9107-6D9FD3685074@iitbombay.org> <20240104183539.cef54811b98fe53c5841edca@dec.sakura.ne.jp> <202401041914.404JEJCm083648@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 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: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Mon, 08 Jan 2024 00:46:21 +0000 (GMT) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.44 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.74)[-0.745]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[jamie]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4T7b3b16qYz4hFY Warner Losh wrote: > See sys/conf/newvers.sh for the 'n' value we use in uname strings. It's a > linear count of commits on the first-parent branch back to the start of the > repo. > > Also, the dates usualy are first order correct and i use them for the stats > i run. Though I've also just dropped tags on the first commit of each year > too... Ahhh brilliant, thanks! I didn't know about that. That looks like just what I'm after. Is it safe to assume that all commits in a cloned and then fetched/pulled repo will have the commits in the same order as the parent? Also, are "null commits", where there is a commit but no actual files commited (not sure what those are for!) counted too? (example: https://cgit.dyslexicfish.net/src/current/commit/?id=cb4ff25c8a40e6811f48f6ad03a0bf882404e9ac ) I'll never understand the nuances of operating day to day with git like you guys, so I'm grateful for the help and patience you have shown, especially when I come out with an idea that is basically dumb. Cheers, Jamie From nobody Mon Jan 8 03:12: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 4T7fHm1JgVz56jQb for ; Mon, 8 Jan 2024 03:12:20 +0000 (UTC) (envelope-from zlei@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 4T7fHm0sgPz4vBy; Mon, 8 Jan 2024 03:12:20 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704683540; 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=s1TT9Zy6EqP8Obn+VdjXFVU+4U5zY/MvR5aUUHSfLK4=; b=Nh2cuky3RWpjMfFXuG0hyjpRPSuN9VtYGDNvx78Fv3t3GNNU/QshH9hfry06uIbPqxI4PZ Jw+CGJPRYhRcRGRx5nKwmE3AMJPiJsBhZ3Z28AtkPnEW01VVU4/GNx2PdSHO//nPS04Ojf P3qZtcWML6/VeOYWvG7rdJIg0oJsU1YY35pMa8bk81VNQt/XEMJLifTYM0sV+gVNAq+QeG EpjalK5iBmgf/8kAKsvkGZMjMdoHjQNsD/ITP7H7n2FGjc5PNfbbp7KYpn85xGTFUQizzw 24FtjNRIzQwatEAHSAUehZ/npnb3pXhAW9U7B7j69yFJr5brfK/s04IDrATaHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704683540; 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=s1TT9Zy6EqP8Obn+VdjXFVU+4U5zY/MvR5aUUHSfLK4=; b=sg2Vag4coYNd8jPkmwL7ZLlZ/I51LVR3UaKuiJ8KbCL8ZVAECsFJp3qg3SmKJ99PDkcf/9 q3pSV99ziRvQAMMrPNEpluCWGkpgROIT3flbRLM+NJSImHd3br1n1KMjXvz0/Fqq8H1IUo QdgKyam5CaVV75PXYDKPWFpqtwkiLHtjZg7ZvDh4k9a6KoWp/5I1JcsPn4IOcAFaL1tA8p Tzm3V+F+naBMiLjrR01B1ApVGeIEXFaDV1VJ0JYNce3RVnGzDbeMz4ie9K62FuTlWbL9HM kGXsX9oBq9T29iiGt9fhQLv8s46iFeK0BNZgye1J3hpsA0XDDA2NwCNuA8VvLg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704683540; a=rsa-sha256; cv=none; b=OBlgGMZWsSahw2lCk60dplaXV1BvT8jOase+da5WWXunY2/D1Z2eIp0iJKkCsGBGkyH5KK wq7ZO/+X5w3E/pgmrkMrf+kACx/TVZomjixCeS9ErOYehDMw53XyBKkhEKOKgSVndUGIHl 4bMhtl8wJs+P0RGuIuceqEubNdygrGdtins1KNeWPraTpKTGWVvz3ozv6RaU6kjPxiKWDr qY3iWYodTo/wbyNVb9u/bEz2trurDzo+53Of/vlg1xoBX4RC00EgJrnZT78XjfUsQ8RrgA 2xCMurq2g4UXSxuCTWAy22hJIl7NZr3ndrxWDy4//WiGKBs5/9nszYOb3VSf+Q== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T7fHl1vNfzhvr; Mon, 8 Jan 2024 03:12:19 +0000 (UTC) (envelope-from zlei@FreeBSD.org) 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 \(3696.120.41.1.4\)) Subject: Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6) From: Zhenlei Huang In-Reply-To: <20240107185057.73c66433@thor.intern.walstatt.dynvpn.de> Date: Mon, 8 Jan 2024 11:12:13 +0800 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <70958CF6-CEF5-43BD-B45C-9765B264BD23@FreeBSD.org> References: <20240107185057.73c66433@thor.intern.walstatt.dynvpn.de> To: FreeBSD User X-Mailer: Apple Mail (2.3696.120.41.1.4) > On Jan 8, 2024, at 1:50 AM, FreeBSD User = wrote: >=20 > Hello, >=20 > I've got a problem with recent CURRENT, running vnet JAILs. > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 = CET 2024 amd64 >=20 > Main Host has IPFW configured and is open for services like OpenLDAP = on UDP/TCP and ICMP > (ipfw is configured via rc.conf in this case, host is listening on = both protocol families > IPv4 and IPv6).=20 >=20 > The host itself has openldap-server 2.6 as a service. The host's = interface is igb0 with > assigned ULA. JAILs (around eight jails) are sharing their vnet = interfaces via a bridge with > the same physical device as the host (igb0). After a while (the time = elapsed is unspecific) How did you create your jails , are they vnet jails ?=20 Is that bridge + epair ? > the jail is unable to contact the host via IPv6: neither UDP, TCP nor = ICMP sent from the JAIL > is reaching the host. IPv4 is working like a charme! No problems = there. >=20 > When pinging the Jail from the main host via ping -6, the jail is = responding! After the first > ping -6, the jail now is able to ping -6 the main host. >=20 > After a fresh reboot, the problem is not present and occurs after a = while and it seems to > happen first to very active jails. >=20 > Kind regards, >=20 > oh >=20 >=20 > --=20 > O. Hartmann >=20 Best regards, Zhenlei From nobody Mon Jan 8 09:40: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 4T7pwG3RtMz57RgZ for ; Mon, 8 Jan 2024 09:41:02 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4T7pwF3wqwz4nTq for ; Mon, 8 Jan 2024 09:41:01 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=alvermark.net header.s=x header.b=HWRIdcQp; dmarc=none; spf=pass (mx1.freebsd.org: domain of jakob@alvermark.net designates 185.34.136.138 as permitted sender) smtp.mailfrom=jakob@alvermark.net Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1rMm6X-000Chw-0o for freebsd-current@freebsd.org; Mon, 08 Jan 2024 10:39:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bLG9e54BJ/mW11AvfUGHt3l/CNPPx/YCkuw8vTIGrXc=; b=HWRIdcQpDs1rzkB/vmjWrnpUz9 qG4y7RdI3+9Hqy1S1rL803gd6PyJaC1otITYPyDvnvtuHkbn71kBBl5hB0NWoCcVFj0ziyuNBZMqE NgH13bzBcWaeom5x3S4ajlhpQ0MI8Cdqy5yxhmiNADpnbs4+wSj+HmbkKU3Zhc1vxtjemhr7g51/2 VYfrxm4H/r63rwCMUjnA6jRqEKy+6yUznS5+vhrO9jXGav+00lyRU/VQikEcB74YAQE8E/3R6TAYR MbQNDu8JkGJL3s309Jf27yBBNxl5gc79eExxNfgv4T71Cc7wH2GCxqJHaHvlUVuKHg9kk4hy7lck1 eiMRPaIQ==; Received: from [192.168.67.27] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1rMm7o-000CjC-Ry for freebsd-current@freebsd.org; Mon, 08 Jan 2024 10:40:52 +0100 Message-ID: Date: Mon, 8 Jan 2024 10:40:52 +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: e179d973 insta-panics in nl_send_one() Content-Language: en-US To: freebsd-current@freebsd.org References: <202401062231.406MVrxT002354@critter.freebsd.dk> <202401062234.406MYJ6E004159@critter.freebsd.dk> From: Jakob Alvermark In-Reply-To: <202401062234.406MYJ6E004159@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.04 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.55)[-0.553]; R_SPF_ALLOW(-0.20)[+ip4:185.34.136.138]; R_DKIM_ALLOW(-0.20)[alvermark.net:s=x]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[alvermark.net: no valid DMARC record]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[alvermark.net:+] X-Rspamd-Queue-Id: 4T7pwF3wqwz4nTq On 1/6/24 23:34, Poul-Henning Kamp wrote: > Addendum: > > I have only installed the new kernel, userland is still from dec18. > > (Even if that is the cause, we should not panic on bad syscall args.) > > Poul-Henning Kamp writes: >> With fresh current: >> >> commit e179d9739b1438ae9acb958f80a983eff7e3dce9 >> Author: Michael Tuexen >> Date: Sat Jan 6 21:31:46 2024 +0100 >> >> tcpsso: support TIME_WAIT state >> >> I get an insta-panic as soon as any network interface comes up: >> >> --- trap 0xc, rip = 0xffff...f80d97b78, rsp = 0x... >> nl_send_one() at nl_send_one+0x18/frame 0xf.... >> nl_send_group() at nl_send_group+0x1bc/frame 0xf... >> _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf... >> rtnl_handle_ifevent() + 0xa1 >> if_attach_internal + 0x3df >> >> I have a picture of the full panic if desired... >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk@FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. I get the same panic, with kernel and userland both installed. Jakob From nobody Mon Jan 8 14:50:47 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 4T7xtp55CSz55y6W for ; Mon, 8 Jan 2024 14:55:14 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T7xtp0VdRz4Fwc for ; Mon, 8 Jan 2024 14:55:13 +0000 (UTC) (envelope-from naddy@mips.inka.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of naddy@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=naddy@mips.inka.de Received: from mips.inka.de (naddy@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1rMr1s-0051nT-Je; Mon, 08 Jan 2024 15:55:04 +0100 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.17.1/8.17.1) with ESMTP id 408EolbT022413 for ; Mon, 8 Jan 2024 15:50:47 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.17.1/8.17.1/Submit) id 408EolAh022412 for freebsd-current@freebsd.org; Mon, 8 Jan 2024 15:50:47 +0100 (CET) (envelope-from naddy) Date: Mon, 8 Jan 2024 15:50:47 +0100 From: Christian Weisgerber To: freebsd-current@freebsd.org Subject: Move u2f-devd into base? 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=us-ascii Content-Disposition: inline X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[naddy]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[inka.de]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4T7xtp0VdRz4Fwc We have FIDO/U2F support for SSH in base. We also have a group "u2f", 116, in the default /etc/group file. Why do we keep the devd configuration (to chgrp the device nodes) in a port, security/u2f-devd? Can't we just add this to base, too? It's just another devd configuration file. -- Christian "naddy" Weisgerber naddy@mips.inka.de From nobody Mon Jan 8 15:18:38 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 4T7yQ24qg1z563Vf for ; Mon, 8 Jan 2024 15:18:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 4T7yQ234tNz4M6x for ; Mon, 8 Jan 2024 15:18:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a1915034144so194460666b.0 for ; Mon, 08 Jan 2024 07:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704727129; x=1705331929; 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=cca2W/jzdDaBY+dh0127urO3AVXohqNzkIzOSQH3qsw=; b=w/3kCE/CvNDYZbqQIZJQ+AuCGclVUuI4s1HtBFe3wO/06vgKhEN0Z+svEFMXmIF3gy 5h9zSqEwfU6SILy4b4GevjjymTS717PFZVtmFgLKw7QtGh//tZAPaqcManP7Cd4ga0EQ fNxqssEoDSZxWvswxEU5VA14sRWgUYlszrn8x6XZdZ0WE8jomEfMUQcPQFoixOX81Hip FwY/P0n+rAkVpyXn6qtLMjywWm3pQCqO3muu5gf6WIAuSodtg5TKEFKS91qxe0+5a7nd 3Qe0NKIdHD7ANyBMBFKhXWVHcq87j5beag3DASYC4cI5Y6oWDcqsTvyn7D8BNFf5E6pf QzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704727129; x=1705331929; 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=cca2W/jzdDaBY+dh0127urO3AVXohqNzkIzOSQH3qsw=; b=AdRC6R2owdzfu6QrtXJeR4gItgJiHT4gV/ryEiCprxbytLKWKdlwjKwq3in+H1B7H6 syWZGh6I1uJ5bCCdCfVSLuvre9CfRgNTvRFol9VhugCgw530OMcw6L4ma4XCh1xFW9PZ o8Q7VsTB180nRjhQb0rN2H17bbvE4qABdmmuOQ1V4+vPbUdIzJ1WWsp4ljdMercfW+xb fMdkYlY8R+MRvvD9QWpC1/Y0efzYG25e8vF/nPb/yAXhokoiLWtZngaEt+wRAqKiYjWl uGgIn5Ks6pN+oxLVWUaw8ZoHS1byKFuxNSEgbt2hkajXuK+BoXoeavDEk3Smk8MAFBS7 DmjQ== X-Gm-Message-State: AOJu0YzBiSqE1BHbVDSxeYGnO4Ruoai7Q+RiSC50utwKyWEgb2kaCTOZ 1fxlktM1G+0D4qyeHwM2IpjBpAOUqcbi0gmZQOgURrOBC7S00oA0VEpJvgPvI1M= X-Google-Smtp-Source: AGHT+IElIVWXB39mSefFVYtmQk5aJ8V7wubDE7BNb8XkywOeox/rp7LMDTw6Y5m3QbKlOY6hIVxYfy0AmhKY78yOdIE= X-Received: by 2002:a17:906:cb08:b0:a2a:1343:5b18 with SMTP id lk8-20020a170906cb0800b00a2a13435b18mr1040346ejb.86.1704727129097; Mon, 08 Jan 2024 07:18:49 -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: Mon, 8 Jan 2024 08:18:38 -0700 Message-ID: Subject: Re: Move u2f-devd into base? To: Christian Weisgerber Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000f817b9060e70b6fa" X-Rspamd-Queue-Id: 4T7yQ234tNz4M6x 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] --000000000000f817b9060e70b6fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber wrote: > We have FIDO/U2F support for SSH in base. > > We also have a group "u2f", 116, in the default /etc/group file. > > Why do we keep the devd configuration (to chgrp the device nodes) > in a port, security/u2f-devd? Can't we just add this to base, too? > It's just another devd configuration file. > This properly belongs to devfs.conf no? Otherwise it's a race... Warner --=20 > Christian "naddy" Weisgerber naddy@mips.inka.de > > --000000000000f817b9060e70b6fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisger= ber <naddy@mips.inka.de> wr= ote:
We have FIDO/U2F support for S= SH in base.

We also have a group "u2f", 116, in the default /etc/group file.<= br>
Why do we keep the devd configuration (to chgrp the device nodes)
in a port, security/u2f-devd?=C2=A0 Can't we just add this to base, too= ?
It's just another devd configuration file.
=

This properly belongs to devf= s.conf no? Otherwise it's a race...=C2=A0

Warner

--
Christian "naddy" Weisgerber=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 naddy@mips.inka.de<= /a>

--000000000000f817b9060e70b6fa-- From nobody Mon Jan 8 16:30: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 4T801S4TTqz56GQH for ; Mon, 8 Jan 2024 16:31:08 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4T801R5jT2z4Y3w for ; Mon, 8 Jan 2024 16:31:07 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 408GUx9k002393; Tue, 9 Jan 2024 01:30:59 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 9 Jan 2024 01:30:58 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Christian Weisgerber , FreeBSD Current Subject: Re: Move u2f-devd into base? Message-Id: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (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-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4T801R5jT2z4Y3w 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:7684, ipnet:153.125.128.0/18, country:JP] On Mon, 8 Jan 2024 08:18:38 -0700 Warner Losh wrote: > On Mon, Jan 8, 2024, 7:55$B".(BAM Christian Weisgerber > wrote: > > > We have FIDO/U2F support for SSH in base. > > > > We also have a group "u2f", 116, in the default /etc/group file. > > > > Why do we keep the devd configuration (to chgrp the device nodes) > > in a port, security/u2f-devd? Can't we just add this to base, too? > > It's just another devd configuration file. > > > > This properly belongs to devfs.conf no? Otherwise it's a race... > > Warner > > -- > > Christian "naddy" Weisgerber naddy@mips.inka.de It's devd.conf materials. It actually is security/usf-devd/files u2f.conf and its contents is sets of notify 100 { match "vendor" ... match "product" ... action "chgrpy u2f ..." };. Some hase more items in it, though. So it should be in ports to adapt for latest products more quickly than in base, I think. -- Tomoaki AOKI From nobody Mon Jan 8 16:35: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 4T80610Frtz56Ggs for ; Mon, 8 Jan 2024 16:35:05 +0000 (UTC) (envelope-from kevans@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 4T80606xJgz4ZWk for ; Mon, 8 Jan 2024 16:35:04 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704731705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CAT/0q2wb1BRQw1OoVfsiBGcWHvKkVofeAOq5ajY9jY=; b=xnHswkXt1LnUo+kqbxOwU2/yYhLJiNYjz2kFVa5khkm1uXoSWIL+fVulAbMKUc0q7fihud gKb4CIHurCjCVWgKdKctb3ew9jTjZ8//tEJ7nUyzgqZj397m1rG5qy8BVmUYbSxq/TgS9R iudEYtJPZ8qnCCgcJ3nM0wtYU0T7qaweKK1XGU08qkaEW7v/rYYhe0JcVWqIMXpZovU53M LOBxK+p83aWAv1E9xMS00NEx5o8FPQQaj2owcwIyPogJ6WrC2Qd0OkhhJOcLO87kA4rDTc 2HdPv0ZYcf51mr0Wv2iA4UO9J4+vp/6ivTAZ0OkTGp5CPcMF4NP9LluWkypRFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704731705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CAT/0q2wb1BRQw1OoVfsiBGcWHvKkVofeAOq5ajY9jY=; b=BeYZymkyaNR4OG7Q9nNLK3Vuhy7GvcT2Ae1TXwJ/HKKfF74Lly7wqaoVZYSsYoAOuBzZFi 0LSHFhJE7ojgp+abz/dpineYni2SPNjND1br1+t7o85xKkijJypmwoOs/OlA8erFRXvs06 p+IGYLHERZg4PuDGK+3cTTHfGXOtSmZ7HNTLSU7G9bvpbJbNzVfgoi/7L+mveHJcSWtH/P iO8/vFEez2OQQPPqXEckEM+IgJvgZ4Pengex6kmAl7T8uOExkkMwvTgkuTQJCnIAq2hf+s Z9CpNU9MIfjUkfAk96u4BZNa+ypeps95rTNdYU5ooZQATFn2mA2oSjHpsMPzBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704731705; a=rsa-sha256; cv=none; b=aAaZEO8P48v9ezutWCvowJrWZ91dwaebVZIqGe9T4CrzdjNUIhwvrb1FnKVYmEVY3icCg9 CD0vXPAFsZ368l7yAwICCTttXdfWnALuA0ZrnhDolTNfLtVfSB7iHTg2gRfy/nw+05/r/t X/Pnkgl6TFJbW7HmQGxLKDzRou8E+uxRoz51tZqj2z+WSP4rVXk3RtYowS0xwtC7nshryg X9D9Kdj9da+dzaXlknr+5J1zYM9GbamcJdE/FZIpgE4vBT9eTaOBIkCPehCcbUTLu/Uwvu eyu+yKONZkwVbW1SfeWPfpbKXjAJ16PD8wRCI4K5+oGTdvxZcrRvzQEx+6rxJQ== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T80603z8dz19rB for ; Mon, 8 Jan 2024 16:35:04 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Mon, 8 Jan 2024 10:35:03 -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 User-Agent: Mozilla Thunderbird Subject: Re: Move u2f-devd into base? Content-Language: en-US To: freebsd-current@freebsd.org References: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> From: Kyle Evans In-Reply-To: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/8/24 10:30, Tomoaki AOKI wrote: > On Mon, 8 Jan 2024 08:18:38 -0700 > Warner Losh wrote: > >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber >> wrote: >> >>> We have FIDO/U2F support for SSH in base. >>> >>> We also have a group "u2f", 116, in the default /etc/group file. >>> >>> Why do we keep the devd configuration (to chgrp the device nodes) >>> in a port, security/u2f-devd? Can't we just add this to base, too? >>> It's just another devd configuration file. >>> >> >> This properly belongs to devfs.conf no? Otherwise it's a race... >> >> Warner >> >> -- >>> Christian "naddy" Weisgerber naddy@mips.inka.de > > It's devd.conf materials. It actually is security/usf-devd/files > u2f.conf and its contents is sets of notify 100 { match "vendor" ... > match "product" ... action "chgrpy u2f ..." };. > Some hase more items in it, though. > > So it should be in ports to adapt for latest products more quickly than > in base, I think. > I don't see any obvious reason that we can't compromise and have a baseline of products in base and just use the port for new products not yet known to base. These vendors presumably aren't going to quickly repurpose some PID for a non-u2f thing, much less in a way that we care about. Thanks, Kyle Evans From nobody Mon Jan 8 17:12: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 4T80y86TtLz567r7 for ; Mon, 8 Jan 2024 17:13:20 +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 4T80y85xdFz4k05; Mon, 8 Jan 2024 17:13:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704734000; 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=3bum2VS9rzTHM6ObNvINxQwzTrrEQ/fkajhZ0/7f98o=; b=q1btE6LZzs9Mbu2wSbv3JJjUAl5cWcdLNi1XXYYwSM6Qms1ovs2zIYuqApQQ/hpbiyN5l/ dlsmiJi/J16KhPlOqCZFDD0xBoMn13m9STcqYZQ4J3/uWDTKUhhnmyjR85DQXxgd3vS6LG ey0C3eQYF0K8JlO258b1WALvncN4c5gWTRETFNy8ZJ/EWuPKJaUKIKUatjTRIauiOhqX+S gXFabnkTMOOswrGsPTx5Iq3+5Zzfx368frKaK393XKp/p4JYnL1Z53tjktoP8BWZsgQW8H c560JnjTp8z2YdBWL6/GQ45lkacrbCsRVPGwlqiIR02o6KqInBOt8ya9eIDdAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704734000; 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=3bum2VS9rzTHM6ObNvINxQwzTrrEQ/fkajhZ0/7f98o=; b=koo0W1CVDkR6pnUK+JEt16eZFg90s4aH1+Hw3bptBLVYJ6B4ukEzDgvZmuWTSCW0UKIv0r J3cspE/AdLv1nq1h2ByEbwuz84R3rTO/xtK1w++TvLemHu9C6KY3Ae7rkK8GBXsn5SzXKi MKWzZVbYJpFS4iVfyxuE87BcTwIhue+74LIby8q+LjnzCfSFk/MfCWlu3kqdSf/7yNu+fy b+Q1GOMFsggw0Zx7jmeacQsFOVgLeJe3T3z8Hu1zB+qaNrqWQ54L6s2T5yql6xnMhlsAau by0E6PNZJOcjNjEJLfpzyEg7p+wZJPD9D0DsSHM4rlctwvEqnI8kOk+oMYlIiQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704734000; a=rsa-sha256; cv=none; b=hg4RP3E/WBUBhoG/W6CvKD6qObrdgF7J2LlTrgHJFanumrS7nnB7fdyrwbCyMwY1L2EYsF ZLwJm7Mysu+IAQndc3GyTWJGe3dvVvh1tfNH0kCtgPTeVaimMZneUv84MWCm8NVNDzAJip WMzv2S1K/QZU5siaN8Mtm4quY+uSDkFKzpm6XpV/095BnZ2ouoUGbcib/NORNiMCAxpoFK Em0RoGlfw+1GDVHKE7TTEJCCBytNXz0yw2PYqr4r1xaKAynxWXu9o3ZJZY806gDKJwHOUW mq8w/OXJWr4knashp7mKtlD9OiRLiMGQlwUrTWusG/QAXHGzWpT3GONqfbXOkQ== 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 4T80y84sCGz1DRY; Mon, 8 Jan 2024 17:13:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host81-141-223-70.range81-141.btcentralplus.com [81.141.223.70]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 90A4BBCD4; Mon, 8 Jan 2024 17:13:19 +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: Move u2f-devd into base? From: David Chisnall In-Reply-To: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> Date: Mon, 8 Jan 2024 17:12:06 +0000 Cc: Warner Losh , Christian Weisgerber , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> To: Tomoaki AOKI X-Mailer: Apple Mail (2.3774.200.91.1.1) On 8 Jan 2024, at 16:30, Tomoaki AOKI wrote: >=20 > So it should be in ports to adapt for latest products more quickly = than > in base, I think. We push out a new release of each of the -STABLE branches every 6 months = and can do ENs if a product ships and becomes popular in under six = months. This shouldn=E2=80=99t be a reason to not do things in the base = system. Streamlining the process for ENs (automating them so that there=E2=80=99s = a simple flow from review request for a commit on a stable branch to = generating the binaries and sending out the announcement) would help a = lot and would almost certainly make Colin happier about his workload. David From nobody Mon Jan 8 17:30: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 4T81Km4SD1z56BVC for ; Mon, 8 Jan 2024 17:30:20 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 4T81Km2ntHz4nhY for ; Mon, 8 Jan 2024 17:30:20 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a2ac304e526so99795966b.0 for ; Mon, 08 Jan 2024 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704735017; x=1705339817; 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=5fKGiePU5/3GlfkFA8vz+QWP6Mb9rqO/9IkmM1SMfhY=; b=fr5b4pF55uLDKYlkJTXuTnBYrIRVgdHYBhzO163FSFWJhtUboRme6PIN5oLPQXrOIp M6B0dl1f/OML9cvJmXKCVuhKI5NnraY6Vpj9TY5eYCillZ2ppJSPKsFI7nKIISqOkHU3 PaD0tQc2tjIk1yHfxDa4IPS7w1DlAVY4oTzoAsFkYWfX9zKbCr02lvHNRhHVuxU3a6J0 8j9BqsG0P9vK30+HJf/3r4R6CtNh+VWwKtFN5tJ2scZFpZG/Zx9tqjo/6oPjI9xG4VGU uSxRArzpv/q6X+fEvWZJiCY+Di0s0hFBDdm2ad/WT0ATP7bebcLCJ97w3DiWsWKN9IM0 mEQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704735017; x=1705339817; 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=5fKGiePU5/3GlfkFA8vz+QWP6Mb9rqO/9IkmM1SMfhY=; b=KlfDyi1N+t7/mchcxU0WNT8/imEHa5iD6BUzrNvkNOlRdKk4uPvoYT9SbWYI97w1j8 nkXbSDuhkmzeE+cOmYwX/BSTZPhKrbJLoxyxFJwiDsRJyecoWDrmFveV04Jg5KfDlszB Pw1WXeFqmb3b9eyW+rVK4tn+RyEOh95PxRToDUATtqknaZfszs3C5d6oXr95jaCYvlko REet0KRR1g27IMXyXzdgtflqbuEWZAktr0DyoPWNuU6TajSFFopKxihC6XVsBeZogqrS j97RjIZXMwqDFNlKr5u1WyvOEPiGwMVGMj5KbD3r7oaA1MOQE19KDllEde6BcOHlFx1z G4oQ== X-Gm-Message-State: AOJu0Ywr/raYFmvVD3QFJuNQLrhMFaQ5VPJg8mGuo9mR8bBTzYQfXXX0 IYTu9UdUUlZWK9F882e6/DPoQMx4fgczSb+/jJI1ufO5 X-Google-Smtp-Source: AGHT+IF5jFSASMbUgjx2t7tJgetZIwcjem1vDeaeVp2ypVeRWH94iZcgLI4dbkypozUjB7gFgRsOf43aBj1lZy2XP0c= X-Received: by 2002:a17:906:25d0:b0:a27:65bf:7448 with SMTP id n16-20020a17090625d000b00a2765bf7448mr1984635ejb.2.1704735016849; Mon, 08 Jan 2024 09:30:16 -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: Xin LI Date: Mon, 8 Jan 2024 09:30:05 -0800 Message-ID: Subject: Re: Move u2f-devd into base? To: Warner Losh Cc: Christian Weisgerber , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000001d9909060e728dfc" X-Rspamd-Queue-Id: 4T81Km2ntHz4nhY 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] --0000000000001d9909060e728dfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh wrote: > > > On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber > wrote: > >> We have FIDO/U2F support for SSH in base. >> >> We also have a group "u2f", 116, in the default /etc/group file. >> >> Why do we keep the devd configuration (to chgrp the device nodes) >> in a port, security/u2f-devd? Can't we just add this to base, too? >> It's just another devd configuration file. >> > > This properly belongs to devfs.conf no? Otherwise it's a race... > That's a good point. But I think in practice the race (if I'm understanding correctly, there would be a window where the device node showed up, but with the standard permissions until devd kicks in and runs "action" steps to change it) would probably not matter because the consumers (Chromium?) would be polling for the device and when opening failed, they would retry, as the security key is not guaranteed to be present when a website asks for it, and it's perfectly natural for the browser to see the security key getting attached and detached while it is running. I would say it's a good idea to have something there in place to support these security keys (possibly also cameras, etc.), especially considering the base OpenSSH now supports U2F devices. It's probably a good idea to have adduser / installer to have a defined "interactive local user" groups (u2f, video, etc. come to mind) that users are added into by default to provide a reasonable out-of-box default too. Cheers, --0000000000001d9909060e728dfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 8, 2024 at 7:19=E2=80= =AFAM Warner Losh <imp@bsdimp.com&= gt; wrote:


On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber &= lt;naddy@mips.inka.= de> wrote:

This properly belongs to devf= s.conf no? Otherwise it's a race...

= That's a good point.=C2=A0 But I think in practice the race (if I'm= understanding correctly, there would be a window where the device node sho= wed up, but with the standard permissions until devd kicks in and runs &quo= t;action" steps to change it) would probably not matter because the co= nsumers (Chromium?) would be polling for the device and when opening failed= , they would retry, as the security key is not guaranteed to be present whe= n a website asks for it,=C2=A0and it's perfectly natural for the browse= r to see the security key getting attached and detached while it is running= .

I would say it's a good idea to have something there in place = to support these security keys (possibly also cameras, etc.), especially co= nsidering the base OpenSSH now supports U2F devices.=C2=A0 It's probabl= y a good idea to have adduser / installer to have a defined "interacti= ve local user" groups (u2f, video, etc. come to mind) that users are a= dded into by default to provide a reasonable out-of-box default too.
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">
<= /div>
Cheers,
--0000000000001d9909060e728dfc-- From nobody Mon Jan 8 18:00: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 4T820W4QpVz56GhW for ; Mon, 8 Jan 2024 18:00:27 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4T820V74rjz41XW; Mon, 8 Jan 2024 18:00:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 408I0GAR018865; Tue, 9 Jan 2024 03:00:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 9 Jan 2024 03:00:15 +0900 From: Tomoaki AOKI To: Kyle Evans Cc: freebsd-current@freebsd.org Subject: Re: Move u2f-devd into base? Message-Id: <20240109030015.bb01527d642a31554647cfa0@dec.sakura.ne.jp> In-Reply-To: References: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4T820V74rjz41XW 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:7684, ipnet:153.125.128.0/18, country:JP] On Mon, 8 Jan 2024 10:35:03 -0600 Kyle Evans wrote: > On 1/8/24 10:30, Tomoaki AOKI wrote: > > On Mon, 8 Jan 2024 08:18:38 -0700 > > Warner Losh wrote: > > > >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber > >> wrote: > >> > >>> We have FIDO/U2F support for SSH in base. > >>> > >>> We also have a group "u2f", 116, in the default /etc/group file. > >>> > >>> Why do we keep the devd configuration (to chgrp the device nodes) > >>> in a port, security/u2f-devd? Can't we just add this to base, too? > >>> It's just another devd configuration file. > >>> > >> > >> This properly belongs to devfs.conf no? Otherwise it's a race... > >> > >> Warner > >> > >> -- > >>> Christian "naddy" Weisgerber naddy@mips.inka.de > > > > It's devd.conf materials. It actually is security/usf-devd/files > > u2f.conf and its contents is sets of notify 100 { match "vendor" ... > > match "product" ... action "chgrpy u2f ..." };. > > Some hase more items in it, though. > > > > So it should be in ports to adapt for latest products more quickly than > > in base, I think. > > > > I don't see any obvious reason that we can't compromise and have a > baseline of products in base and just use the port for new products not > yet known to base. These vendors presumably aren't going to quickly > repurpose some PID for a non-u2f thing, much less in a way that we care > about. > > Thanks, > > Kyle Evans Looks reasonable to me. Regards. -- Tomoaki AOKI From nobody Mon Jan 8 18:36:37 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 4T82pV3tmbz56NXQ for ; Mon, 8 Jan 2024 18:36:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4T82pT5fxwz47GZ for ; Mon, 8 Jan 2024 18:36:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-557a318123bso1612026a12.2 for ; Mon, 08 Jan 2024 10:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704739008; x=1705343808; 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=nzZIvQ3h1Ic7FTd4fFRlgVe1HVyk7fuDmKnUJjY9Y9U=; b=I/YbJ6PzIjlQmjAHuKGErsDiXkl7RCq72FP+5Q8QF9et8oTtNfF6TwwsSLnkzWJ0NS tlTaFq80UBjl5UXMSLE2aeRVjogl2VykBzeyI/NVC5ymQw2OOlcpk9pl+QHFj9R1HT4l HlQuyCxg3jivsvkuSNuyaAhlzBLxLdgruZ+P2r+FEnvKhTcMsyfFcz3kU+nTKQ6BrSGg 0RdGBHClFiUGxuYR6OIRbTQs3Ll1uo+vyhDOVW+nP+9GZ83YqhUwOBiYEf8crCUMv43y HTeNnNprufaY7KhrksJ6WE48y9TkoRfqD0kEKTIkBDS4opiM5jIrilBNlASD+y6WE7Q2 q1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739008; x=1705343808; 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=nzZIvQ3h1Ic7FTd4fFRlgVe1HVyk7fuDmKnUJjY9Y9U=; b=GK3TsyT/s8Uvw+cmjisw8RKHUD06rlGyUbD/IROV/s/jvLt+uGCnIg0VgDzZB4xpbw 1HnF9gAgzR2Vbej6MbYHjit8nViMsEY5aFLfLTK2cex1bqIwrrKZRM4WpG6P4L6NQjyx V5oGPiZn/Ok43eOMox2iM3cGZ+RVhycWVX0k2QOXHsewCLK+Fs7kuloOe5a8X29hFL37 inHJi2GHoTwscybkbJ6/mMkVYoWRtyd6LjZyEWzj8RdCFhC+gMpBbYilcowYvdz9YsEr HsydmVqpp3F+h64R9VXANV+612/kJ6qwn86cmomYwybyXJ0TDRUKlrbb9z/9ScH2xfHo +MoA== X-Gm-Message-State: AOJu0Yy/IicBCWR8il+xP94TlwKVMCfk9ERZt2NAytjpsmdW0rdFF+Pa siIYpQKqu4R+TtqFh1GufhFop7f8Wi0G3GQOQp42qM+X328mEw== X-Google-Smtp-Source: AGHT+IFFJznc/OySdSX4lokt4EQwdpw7XG/wuhgpP+n6tkAbO6xZqRJnJcw7T8tPbkJloMMK2WVup1T0MTFQFdOohqw= X-Received: by 2002:a17:906:f584:b0:a27:8833:2411 with SMTP id cm4-20020a170906f58400b00a2788332411mr978192ejd.60.1704739007742; Mon, 08 Jan 2024 10:36:47 -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: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> In-Reply-To: From: Warner Losh Date: Mon, 8 Jan 2024 11:36:37 -0700 Message-ID: Subject: Re: Move u2f-devd into base? To: Kyle Evans Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fdd7a0060e737a5d" X-Rspamd-Queue-Id: 4T82pT5fxwz47GZ 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] --000000000000fdd7a0060e737a5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyle Evans wrot= e: > On 1/8/24 10:30, Tomoaki AOKI wrote: > > On Mon, 8 Jan 2024 08:18:38 -0700 > > Warner Losh wrote: > > > >> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber > >> wrote: > >> > >>> We have FIDO/U2F support for SSH in base. > >>> > >>> We also have a group "u2f", 116, in the default /etc/group file. > >>> > >>> Why do we keep the devd configuration (to chgrp the device nodes) > >>> in a port, security/u2f-devd? Can't we just add this to base, too? > >>> It's just another devd configuration file. > >>> > >> > >> This properly belongs to devfs.conf no? Otherwise it's a race... > >> > >> Warner > >> > >> -- > >>> Christian "naddy" Weisgerber > naddy@mips.inka.de > > > > It's devd.conf materials. It actually is security/usf-devd/files > > u2f.conf and its contents is sets of notify 100 { match "vendor" ... > > match "product" ... action "chgrpy u2f ..." };. > > Some hase more items in it, though. > > > > So it should be in ports to adapt for latest products more quickly than > > in base, I think. > > > > I don't see any obvious reason that we can't compromise and have a > baseline of products in base and just use the port for new products not > yet known to base. These vendors presumably aren't going to quickly > repurpose some PID for a non-u2f thing, much less in a way that we care > about. > Yea, I just wonder why it has to be devd.conf, and not devfs.conf. What are we missing from that to make this doable generically? If we want it safe, w= e may need some additional work around the whole ugen thing it uses. Warner --000000000000fdd7a0060e737a5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 8, 2024 at 9:35=E2=80=AFA= M Kyle Evans <kevans@freebsd.org> wrote:
On= 1/8/24 10:30, Tomoaki AOKI wrote:
> On Mon, 8 Jan 2024 08:18:38 -0700
> Warner Losh <im= p@bsdimp.com> wrote:
>
>> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <naddy@mips.inka.de&= gt;
>> wrote:
>>
>>> We have FIDO/U2F support for SSH in base.
>>>
>>> We also have a group "u2f", 116, in the default /etc= /group file.
>>>
>>> Why do we keep the devd configuration (to chgrp the device nod= es)
>>> in a port, security/u2f-devd?=C2=A0 Can't we just add this= to base, too?
>>> It's just another devd configuration file.
>>>
>>
>> This properly belongs to devfs.conf no? Otherwise it's a race.= ..
>>
>> Warner
>>
>> --
>>> Christian "naddy" Weisgerber=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 naddy@mips.inka.de
>
> It's devd.conf materials. It actually is security/usf-devd/files > u2f.conf and its contents is sets of notify 100 { match "vendor&q= uot; ...
> match "product" ... action "chgrpy u2f ..." };. > Some hase more items in it, though.
>
> So it should be in ports to adapt for latest products more quickly tha= n
> in base, I think.
>

I don't see any obvious reason that we can't compromise and have a =
baseline of products in base and just use the port for new products not yet known to base.=C2=A0 These vendors presumably aren't going to quick= ly
repurpose some PID for a non-u2f thing, much less in a way that we care about.

Yea, I just wonder why it has to= be devd.conf, and not devfs.conf. What are
we missing from that = to make this doable generically? If we want it safe, we
may need = some additional work around the whole ugen thing it uses.

Warner=C2=A0
--000000000000fdd7a0060e737a5d-- From nobody Mon Jan 8 18:39:32 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 4T82ss6Ln7z56PJl for ; Mon, 8 Jan 2024 18:39:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 4T82ss4CTwz494D for ; Mon, 8 Jan 2024 18:39:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a298accc440so234317866b.1 for ; Mon, 08 Jan 2024 10:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704739183; x=1705343983; 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=ryFulrrwf6lelSA8uBVun24Ta6zslURMNaFZRAAGlVo=; b=jlxUt7SPAcW9hQAniKuWuL/2LLsEnkJxE646NE5VUqu8XdLRw1iGaXw1nDPpNXHYDJ Hv235TgLPNQUuCMmYJZsNLEcaAQ5Cm/Mb0kHqEvHT4e7ImqlgK4ddoblvWtu5A+/NNxs AGBzGmFoeUpOyTCiPCW03ar9YY9qBZVaHe9ljAzBL4M7AM3TudNiNajy3gs+VNf3TCva sN435Me0Vq4y8bz2EVkpVrguGUEpydygkc0VGpAlV5ppWev/tjyfIiz7l9kyjoNugH8n lc4tdqirMZO+5a0Zu7nUxDgZpsII73jaVjiomk1R8rBQWJ3WY0cuzcRjBWi1OuEZ6B7I WdwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739183; x=1705343983; 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=ryFulrrwf6lelSA8uBVun24Ta6zslURMNaFZRAAGlVo=; b=qNlHEPCuVtp6xZ1ZODDLOveDUGpQ9tiDp3W/Nuzd77WUC0i7YYHz4xBuPSoTAEyJy4 1sD1kXnD8IcB5owV5Hj8Gi8H6TPJG8pSZfZXvqNdRAHdn7Duw4OaFPz6rCD/swT62VCP yflENeMNH8veSc/1M3zAquUpPRMjzDJvpHXtSryEKzpi51isNPLBf3nkE5nVx2LR6t78 WSiZ9dYPaqT9vZ3/r5uXdJngsGPuxB4psVqCLyMjLhd4mftSON7CRzBvgTzH2yEcc4RZ 7eYg89bigXlOpMZ8N5LgfCn9/NV4EliHvu35p5VunDZHeJfupRdXAd+KHu6u7z35bqFw LSDQ== X-Gm-Message-State: AOJu0Yzv+X59k0bThW9aUGQ66Vf9cW0KIANz9/TFGGnihF+ngJc7q6RM pMhEray9PYYy0yJKzTBX1Shnd5szPGerPnCJBxHHVvU51UJ5Nmdc+GMAxDf1bog= X-Google-Smtp-Source: AGHT+IE3eScMW2hovE4adEARRKbiRySRQO6WJGK77lQHPz46izqplwJSLsD59//HYghkJXfG3E7Z2J4GGD27N7Nn6Ag= X-Received: by 2002:a17:907:b9cc:b0:a28:d5f4:ff48 with SMTP id xa12-20020a170907b9cc00b00a28d5f4ff48mr1851036ejc.116.1704739183647; Mon, 08 Jan 2024 10:39:43 -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: Mon, 8 Jan 2024 11:39:32 -0700 Message-ID: Subject: Re: Move u2f-devd into base? To: Xin LI Cc: Christian Weisgerber , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000079eb54060e7385d7" X-Rspamd-Queue-Id: 4T82ss4CTwz494D 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] --00000000000079eb54060e7385d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 10:30=E2=80=AFAM Xin LI wrote: > On Mon, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh wrote= : > >> On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber >> wrote: >> >>> We have FIDO/U2F support for SSH in base. >>> >>> We also have a group "u2f", 116, in the default /etc/group file. >>> >>> Why do we keep the devd configuration (to chgrp the device nodes) >>> in a port, security/u2f-devd? Can't we just add this to base, too? >>> It's just another devd configuration file. >>> >> >> This properly belongs to devfs.conf no? Otherwise it's a race... >> > > That's a good point. But I think in practice the race (if I'm > understanding correctly, there would be a window where the device node > showed up, but with the standard permissions until devd kicks in and runs > "action" steps to change it) would probably not matter because the > consumers (Chromium?) would be polling for the device and when opening > failed, they would retry, as the security key is not guaranteed to be > present when a website asks for it, and it's perfectly natural for the > browser to see the security key getting attached and detached while it is > running. > I just don't like this depending on devd not dropping the arrival bit (due to too much congestion of events) and having a resulting broken system. It's half-assed today, but it's half-assed enough that it works enough of the time the issue hasn't been pressing (which is my way of agreeing with you: its imperfect, but it works almost all the time today). Working well enough suggests we shouldn't 'gate' this change to a perfect solution.... Especially since we're a bit short handed in the usb world after Hans' tragic passing. > I would say it's a good idea to have something there in place to support > these security keys (possibly also cameras, etc.), especially considering > the base OpenSSH now supports U2F devices. It's probably a good idea to > have adduser / installer to have a defined "interactive local user" group= s > (u2f, video, etc. come to mind) that users are added into by default to > provide a reasonable out-of-box default too. > Totally agree here. Warner --00000000000079eb54060e7385d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 8, 2024 at 10:30=E2=80=AF= AM Xin LI <delphij@gmail.com>= ; wrote:
On M= on, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
On Mon, Jan 8, 2024, 7:5= 5=E2=80=AFAM Christian Weisgerber <naddy@mips.inka.de> wrote:
We have FIDO/U2F support for SSH in ba= se.

We also have a group "u2f", 116, in the default /etc/group file.<= br>
Why do we keep the devd configuration (to chgrp the device nodes)
in a port, security/u2f-devd?=C2=A0 Can't we just add this to base, too= ?
It's just another devd configuration file.
=

This properly belongs to devf= s.conf no? Otherwise it's a race...

That's a good point.= =C2=A0 But I think in practice the race (if I'm understanding correctly= , there would be a window where the device node showed up, but with the sta= ndard permissions until devd kicks in and runs "action" steps to = change it) would probably not matter because the consumers (Chromium?) woul= d be polling for the device and when opening failed, they would retry, as t= he security key is not guaranteed to be present when a website asks for it,= =C2=A0and it's perfectly natural for the browser to see the security ke= y getting attached and detached while it is running.

I just don't like this depending on devd no= t dropping the arrival bit (due to too much congestion of events) and havin= g a resulting broken system. It's half-assed today, but it's half-a= ssed enough that it works enough of the time the issue hasn't been pres= sing (which is my way of agreeing with you: its imperfect, but it works alm= ost all the time today). Working well enough suggests we shouldn't '= ;gate' this change to a perfect solution.... Especially since we're= a bit short handed in the usb world after Hans' tragic passing.
<= div>=C2=A0
I would say it's a good idea to have something there in place t= o support these security keys (possibly also cameras, etc.), especially con= sidering the base OpenSSH now supports U2F devices.=C2=A0 It's probably= a good idea to have adduser / installer to have a defined "interactiv= e local user" groups (u2f, video, etc. come to mind) that users are ad= ded into by default to provide a reasonable out-of-box default too.

Totally agree here.=C2=A0
<= div>
Warner
--00000000000079eb54060e7385d7-- From nobody Mon Jan 8 18:43:56 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 4T82yy1ZyMz56Pw4 for ; Mon, 8 Jan 2024 18:44:10 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 4T82yx6hnkz4DcG; Mon, 8 Jan 2024 18:44:09 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-50e67e37661so2529577e87.0; Mon, 08 Jan 2024 10:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704739448; x=1705344248; 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=7JG/71P2fxyQFxoZhk617xf+Y21cyWPgGzaKvylEI5s=; b=BliG63jwDf/wZngXWaUZCmka4Kju/p2tdUGZztBDwq3nkb0iCUzmnV0Nz7awIiEmEg lEGZAU9WZrKb3Eq+9/mqHl1whHEpW++QAZxpAo02zmQHghpJS5v9kjHQzC8yVYrsB9k0 QWU/Woc+qf5FBufqQ7Mmnbkc47gMpe1fyf6xcvhTJL5vIvB0i8GLkU+X2Cf3ikfnuzkI SX4FmHMVpkk0MuyE1IXmlZAouruOHBOUZaKET0eUtPUstkTCwnaLTROKn1WeHTGRBFCc 3jL3CU1kOTE6718dOhGtR90wP11ddpDccButqzWnFrB36PIAJriUAge8AYUWhwF8Q0Ma yRng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739448; x=1705344248; 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=7JG/71P2fxyQFxoZhk617xf+Y21cyWPgGzaKvylEI5s=; b=CBv2JpaVx3SQXbd1pRYv6p6e2qj3qlAEEcRzmPvQa2pucDYqBft7txVNbi5YnE7I0C HCoF8hLRmWelJ0h6G1YyetjirYPDf37fvHYukwVcLm5/XLuKY3nHpxrPyF4XTZ338Wfk 5MyqzTJ5OaG2u/pcj25ZC8G/pzSAcDoxVpKfrCgZMaNP3zEhkEuF+FMp+lposPRdEDvm UTFK2v9bepXygjdncB2OLGp5sw8DXhRQRe3tbe2Jr7RaOSp4gyo+CE8snkW9vDI3v53N 3tYzkC/xKnvwrC3DzVlQhoGLTVbt1t0DeO/lvJMwvZfDfO5M4XgPTuitzMKOhBhfetvy 8qXg== X-Gm-Message-State: AOJu0YxTxsUslpYGvClVIRGjKzBD8fgUZ0DyA0xA2qYhA9hAIx2scU98 cv3J65c6ZtOC9/CUtvF4ClQLaNHQtZU/gADmwASwHR1v X-Google-Smtp-Source: AGHT+IH89ogLxgxyQ9UmfkmVQGy/oaF7xvpSkfTrN3Pq//YyQVk3162ZrnYYdIR2a5shH65OOQ1hDJcBbmFZmHRYJLQ= X-Received: by 2002:a05:6512:3c81:b0:50e:7555:ddf4 with SMTP id h1-20020a0565123c8100b0050e7555ddf4mr2176428lfv.20.1704739447715; Mon, 08 Jan 2024 10:44:07 -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: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> In-Reply-To: From: Xin LI Date: Mon, 8 Jan 2024 10:43:56 -0800 Message-ID: Subject: Re: Move u2f-devd into base? To: Warner Losh Cc: Kyle Evans , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000373e64060e739558" X-Rspamd-Queue-Id: 4T82yx6hnkz4DcG 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] --000000000000373e64060e739558 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 10:37=E2=80=AFAM Warner Losh wrote: > > > On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyle Evans wr= ote: > >> On 1/8/24 10:30, Tomoaki AOKI wrote: >> > On Mon, 8 Jan 2024 08:18:38 -0700 >> > Warner Losh wrote: >> > >> >> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber >> >> wrote: >> >> >> >>> We have FIDO/U2F support for SSH in base. >> >>> >> >>> We also have a group "u2f", 116, in the default /etc/group file. >> >>> >> >>> Why do we keep the devd configuration (to chgrp the device nodes) >> >>> in a port, security/u2f-devd? Can't we just add this to base, too? >> >>> It's just another devd configuration file. >> >>> >> >> >> >> This properly belongs to devfs.conf no? Otherwise it's a race.. >> >> >> >> Warner >> >> >> >> -- >> >>> Christian "naddy" Weisgerber >> naddy@mips.inka.de >> > >> > It's devd.conf materials. It actually is security/usf-devd/files >> > u2f.conf and its contents is sets of notify 100 { match "vendor" ... >> > match "product" ... action "chgrpy u2f ..." };. >> > Some hase more items in it, though. >> > >> > So it should be in ports to adapt for latest products more quickly tha= n >> > in base, I think. >> > >> >> I don't see any obvious reason that we can't compromise and have a >> baseline of products in base and just use the port for new products not >> yet known to base. These vendors presumably aren't going to quickly >> repurpose some PID for a non-u2f thing, much less in a way that we care >> about. >> > > Yea, I just wonder why it has to be devd.conf, and not devfs.conf. What a= re > we missing from that to make this doable generically? If we want it safe, > we > may need some additional work around the whole ugen thing it uses. > I think it's probably because of the lack of device ID matching capability in devfs.conf (or in other words, there may be _some_ reason that I am not aware of, to not expose all USB HID devices to desktop users; devd.conf gives us the ability to selectively expose them based on what they claim themselves to be, while with devfs.conf we can only say "expose HID devices" vs "expose these allowlisted devices"). Cheers, --000000000000373e64060e739558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 8, 2024 at 10:37=E2=80= =AFAM Warner Losh <imp@bsdimp.com&= gt; wrote:


On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyl= e Evans <kevans@= freebsd.org> wrote:
On 1/8/24 10:30, Tomoaki AOKI wrote:
> On Mon, 8 Jan 2024 08:18:38 -0700
> Warner Losh <im= p@bsdimp.com> wrote:
>
>> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <naddy@mips.inka.de&= gt;
>> wrote:
>>
>>> We have FIDO/U2F support for SSH in base.
>>>
>>> We also have a group "u2f", 116, in the default /etc= /group file.
>>>
>>> Why do we keep the devd configuration (to chgrp the device nod= es)
>>> in a port, security/u2f-devd?=C2=A0 Can't we just add this= to base, too?
>>> It's just another devd configuration file.
>>>
>>
>> This properly belongs to devfs.conf no? Otherwise it's a race.= .
>>
>> Warner
>>
>> --
>>> Christian "naddy" Weisgerber=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 naddy@mips.inka.de
>
> It's devd.conf materials. It actually is security/usf-devd/files > u2f.conf and its contents is sets of notify 100 { match "vendor&q= uot; ...
> match "product" ... action "chgrpy u2f ..." };. > Some hase more items in it, though.
>
> So it should be in ports to adapt for latest products more quickly tha= n
> in base, I think.
>

I don't see any obvious reason that we can't compromise and have a =
baseline of products in base and just use the port for new products not yet known to base.=C2=A0 These vendors presumably aren't going to quick= ly
repurpose some PID for a non-u2f thing, much less in a way that we care about.

Yea, I just wonder why it has to= be devd.conf, and not devfs.conf. What are
we missing from that = to make this doable generically? If we want it safe, we
may need = some additional work around the whole ugen thing it uses.
=

I think it's probably because of the lack = of device ID matching capability in devfs.conf (or in other words, there ma= y be _some_ reason that I am not aware of, to not expose all USB HID device= s to desktop users; devd.conf gives us the ability to selectively expose th= em based on what they claim themselves to be, while with devfs.conf we can = only say "expose HID devices" vs "expose these allowlisted d= evices").

Cheers,

--000000000000373e64060e739558-- From nobody Mon Jan 8 20:29:50 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 4T85KF52Plz56hFJ for ; Mon, 8 Jan 2024 20:30:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4T85KD4rWZz4SSm for ; Mon, 8 Jan 2024 20:30:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=azX2la5x; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704745807; bh=7GEm7MqTY1Z9tWlaABr+zufp/Q3SU33pAq/k8WtL11w=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=azX2la5xd8hY2dP3M/1V/CXs3UDUK6ej+UcxvRmewicEsUZK5RXz/1gYWWz3w8vqQlAwKcla9s7Ue/Jhm44YO0jUnb3usS9x/iKTmbeFsjG9ed8TCNMW4kCdgK1XtBL6fOV2bm1878dF7HV5yOnltMJUufL5uAHNySI/Qq4fQECnvo60Gr7XHfLwf6dO5A93kbVWszT045SzAE265E68XiaqwKOYtp6w5WOstyEWk9RJicBNrgpEhCNVsu9/w+rTzy7HCs3x9jLQdCDLG28d4NiECIqX61G7pbXiDjuSuMsztAa83odEoq2UYx0Muonoz0FrtBOyGG1kPih6WyHwuw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704745807; bh=4bjz7yW3H6fRfA1+9/dwghJi7RtFlvUZeNdg4vKFyjf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hyF9zxX4pMpgm3QB8xTWguYER2LZjVNOqcaqTpgq6Qj+dO7zO0vOMnknrzXG/K3+Xhy5uk8pHBkbUKbB3uxYcoPN/s3f4XnjwdMSgIjk14JnToq0vuGfY/4iWWANdWuKd4v2Af3qxu8ZtwkMXJ0qbxyBXOR3Vl4e5HjMZUYQX/7/93i932KppLFqp0HRt8fWpK5Caj/yY6/7UH7gOuzaQ/WtpjPiuiUc7UAki4avHHcQByL9/CvKU9/xhPwclR0xvmHknBVmZWzrOe9fDVNzk8iB68wRR2ocCfQ41cLLI3yJzUsicAdCuQt9cUOpmp70eOnyR10PFg1jTPXBFgO21w== X-YMail-OSG: JRsPkZkVM1kuLki4dpzO71Y5s1_15AZ6m.e0et7J.xKvQe3beORLT06NwCq5COE 3u5vFXKc0DAtseXdPGfzD0Iofy4RbswvFGk8KMBNv.KaIdcF0Y1F5txYA_wBEbnZRnVIw2.h6ZtJ c1HrhauonV0kA2U17O3l640fpV34TQ59oEdkdivgf_dKGkuujCXEa_vrG7_c6LaU.6iz.NdO1fVQ wDyqM41u5.u7jawRw5AwSf_NhwP.pwOyj0uj9e8Z7TiHJrA6YKcGYkKyOV53yZaci9XRnuIoArJB 9rc5.6akGDufvxWErK7wdgQuZy21XBcgjgCav637ZqNv.PAoygAUi7D8tOGuxmzF7tZIIRLvTj4T LYl_5ZZ4PmUl_E.uOshtdTVc9f6TNRQahnQtjeR4Yo9PyewQnw1lQt93M18.SwFO06JsKpIef9ij 8.OYNki1CWs4hwH1f48qeAyrWhr4G2mYuyH_xsocDbiGOuSP4UEr87pQ0LWr8hsPemBvWzrXfGQx kEUJatDrg97WsW83RSNIWMmRiH4CI665ycnZ4vyrKozaNK6NR9c8iMSH26hhm0zkgRY20vqPvWnl mqDbHowYvhG.ZlkqO8uKsYqwYYXsrLhPmAQGkQKjXMvTxw23nE1Ifd34A_moiCuSu3C2bSLdw8Nl D7pasftOLV.xihgQBLXZu5XUhT6Bi0X12LFG2ZX6f2JAKSfK1myFiM6PrF6IU0IWgMHX7XdXl_MV WK_24DHhKQu0ldRDVR7uTBWeHg7pjdxabAZ4hCFeVSP9xyExV0vCkR4sgGgblCJ1zgITKeLomtbv P7GCLhaatVmJbzzhTVg1kbw4Oe0oFdAj1lHSmSIZUfCWLvTaCP2FmMAQWdWkK6uhxdABzvn52n56 2hyAJqbS4xI58GTLFdLmZhdqHG_bQZvWv5Q946rsw07jLes0epwrghFggVCNyYId0ekyN50AENlC 1at2TrJNv5NeE0q8hqy5WR4YV2oM0jrbqPp0LjfrnVZsh33zHChBIqXjIWB9wYAikGjKmNI2UtE9 XrrVDzKh8nGwio8_ASC02pLRd__XVP7EqX4YQbfJFLEgW.xJ_iTAjL6IfE8S5MwKXhkWW81Hzaa6 dN.wdk_TahcRxqea4yEqqWu329vxX1L1np5CJ4eIvGjyAbie60SuF3vBjhuJ3vk.B25mNranJVRr wI2IAtZNCa2XjVy09XTVrA176AhBXeFKY6FDZ_FkJMUeAVtTayUAzF.RdqOz7.FoTiHgal6nzCjS YDJUFEmmgr9dKLbO0CttP4Mi_Ocxpf2PQl4Hvw9Xbban.rQnwav1sabszs8qfwGOAjTWaHcSbsRI XdVtUTH4BDsRr5H3Y0MjK6AxNMfbct7clWgcOfSw0FGiEeaLlYSTjyW_f_fNXEO3TpDNAGzsT2Gc .pZ0Vyz2thvPoDHB8KOvFX1Rzvu1QT8kxUellet8vt2LF23jSiC6gmzpSQVMQzNF6yW207yPcGxW 7bj5Mb_OPLNwbF0SuDNGeLU3J31kohfm0Z.xGrwmXs3lE8Z7p.HSh3yZ.TEhGcGX17kWz.t8tlv1 vYyNYmyMuzw.GwE_TVC4uOfO5_bQMGb0zKlNY0IktsS03AyOFLXK2sE1lSeaW_XIalfOGYafst5S Zxi7u58Oj9hmqYQVGk14rbH6QyoZ0VFGhbDbzy_4CUWlMQyT5cxNpAK.jh3BTwDxbiut0fnpzsDE m0Gq8wCXDRCNWy.bGM7inFrufawezSNxhjb8yXOZjqvGGITsvc5IdR1YgWBjhnKfrPBJvKmUkuFM Wq1WU70v8kdsxMWfHOS5QAExRNLNnpTdf6nWt_vcsyinCNGeR8VBS039Dq9gz4S5YxZ679KgidCi NGgGXbxdMctCG0un8V2WCE7rw.c0Urc2nukxw6VGjyP88idC9marY6fIB.oywJepn1yaU4E2dRKu Af2LO3jcvBWGc9c2AluQPAo6xAw4BD5WOOZ89wjOK0K.QM8oM1whY4jO44FMSWplOKEJNFXZysSQ ei8IcpolVgB9n_MnDEB_sXrARO.TLeft1XblqsOJpOGwTbM8bflNYD3GD.AFIn5YQ2QkMaSi58jM fGax0Sk5KVhvWuTtpqq9X8zDtRC9hGTKLg04FVSLw6VDmPW7R_ou_aQffhpfhzrupfNLygrpQhkK C1wPIIzPwlGkKnSwVuSrSmhc11fsE5rnhX9BDFOLR_qo2rfWsxHsdErPk8ygR0OVBhvKcVlHu52y RySjw8FoLh97gdMtD4Dexf5bybZ8QuGdtiJk7xDuLUrPneFbxxEIfugmT8PHEArwsELO1a5DwjSp txg-- X-Sonic-MF: X-Sonic-ID: 5a82de4e-e249-4298-9a9c-48535cd28efd Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 8 Jan 2024 20:30:07 +0000 Received: by hermes--production-gq1-6949d6d8f9-c9pk7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 52fe207d09cd91c4562333cd412c0fbe; Mon, 08 Jan 2024 20:30:01 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Move u2f-devd into base? Message-Id: Date: Mon, 8 Jan 2024 12:29:50 -0800 To: David Chisnall , Current FreeBSD X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from] X-Rspamd-Queue-Id: 4T85KD4rWZz4SSm David Chisnall wrote on Date: Mon, 08 Jan 2024 17:12:06 UTC : > On 8 Jan 2024, at 16:30, Tomoaki AOKI = wrote: > >=20 > > So it should be in ports to adapt for latest products more quickly = than > > in base, I think. >=20 > We push out a new release of each of the -STABLE branches every 6 = months https://www.freebsd.org/releases/ reports (mixing "Most Recent" and "Prior Releases - EOL" lines for 13.x): =E2=80=A2 Release 13.2 (April 11, 2023) Announcement : Release Notes = : Installation Instructions : Hardware Compatibility List : Readme : = Errata : Signed Checksums . . . =E2=80=A2 13.1 (May 16, 2022) Announcement : Release Notes : = Installation Instructions : Hardware Compatibility List : Readme : = Errata : Signed Checksums =E2=80=A2 13.0 (April 13, 2021) Announcement : Release Notes : = Installation Instructions : Hardware Compatibility List : Readme : = Errata : Signed Checksums and for the end of the 12.x releases: =E2=80=A2 12.4 (December 5, 2022) Announcement : Release Notes : = Installation Instructions : Hardware Compatibility List : Readme : = Errata : Signed Checksums =E2=80=A2 12.3 (December 7, 2021) Announcement : Release Notes : = Installation Instructions : Hardware Compatibility List : Readme : = Errata : Signed Checksums Looks more like around a year for each separate stable/?? to me. > and can do ENs if a product ships and becomes popular in under six = months. This shouldn=E2=80=99t be a reason to not do things in the base = system. >=20 > Streamlining the process for ENs (automating them so that there=E2=80=99= s a simple flow from review request for a commit on a stable branch to = generating the binaries and sending out the announcement) would help a = lot and would almost certainly make Colin happier about his workload. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 8 20:41: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 4T85Z71z97z56k9G for ; Mon, 8 Jan 2024 20:41:19 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 4T85Z55d0Xz4Xxq for ; Mon, 8 Jan 2024 20:41:17 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=lBUJLad6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=delphij@gmail.com Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a2adc52f213so115520466b.0 for ; Mon, 08 Jan 2024 12:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704746474; x=1705351274; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=OC/rHOeYXHE2yfnMGAaBpFRMcpOUMApuC16av+6IXxQ=; b=lBUJLad6no9p8zHmR1LIqKizIEm2Sa1zSyiR1M4iOS20HryVmFXBnj3PKyWlUfEIOE FrA7KlZwru+5hWqqtP6wJziNv6sznTgzEO2o7nNPSaKE6gFV6Y70pMGAdVSHnlVkmwfR NOlO12+cuPbwwXnK9vI2neW4/Y/LnUWBP2XrRS8wKhoyPsAdVSdEDyw4cgvm+RcknQOE q7tbnjW9H3tXoCu5JUilymLBCzYKuWja6b8uvXcimETahZvJPiIKcSGhJ8q9m5l94sSW lkvLUZ6ULtRUJKDYXLlv2ThisFX0ALSF9LryJqPJsp3PPFjvB8mmM+qhBLaPkrMBhwwG 13IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704746474; x=1705351274; h=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=OC/rHOeYXHE2yfnMGAaBpFRMcpOUMApuC16av+6IXxQ=; b=ipxViH2CWwJZleEdd1QKVzEKpihwArqjfXhEUUZLxgYFoO1K9sPDVwgc5c81Ge2d5H pR1VIhGcF8jp1atcgAHOEYyF2DhfZ+Phh9l0opwFPfT8p9gFp2AHxqDXU1CO1L7ikfeY zPcuoNz4Nm15Fd5TzTOFMVCObqVl2xxxCl5wZc0aQYHjxdY5YfqRMPuk+rHm4qWmEUx7 jTh3E09N56mJ5DXD6/QHKw5eRpVON1OBH3GyPqc4eZBwkXQ4Hbzy9KBRksH8zme1t/Gv kRrAEEp7/sxGLlla8eOZt42wfBi1y2c021pmAxhVIDhcgk3G4XryVwOw4fq7iq64+3VJ R8Ew== X-Gm-Message-State: AOJu0YxypzFC1AaPgserbraEhgLYZXoPxsY/pfq0OQcxltK08+GnB1BJ N2LZ+Xtrm4w11vZuI9NXUv74Nf/wRwoZqcFSi6rE8LH1fSA= X-Google-Smtp-Source: AGHT+IGG8OorzKf+ib0NNl8GSwr1VNcHK0P+ztmGlLhxNOk3w/O2hh9qrll6vBlW7+RTythUmJIYAlYtwTuPs3g3uhQ= X-Received: by 2002:a17:906:1458:b0:a28:cf0a:c29e with SMTP id q24-20020a170906145800b00a28cf0ac29emr6440ejc.114.1704746473946; Mon, 08 Jan 2024 12:41:13 -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: Xin LI Date: Mon, 8 Jan 2024 12:41:02 -0800 Message-ID: Subject: Re: noatime on ufs2 To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000003004c060e753845" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.899]; 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]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEFALL_USER(0.00)[delphij]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T85Z55d0Xz4Xxq --00000000000003004c060e753845 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void wrote: > Hi, > > Does /var/mail still need atime? > > I've installed a ufs2-based -current main-n267425-aa1223ac3afc on > rpi4/8BG which installs into one / . If it's mounted with noatime, > will it have consequences for /var/mail ? It doesn't matter if you don't normally receive emails locally (nowadays, it's rare). If you do receive emails locally, it depends on what application(s) that you are using. Most applications nowadays check both mtime and atime plus sizes of the mailbox file and do not rely on atime (because they saved the previous mtime). Without atime updates, some application may claim that you have new mail when the mailbox is not empty when they first start. That's said, if I were you and I'm using some flash based storage (with rpi it's highly likely) regardless if I'm using mail locally; most of the time the data is not really useful for anything, and it does increase the wear of your storage. This reminds me that -- we probably should have implemented the Linux "relative atime" (update atime iff (atime <=3D mtime || atime <=3D ctime) |= | atime is older than a day) and "no diratime" (don't update directory atime) for UFS and make the "relatime" option the default; I had an incomplete implementation about a decade ago somewhere but with the recent VFS changes it's probably easier to start over. IMHO, updating atime every time when a file is accessed is not really providing useful data (like who accessed the file, etc.) for audit purposes and does come with performance (more write I/O) and reliability (wear of SSD and other flash devices) cost, therefore not generally useful in modern days. The Linux relative atime is a pretty clever idea that has covered the most useful use case for atime (Did I accessed the file after it was last modified) and also provided a coarse-grained update (capped to daily, which is a reasonable compromise) to the atime. Cheers, --00000000000003004c060e753845 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 7, 2024 at 5:27=E2=80= =AFAM void <void@f-m.fm= > wrote:
= Hi,

Does /var/mail still need atime?

I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
rpi4/8BG which installs into one / . If it's mounted with noatime,
will it have consequences for /var/mail ?

It doesn&#= 39;t matter if you don't normally receive emails locally (nowadays, it&= #39;s rare).

If you do receive emails locally, it depends on what ap= plication(s) that you are using.=C2=A0 Most applications nowadays check bot= h mtime and atime plus sizes of the mailbox file and do not rely on atime (= because they saved the previous mtime).=C2=A0 Without atime updates, some a= pplication may claim that you have new mail when the mailbox is not empty w= hen they first start.

That's said, if I were you and I'm usi= ng some flash based storage (with rpi it's highly likely) regardless if= I'm using mail locally; most of the time the data is not really useful= for anything, and it does increase the wear of your storage.

This r= eminds me that -- we probably should have implemented the Linux "relat= ive atime" (update atime iff (atime <=3D mtime || atime <=3D cti= me) || atime is older than a day) and "no diratime" (don't up= date directory atime) for UFS and make the "relatime" option the = default; I had an incomplete=C2=A0implementation about a decade ago somewhe= re but with the recent VFS changes it's probably easier to start over.= =C2=A0 IMHO, updating atime=C2=A0every time when a file is accessed is not = really providing useful data (like who accessed the file, etc.) for audit p= urposes and does come with performance (more write I/O) and reliability (we= ar of SSD and other flash devices) cost, therefore not generally useful in = modern days.=C2=A0 The Linux relative atime is a pretty clever idea that ha= s covered the most useful use case for atime (Did I accessed the file after= it was last modified) and also provided a coarse-grained update (capped to= daily, which is a reasonable compromise) to the atime.

Cheers,
--00000000000003004c060e753845-- From nobody Mon Jan 8 21:07:30 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 4T868Q3XZZz56nm5 for ; Mon, 8 Jan 2024 21:07:34 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 4T868P560dz4dxD for ; Mon, 8 Jan 2024 21:07:33 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=VeuaLJG7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::42f as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-6d9bee259c5so1179562b3a.1 for ; Mon, 08 Jan 2024 13:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704748052; x=1705352852; darn=freebsd.org; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xSATHoNBMexxbSbzaRDrKWd2i18yXCd2CYF+GK9ZEGA=; b=VeuaLJG7hsUga8ho79LU8QTaB4Px/m7uuW+MQzQ/btOzFOpTG66+iKtumvUt6ICMdz 3XK+YIkkJzVJTGj900YH7GTvOmVyHH9sDrkOuMZG+IqnD/8/qBc3r3Kqc0j+BgRAP9jZ BsLaUvG/nNgJTnR/1arcrbjgqXzuI6tgxFIj49GffkrVSVkOYxAo04zl5NKd7vXQvJtO I/qtXPBs33znyPEuxPtvmMHGkYQEmW0MCRa7EOVcORgviUeqgDFjMxFhiFXXRY2HMXOX 4BxECgOuyPrj2JlkNQ4jvVGpDE7SSCYmSwq/2vCYs4f/9NYPJKuCnSvMpm7RRgGglHSV ZARA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704748052; x=1705352852; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xSATHoNBMexxbSbzaRDrKWd2i18yXCd2CYF+GK9ZEGA=; b=LISF2EXDXhjJvJXvBE116ZGH0NuMkBWqS0N3hsqKPeI6LMNNwgec8PwFDjWlhtBY9p MDsTTKfyml3IznX0txFH2m4/mdayHUv5yDU1Ubfsld3aRh67uO9DmhNPYNvzkoJpKOE7 bYj2mqipXYZJnwhcuND/vQgXd6tI1vUWeTq3QNLyzgXL+uCEuE8VE1FAwpx1q9G/LLTw Jqy3QsWTd++r+F2rGSLQI9g1EM9RhzkmH9rSdAwhJk/RtpasxX2SHV4bN6IeNZ1rPYzI U/vGY8FNRQX9XDLbI8o6HnxXNKGNqDiTcUQjYSFYKROZgolzns8bDtkKp6MyKXk6h+bF UY1Q== X-Gm-Message-State: AOJu0YwckwIS8KSayC0k17g6KVWxzMXR8NSSRmDz+Jkp9idYSWNRe+27 WHJ5rcE5sYnyUmXOfrmY5GuIgxaMAPThQQ== X-Google-Smtp-Source: AGHT+IEzqNVeMxXH4/J0Sin/IEJoHIWnLnNLFY823pIrcx1Caj0yktWq09zhdTtQooEBvI49QbhnnA== X-Received: by 2002:a05:6a00:1caa:b0:6d9:b266:16c3 with SMTP id y42-20020a056a001caa00b006d9b26616c3mr1992156pfw.4.1704748052199; Mon, 08 Jan 2024 13:07:32 -0800 (PST) Received: from smtpclient.apple ([2601:601:782:be00:9c2b:b3b7:ec79:86b6]) by smtp.gmail.com with ESMTPSA id k12-20020aa790cc000000b006d8610fcb63sm303510pfk.87.2024.01.08.13.07.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2024 13:07:31 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E1A35192-08D8-4C26-BDF1-121D2C25D90D"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 \(3696.120.41.1.4\)) Subject: Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64 From: Enji Cooper In-Reply-To: Date: Mon, 8 Jan 2024 13:07:30 -0800 Cc: freebsd-current@freebsd.org Message-Id: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com> References: To: void X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.60 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; HAS_ATTACHMENT(0.00)[]; TO_MATCH_ENVRCPT_SOME(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]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42f:from] X-Rspamd-Queue-Id: 4T868P560dz4dxD --Apple-Mail=_E1A35192-08D8-4C26-BDF1-121D2C25D90D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 7, 2024, at 6:29 AM, void wrote: >=20 > Hi, >=20 > on a rpi4/8GB, my rc.conf looks like so. It's an ipv4-only system on a = LAN not directly connected to the internet >=20 > hostname=3D"generic.home.arpa" > ifconfig_genet0=3D"inet 192.168.1.199 netmask 255.255.255.0" > defaultrouter=3D"192.168.1.1" > sshd_enable=3D"YES" > sendmail_enable=3D"NONE" > sendmail_submit_enable=3D"NO" > sendmail_outbound_enable=3D"NO" > sendmail_msp_queue_enable=3D"NO" > growfs_enable=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > ntpd_enable=3D"YES" > ntpdate_enable=3D"YES" >=20 > when it boots, the following appears in the serial console >=20 > ### >=20 > Starting devd. > Autoloading module: uhid > Autoloading module: usbhid > Autoloading module: wmt > route: message indicates error: File exists > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add net default: gateway 192.168.1.1 > route: bad keyword: inet6 > route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args] > route: bad keyword: inet6 > route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args] > route: bad keyword: inet6 > route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args] > route: bad keyword: inet6 > route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args] > route: bad keyword: inet6 > route: usage: route [-j jail] [-46dnqtv] command [[modifiers] args] > Updating motd:. > Creating and/or trimming log files. Was the kernel/utility built with IPv6? If not, that=E2=80=99s a general = bug which should be filed (which can be easily checked/avoided using the = FEATURES(9) subsystem)=E2=80=A6 Cheers! -Enji --Apple-Mail=_E1A35192-08D8-4C26-BDF1-121D2C25D90D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmWcZBIACgkQ5JFNMZeD GN6RrA/8CaoWUPnTCVw+g0lXN9dXGTqa6kjCkbZr61ond0auXidRUa/c4OR0Gyve zkp8CY0fOVH8YZ3GO80wXlOkfGYgVaKzBVSCTgvRxpTsVPgQYIUDJioh3DuQ5x4p 25EvDMqtm01GPaVFE6Pf0NznppLunT3LSMRb+eg9iR3BU2J7INsu2tCc7++8yjH2 CFJJjd0YzttluNC7R0Hcjahr+fjUEIy9HycWCUGiqUOpzr/wizXA3A9LSvvmArF9 AXJ4zxv9av7MNOO6J/RpgR+44hG49gUNqwM1xD3kaevj1of34XXDFbkkNcvqeb2S GB48uxhphP+RtyeEfKWIgEYwlrRuDWAzUWE/NLjVMQeGS0Ad+r6pNq6iq4z8G9Ub 0MY1Aa5PU8rdFCAv2iKBkW9I4yqKK3HTX84HvVEspcZD+8JU4ItgeOWU4/cMymU4 B/fjCOose3jjQki5nvjar2TPtVBSkYWgveUhzJj8atJTF19cce7Vd10WAw08AywR 9ZVInJ05/gBEbllV9D3MvhK2Qq/l9T320n90hw1at0Ib/biQUS3ShspgPul9uAo2 9zEltvSEksMcosmpdFGkYylHvWLRjiwDcBJFeUgavE0IdDeiMAHt+9p4qxviDNYs xq5hgME5DmS/WMwwWPl+IMRelWdUnaOMJ4JPRD5oLYAeHtxq/64= =sU2l -----END PGP SIGNATURE----- --Apple-Mail=_E1A35192-08D8-4C26-BDF1-121D2C25D90D-- From nobody Mon Jan 8 21:12: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 4T86Fv5Nkkz56pNw for ; Mon, 8 Jan 2024 21:12:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4T86Fv0QG9z4gmD for ; Mon, 8 Jan 2024 21:12:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a2a17f3217aso225307766b.2 for ; Mon, 08 Jan 2024 13:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704748338; x=1705353138; 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=6t46BCg077sBnDUQhm+f0+m/gnV2sEfKxqJhthHEOkM=; b=DMxhkTFKVyGZO7za5Thjk09YccgVr4NbrVNffxf/PQRUxDqUd3rptvViuvoQBrviYT wPWChK1Ft8cQlpxLqX4UQQtEIDqLa+1tx1WOdxSh5WKYLdXLkQRheBKh8ccdgw1KBtTh IEyLPYRB8WaDiEgr34w6CjWkFYY8SIeknEqki5WXYJF/OLOHG/Ow/HJSVtZeJsWXPBps 9XzJt4Ie/sFb9gsGVFgi/0NKhfyUFYgro6au4SIE96GpOWPm9RZV67uZijHgowKH9E/O KuHgIiC5IuCfPx1EW+6KD64pPhV2/YAPbCO8TSOLcLNYwRTMgHLF2k+QYD9pQQS/T0sR qSRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704748338; x=1705353138; 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=6t46BCg077sBnDUQhm+f0+m/gnV2sEfKxqJhthHEOkM=; b=FNIjSHrFnxnTXEtiqITQlAUuRAgK0//XzfArC9I6/fbE9HcvM9aNNtch2po9Fs0N51 zrQaToWQW4Anme/l8JsXemAFnNydhGbT1DsFbSM9rH1GJkn9LJ/jOTUUNAqZkO6pDH/r 9KGjuV68ivbmvjnIJRpmRpBjeticH6yvGTVs2Glf7kFPqpQIamnmqaa9/yGg/f3sxxuv 1z90zqmMYpU24CpE0tW67KS2ukPwedbFHjzRG2lrNphTCn05OWmBDjhACaZQ/6MSmQMc Ba7Rr0bcbaYUXr6Nng+0X9fHJ/UxK6Z0nxJe9t/vatUkUAJFgJfzZt1isaQPYMC1V1dk FD3A== X-Gm-Message-State: AOJu0Yz47oUDiQ31pdrZQserFufyxCTvyUm1RQzEYWY91bWnzx1U6b0q sglAsPmswtFLdUPXPm7uUrf5bK8+rvqCdqyLI1DzWV2LUPBibStoJznkYKzEALw= X-Google-Smtp-Source: AGHT+IE1+wVtdtT9aMIOhwAUcNBPUuNUJsGvBKBZbm//ZBCGBYN6i7Hkcv7FK2RvNuGF/juJMdJcazHA94ultegp7sI= X-Received: by 2002:a17:907:7f8e:b0:a23:46f2:d8e4 with SMTP id qk14-20020a1709077f8e00b00a2346f2d8e4mr25654ejc.51.1704748337619; Mon, 08 Jan 2024 13:12:17 -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: Mon, 8 Jan 2024 14:12:06 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Xin LI Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001888a4060e75a716" X-Rspamd-Queue-Id: 4T86Fv0QG9z4gmD 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] --0000000000001888a4060e75a716 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 1:41=E2=80=AFPM Xin LI wrote: > > > On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void wrote: > >> Hi, >> >> Does /var/mail still need atime? >> >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >> rpi4/8BG which installs into one / . If it's mounted with noatime, >> will it have consequences for /var/mail ? > > > It doesn't matter if you don't normally receive emails locally (nowadays, > it's rare). > > If you do receive emails locally, it depends on what application(s) that > you are using. Most applications nowadays check both mtime and atime plu= s > sizes of the mailbox file and do not rely on atime (because they saved th= e > previous mtime). Without atime updates, some application may claim that > you have new mail when the mailbox is not empty when they first start. > > That's said, if I were you and I'm using some flash based storage (with > rpi it's highly likely) regardless if I'm using mail locally; most of the > time the data is not really useful for anything, and it does increase the > wear of your storage. > > This reminds me that -- we probably should have implemented the Linux > "relative atime" (update atime iff (atime <=3D mtime || atime <=3D ctime)= || > atime is older than a day) and "no diratime" (don't update directory atim= e) > for UFS and make the "relatime" option the default; I had an > incomplete implementation about a decade ago somewhere but with the recen= t > VFS changes it's probably easier to start over. IMHO, updating atime eve= ry > time when a file is accessed is not really providing useful data (like wh= o > accessed the file, etc.) for audit purposes and does come with performanc= e > (more write I/O) and reliability (wear of SSD and other flash devices) > cost, therefore not generally useful in modern days. The Linux relative > atime is a pretty clever idea that has covered the most useful use case f= or > atime (Did I accessed the file after it was last modified) and also > provided a coarse-grained update (capped to daily, which is a reasonable > compromise) to the atime. > I like that compromise. It will miss a lot, but that 'miss' results in atime being good to only about a day, which for the vast majority of things is fine. Warner > Cheers, > --0000000000001888a4060e75a716 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 8, 2024 at 1:41=E2=80=AFP= M Xin LI <delphij@gmail.com>= wrote:

On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void <void@f-m.fm> wrote:
Hi,

Does /var/mail still need atime?

I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
rpi4/8BG which installs into one / . If it's mounted with noatime,
will it have consequences for /var/mail ?

It doesn't matter if you don&#= 39;t normally receive emails locally (nowadays, it's rare).

If you do receive emails locally, it depends on what= application(s) that you are using.=C2=A0 Most applications nowadays check = both mtime and atime plus sizes of the mailbox file and do not rely on atim= e (because they saved the previous mtime).=C2=A0 Without atime updates, som= e application may claim that you have new mail when the mailbox is not empt= y when they first start.

That's said,= if I were you and I'm using some flash based storage (with rpi it'= s highly likely) regardless if I'm using mail locally; most of the time= the data is not really useful for anything, and it does increase the wear = of your storage.

This reminds me that -- = we probably should have implemented the Linux "relative atime" (u= pdate atime iff (atime <=3D mtime || atime <=3D ctime) || atime is ol= der than a day) and "no diratime" (don't update directory ati= me) for UFS and make the "relatime" option the default; I had an = incomplete=C2=A0implementation about a decade ago somewhere but with the re= cent VFS changes it's probably easier to start over.=C2=A0 IMHO, updati= ng atime=C2=A0every time when a file is accessed is not really providing us= eful data (like who accessed the file, etc.) for audit purposes and does co= me with performance (more write I/O) and reliability (wear of SSD and other= flash devices) cost, therefore not generally useful in modern days.=C2=A0 = The Linux relative atime is a pretty clever idea that has covered the most = useful use case for atime (Did I accessed the file after it was last modifi= ed) and also provided a coarse-grained update (capped to daily, which is a = reasonable compromise) to the atime.
I like that compromise. It will miss a lot, but that 'miss&= #39; results in atime being good to only about a day, which for the vast ma= jority of things is fine.=C2=A0

Warner
= =C2=A0
Cheers,
--0000000000001888a4060e75a716-- From nobody Mon Jan 8 22:21:29 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 4T87nv3KJyz5711j for ; Mon, 8 Jan 2024 22:21:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4T87nt5btXz4s3H for ; Mon, 8 Jan 2024 22:21:37 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 408MLT7h066137; Tue, 9 Jan 2024 07:21:30 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 9 Jan 2024 07:21:29 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Xin LI , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-Id: <20240109072129.3e6411b51a2f32945f41decd@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4T87nt5btXz4s3H 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:7684, ipnet:153.125.128.0/18, country:JP] On Mon, 8 Jan 2024 14:12:06 -0700 Warner Losh wrote: > On Mon, Jan 8, 2024 at 1:41 PM Xin LI wrote: > > > > > > > On Sun, Jan 7, 2024 at 5:27 AM void wrote: > > > >> Hi, > >> > >> Does /var/mail still need atime? > >> > >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on > >> rpi4/8BG which installs into one / . If it's mounted with noatime, > >> will it have consequences for /var/mail ? > > > > > > It doesn't matter if you don't normally receive emails locally (nowadays, > > it's rare). > > > > If you do receive emails locally, it depends on what application(s) that > > you are using. Most applications nowadays check both mtime and atime plus > > sizes of the mailbox file and do not rely on atime (because they saved the > > previous mtime). Without atime updates, some application may claim that > > you have new mail when the mailbox is not empty when they first start. > > > > That's said, if I were you and I'm using some flash based storage (with > > rpi it's highly likely) regardless if I'm using mail locally; most of the > > time the data is not really useful for anything, and it does increase the > > wear of your storage. > > > > This reminds me that -- we probably should have implemented the Linux > > "relative atime" (update atime iff (atime <= mtime || atime <= ctime) || > > atime is older than a day) and "no diratime" (don't update directory atime) > > for UFS and make the "relatime" option the default; I had an > > incomplete implementation about a decade ago somewhere but with the recent > > VFS changes it's probably easier to start over. IMHO, updating atime every > > time when a file is accessed is not really providing useful data (like who > > accessed the file, etc.) for audit purposes and does come with performance > > (more write I/O) and reliability (wear of SSD and other flash devices) > > cost, therefore not generally useful in modern days. The Linux relative > > atime is a pretty clever idea that has covered the most useful use case for > > atime (Did I accessed the file after it was last modified) and also > > provided a coarse-grained update (capped to daily, which is a reasonable > > compromise) to the atime. > > > > I like that compromise. It will miss a lot, but that 'miss' results in > atime being good to only about a day, which for the vast majority of things > is fine. > > Warner > > > > Cheers, Looks great if possible. Maybe /usr/bin/mail would be almost all of the MUA which actually require atime and local mailboxes (under /var/mail) would usually be used for local cron-generated ones. Others would use POP or IMAP running on different computer in most cases, I think. Regards. -- Tomoaki AOKI From nobody Tue Jan 9 02:39: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 4T8FZW09N3z55lD1 for ; Tue, 9 Jan 2024 02:42:11 +0000 (UTC) (envelope-from robert@rrbrussell.com) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 4T8FZV271vz4Xk4 for ; Tue, 9 Jan 2024 02:42:10 +0000 (UTC) (envelope-from robert@rrbrussell.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rrbrussell.com header.s=fm2 header.b=VMTh6LNT; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=aeZxZsec; dmarc=pass (policy=quarantine) header.from=rrbrussell.com; spf=pass (mx1.freebsd.org: domain of robert@rrbrussell.com designates 64.147.123.25 as permitted sender) smtp.mailfrom=robert@rrbrussell.com Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C791B3200A33 for ; Mon, 8 Jan 2024 21:42:08 -0500 (EST) Received: from imap52 ([10.202.2.102]) by compute1.internal (MEProxy); Mon, 08 Jan 2024 21:42:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rrbrussell.com; h=cc: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=fm2; t=1704768128; x=1704854528; bh=V4iumuCCJU T8r2tcRQki0yDYC/8B7SmTrSexSlgucGA=; b=VMTh6LNTGvlYGwBOVjxUFcYn2A vog7dyqW5m1rKxi1h4MqySWh3Aj1a0klli3wo6MHn6y71F/YdskDmg7rjfO3zHZ4 wy9rVboA1OsBGHa51AQuyU8GwZOqH8Cio1UFeuj6v4wRJYu/OmgccqhNd3UhgfOc INZDEVNXMQXYYGclAGi/njg0g3YoTw60VRSbneQoItN7Re7ClRsgHHYEI6Gk5nvb S0vCkeE5YK04bYpEWT4+Sv3+MJS15r2ptdnZcUuziFPvAzVsYv3FxHtW2XwvXSXe F1HEfldJFOa02EmEOYaTNAhRZf0IrMCoAY+EZyhkA0j0Qm95Kmz39viyP+tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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= fm2; t=1704768128; x=1704854528; bh=V4iumuCCJUT8r2tcRQki0yDYC/8B 7SmTrSexSlgucGA=; b=aeZxZsecJudmrkoqkwFTPpXS8OyWTXcMKlPLv9Kb6+GW 9lCWReBh3tjmDZjhhFGiMrd6fBURQ2/qgRTiSeBKoP4N0m9MpAoAWEBMKBcm/ERm NRNs8E97U7vGCe/uzwGWHH94tpylHPADUt+Mmc8G0kOWj2OKUwbCtOHVS97ptYpK 5cGn2m4wEMUahdNkGiarACku5ZSJoTwcebgzKOUduoOTE3qsdRM2RZldSD+/+jYA wiY/OSpkZIhftWYnJvuNbtyLbLYiz60wmimBadcz/zsOcrcYhYdx62AMeAJTqqA9 EcplheNlObqWirqZBzz4SmhXFQO1xBuR/EDI750MjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehkedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhmnecu ggftrfgrthhtvghrnheptddvhedvkeejieefveffgedukedtleehffevgfekvdehkeetie dtgeelkeeftdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomh X-ME-Proxy: Feedback-ID: ie421460a:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E786BC63EC9; Mon, 8 Jan 2024 21:42:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 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: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> In-Reply-To: References: Date: Mon, 08 Jan 2024 20:39:06 -0600 From: robert@rrbrussell.com To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Content-Type: multipart/alternative; boundary=54b92331b9ec41dc9f02046dfeeac9b9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.09 / 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)[rrbrussell.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; R_DKIM_ALLOW(-0.20)[rrbrussell.com:s=fm2,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; XM_UA_NO_VERSION(0.01)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[robert]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[rrbrussell.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4T8FZV271vz4Xk4 --54b92331b9ec41dc9f02046dfeeac9b9 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024, at 14:41, Xin LI wrote: >=20 >=20 > On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void wrote: >> Hi, >>=20 >> Does /var/mail still need atime? >>=20 >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >> rpi4/8BG which installs into one / . If it's mounted with noatime, >> will it have consequences for /var/mail ? >=20 > It doesn't matter if you don't normally receive emails locally (nowada= ys, it's rare). >=20 > If you do receive emails locally, it depends on what application(s) th= at you are using. Most applications nowadays check both mtime and atime= plus sizes of the mailbox file and do not rely on atime (because they s= aved the previous mtime). Without atime updates, some application may c= laim that you have new mail when the mailbox is not empty when they firs= t start. >=20 > That's said, if I were you and I'm using some flash based storage (wit= h rpi it's highly likely) regardless if I'm using mail locally; most of = the time the data is not really useful for anything, and it does increas= e the wear of your storage. >=20 > This reminds me that -- we probably should have implemented the Linux = "relative atime" (update atime iff (atime <=3D mtime || atime <=3D ctime= ) || atime is older than a day) and "no diratime" (don't update director= y atime) for UFS and make the "relatime" option the default; I had an in= complete implementation about a decade ago somewhere but with the recent= VFS changes it's probably easier to start over. IMHO, updating atime e= very time when a file is accessed is not really providing useful data (l= ike who accessed the file, etc.) for audit purposes and does come with p= erformance (more write I/O) and reliability (wear of SSD and other flash= devices) cost, therefore not generally useful in modern days. The Linu= x relative atime is a pretty clever idea that has covered the most usefu= l use case for atime (Did I accessed the file after it was last modified= ) and also provided a coarse-grained update (capped to daily, which is a= reasonable compromise) to the atime. >=20 > Cheers, On the Linux side of things I think almost of the mail handling programs= have migrated to either using MailDir or MH style mailboxes, which don'= t need atime, for anything local. The MDA/MTA configuration examples hav= e all used MailDir for around a decade now. Why not make noatime the default across the whole system? Outside of mbo= x why is recording access time actually useful? --54b92331b9ec41dc9f02046dfeeac9b9 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 8, = 2024, at 14:41, Xin LI wrote:


On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void <void@f-m.fm> wrote:
<= blockquote class=3D"qt-gmail_quote" style=3D"margin-top:0px;margin-right= :0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-le= ft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><= div>Hi,

Does /var/mail still need atime?<= br>

I've installed a ufs2-based -current main= -n267425-aa1223ac3afc on
rpi4/8BG which installs into one= / . If it's mounted with noatime,
will it have consequen= ces for /var/mail ?

It doesn't = matter if you don't normally receive emails locally (nowadays, it's rare= ).

If you do receive emails locally, it depen= ds on what application(s) that you are using.  Most applications no= wadays check both mtime and atime plus sizes of the mailbox file and do = not rely on atime (because they saved the previous mtime).  Without= atime updates, some application may claim that you have new mail when t= he mailbox is not empty when they first start.


This reminds me t= hat -- we probably should have implemented the Linux "relative atime" (u= pdate atime iff (atime <=3D mtime || atime <=3D ctime) || atime is= older than a day) and "no diratime" (don't update directory atime) for = UFS and make the "relatime" option the default; I had an incomplete = ;implementation about a decade ago somewhere but with the recent VFS cha= nges it's probably easier to start over.  IMHO, updating atime = ;every time when a file is accessed is not really providing useful data = (like who accessed the file, etc.) for audit purposes and does come with= performance (more write I/O) and reliability (wear of SSD and other fla= sh devices) cost, therefore not generally useful in modern days.  T= he Linux relative atime is a pretty clever idea that has covered the mos= t useful use case for atime (Did I accessed the file after it was last m= odified) and also provided a coarse-grained update (capped to daily, whi= ch is a reasonable compromise) to the atime.

= Cheers,

On the Linux side of things I think a= lmost of the mail handling programs have migrated to either using MailDi= r or MH style mailboxes, which don't need atime, for anything local. The= MDA/MTA configuration examples have all used MailDir for around a decad= e now.

Why not make noatime the defau= lt across the whole system? Outside of mbox why is recording access time= actually useful?

--54b92331b9ec41dc9f02046dfeeac9b9-- From nobody Tue Jan 9 08:47:59 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 4T8Phm5Zcqz56m6Y for ; Tue, 9 Jan 2024 08:48:08 +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 4T8Phm561jz4GBy for ; Tue, 9 Jan 2024 08:48:08 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704790088; 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=8u5c3kDd6q0YjKy4QQhskPARocNSG0j3A9qUxv3Egu0=; b=OAaSrmrAhlhy1O9lSzSWArgPii+OarYVSsKZ5g8Apa2dGoMAJ5QrX2qwy5GA4pLB943nKK OjNKYZt2yTB9efWyFm+/Wd4zcsukTBaq5uF5kuIfAm+NcHQBxLVFlNWuObfVW4sHxunfcx WUuI2J5XMtUFaOzx3BBau/46yPkkfM1CnGK1vpu5Pf9XVrgq2LbBFrnuGcZJabXjyrn4mF yhi6eu2/IUYz/ts9idOEMCkVoY+qqK0D1Z5Y40gZaTH4tMylbfmhCGYWkBvnTPPqGRVKK5 mXNOkdaVoCf4+Bvt/Wys7QfjanGGZlIQqr5g9w+dLB1qMSUQXp4OCeLMFGfY5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704790088; 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=8u5c3kDd6q0YjKy4QQhskPARocNSG0j3A9qUxv3Egu0=; b=dC6c3WltYehIPVm/A4g9U0gGje494p/BMvTGKcx3g71E+y5KY+tIGLLFecg+Xfrr1LCrNj TNXq1LKAY+CT+kfoQMnfA04rUrFUvoVESkmt8xjvHi15jsO6tmFkICZYfEqTe/FPJl2V9M +9axwDB9PNm1lOFSG3cARJvQk6/JtrIkbPed/FHrv7OMMTXUik8TeOomClDTWAa6Q8nXBU 09ExJDYi3cdyBLs69qrBzddYzhcHwhNMMLLQTyyfstp8oI1R8aILxvtEb3b1eeu6SRdSkF IoG5mjYWlGlVGt/WcjaOjjoRECCwlDdLDvzBPtCVwxbnVTON6cwDVyZlfqctAw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704790088; a=rsa-sha256; cv=none; b=jUsa9s7s21kC57p647Uq0PXGgUoX9eTiWb5O7IUYjMcXGVBCzSFRKBTI+QfuGTV+jyIcNP CyfdxuB3JVpRXkt4PaHnAVV9XLcFlt87Bp08WgOeuQ8OE8abY96kybYJVGmg1E1RXLCH5k j2XuqA+fTk8B1AHkGDpHl9MuIAyRM4xmpazwNZ9FudNGwViBT7y9UNkC8sOtMJYvQ5GhRr idBl9WuqzgSgRDSu4eYs6j5DPlkf6WU3QfYaiAlx6wbZy6/ZuWFM5PcAS+TemyicLia7+9 4+MQRp2UCZnoyiSBrFKtzN/9Z45bEFskzNoszNOPam0sy6FwaHdn0BRWHb6o7g== 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 4T8Phm2YfLzJ6S for ; Tue, 9 Jan 2024 08:48:08 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 09 Jan 2024 09:47:59 +0100 Message-ID: <6714298.qJWK8QVVMX@ravel> In-Reply-To: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.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="nextPart28415695.QdLYigECfs"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart28415695.QdLYigECfs Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Tue, 09 Jan 2024 09:47:59 +0100 Message-ID: <6714298.qJWK8QVVMX@ravel> In-Reply-To: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> MIME-Version: 1.0 > Why not make noatime the default across the whole system? Outside of mbox why is recording access time actually useful? Exactly. I've never found any compelling reason in most uses to enable "atime", except perhaps local mail but as addressed in other answers it is a relic of the past mostly irrelevant today. And its drawbacks are well known and can be serious. The auditing use is not what I consider "normal" in the sense I suspect it concerns a small minority of users (maybe even tiny). Plus, serious auditing requires keeping a log (generally immutable) of accesses, i.e., more than a single time and, as pointed out in another answer, at least the ID of the user performing the access. Updating the access time field on files/directories doesn't address both. What "relatime" only gives you is a guarantee that you know that some file has been accessed at some point after its last modification (or creation), and that the access time is correct if precision is only a day. It also generally lowers I/O obviously, but not in some scenarios (file creation and subsequent read). So, to me, at this point, it still sounds more than a gimmick than something really useful. If someone has a precise use case for it and motivation, than of course please go ahead. In the short term, I'd vote for turning "atime" off by default. Thanks and regards. -- Olivier Certner --nextPart28415695.QdLYigECfs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWdCD8ACgkQjKEwQJce Jid3yQ//fgipM+tVDOYza6TAUKNyEmvFIlL27XQYJocsF9FD8/LS4roCJkZ1Umyg cYzTT2FlxepfZ3mTfBvdHoQ2eTZae8V6+u+2e17gkQ1Eczp26ziCNGrMEgBHXZyo l8eeJ4ajwaQssl1AUCFJ8POQ0Z/5D06GDydhnR0YeLSxVhWwT4HCi8H2zEOpVFzw Eyt2F1u5dZ59NMo2LlTTWcH+xAaomZI2LZuxsAEbzC5ustCxz4crYDPNvhW+psJK UBG1/FVgsKCXUi3PI6xjLkqvgmVe71r8dpa9NEpUERY/TPUAqVCguK6hfTo6YYOR gvdP1Qcp4Ru24OELBMS9URb4//QU18gyymIhizP9glbRXN30ded+LsHY0VfnOC4J tBA44DNlswi7r7AtPaByTGfzMqgTSjNpXk8yhF5uQIpcgpDeng5MJTmnS6W2wsOG crfuc2nGZ+TMsAK/rvnYKdtsbTsgYjW4ywXFD1jYoNrjdTnwGPG7J5ZSgt7hAaKl uU5MLkL8EmhN+799SUAo+K/ywyUBnVdG4vpw9GgWuDYcaczALeS02pJWSLk9GUA/ JzI1jX+/7ULK0guq24bjuSM6F89AUd/w0UexhUFpIFzrYH0Hg3QTDpIXN8Uii+iC 9YMe6vt8Fu8QJ+oBW9xCLjlVsZ5CUQo3vObpbiDVXIDBw9xeEJY= =ZnO9 -----END PGP SIGNATURE----- --nextPart28415695.QdLYigECfs-- From nobody Tue Jan 9 09:42:34 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 4T8QvZ2m0qz56vtf for ; Tue, 9 Jan 2024 09:42:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8QvZ1kJQz4NcV for ; Tue, 9 Jan 2024 09:42:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704793354; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8rIfbo9KhmPuzU1Ly67pQK2Ps67q1epTLBDhNkeBxEA=; b=iyXlX7dE95R5Z36nl162ukJTLnrLy1kmGFgNwhN5LaS8N8ZyWfP17+htTFuAaaTGwrdM4D 5sm7rr8IZ9r1x4bSv22nyozQh0MNHy5UgANzDXgBVzk9P1ziL3VdIqjGHc/74P0DsCKweH SJgq6E/VoBMTfD/mMzxEY7v3H1S0wtOrpjQeIt4WEWa0K8vqMYIkn8/4zbS6A6E2al4eQd WqIQU8/c2H5vh9nKoKOe93M7W0gkMj+5yJGXO5SoYKttxcZR23xKv8xQCKEBfO0VAkPt8+ 1kSwXeZsWQCuhM0O1JzEk/mhjg+1ueUwP+1At70vpZ4zCGdxZeJik0GSgwZu9g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704793354; a=rsa-sha256; cv=none; b=meBvjhPjQ2Xb1FDVk8mzWZR6k7Dx84zvl5bqDSCFZLInY7YHzab5Ax5OWAjoqXuQbTeUJ0 9GRGoRdtj2M9jwIzWtlwLEsHd39rdSJqkcH8+yl/hIEx13PjIpCPhJwThUDpFKMATq585v CwlOb7IVIZi+GZlsjGnI6OI51ggmC7Y86wz7+ZbmSnUGeldjK65mBbwtzMNb62P0lJkUoB PfU0wcX5UfGcPFCXUf/IRoCQDkvCuBvEXdz7+6g/FQbFwFXmyoKMokl2vB1dA2mdSBlpNg 6qN7y+/Oc7bNZFB/c+/m/uDzNU/sBksGE1YaNRmqGrcgOoUyfqysFpShcuREgg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T8QvZ0pBNzlyl for ; Tue, 9 Jan 2024 09:42:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4099gYi9092221 for ; Tue, 9 Jan 2024 09:42:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4099gY48092220 for current@FreeBSD.org; Tue, 9 Jan 2024 09:42:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU Date: Tue, 09 Jan 2024 09:42:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zlei@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197921 Zhenlei Huang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zlei@FreeBSD.org --- Comment #3 from Zhenlei Huang --- It seems we do not have usage that bind a thread to local CPU, otherwise `KASSERT(THREAD_CAN_MIGRATE(td), ("%p must be migratable", td))` will compl= ain (when kernel built with option INVARIANTS). (In reply to Ed Maste from comment #1) > but, what about just moving the KASSERT after the `if (PCPU_GET(cpuid) = =3D=3D cpu)` test? I think that is much simpler. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 9 10:24: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 4T8RrT2Pypz572V0 for ; Tue, 9 Jan 2024 10:24:57 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4T8RrS4Lklz4W5P for ; Tue, 9 Jan 2024 10:24:56 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=uYKomADZ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="a RiS60N"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 96B265C0327 for ; Tue, 9 Jan 2024 05:24:55 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 09 Jan 2024 05:24:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=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=fm2; t=1704795895; x=1704882295; bh=cby6eD33kYM3kPRSLwZT0WTsKJEHXcE3YsA2wUyCUJ8=; b= uYKomADZnKoyoHjifaiTt3sEV1LaOJEmw8M+JuUQgB00c0KVrVveE3Q9FLbuKYSp e3xoewJCAS2+rUrOj/nFViq4regt5MvoDfJELWB3xjkhy9scw/MXzKpyC/7zKjP5 5ySsZS8I87EzZUAYvho+v6bI29m5zKO0K6hW6L2FqvcK47XQ0f62ucm8/JH3MRAv UM1/Cr1oH3MvmcEotJs0mLsf4wWFyu8iqVJpcCyfUcf2BGxGXIE6+ufVU+sAkahP RGeALy+XC0RCCyvMNCT1aKQpuZBZGeNgPBt8OGGnNgDnQgDH+45yjl6ToetaR/au RnMOxJN2p1L7qHs0/p1iwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; t=1704795895; x= 1704882295; bh=cby6eD33kYM3kPRSLwZT0WTsKJEHXcE3YsA2wUyCUJ8=; b=a RiS60N95f0f41LHUohw2CMXTHPrfclD7G7OTbUx/xxVXUEwHBsLbZapcx103NxzC 3Q2b9rTHsiZSDPa4XqY5V7jdPxBpLK/gbWHkjJJbfcTM2akZtEoFuV1I6t1Y6gDI E9b/XT0A0iDYedqbUzCMSv347WYFu/oJt7JqivmVe+J+DsxRYirnzV9Or+3tDLRv UhxeWLzObIVGAIHdrF4R8ybHoeJ6ycn26qTN1pQucB2/aVtiITg/NxwG54AHO3Kq 05Ln3YOvKof9zCqC6wtEabMtJIrMLGWGGno5pXr4HrXKYqYhPra+pOFnR2lcr2cB mce7MAGYKthckXK9mHlSA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 9 Jan 2024 05:24:55 -0500 (EST) Date: Tue, 9 Jan 2024 10:24:53 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.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; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T8RrS4Lklz4W5P On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: > > Was the kernel/utility built with IPv6? If not, that’s a general > bug which should be filed (which can be easily checked/avoided > using the FEATURES(9) subsystem)… > Cheers! >-Enji world/kernel was built with WITHOUT_INET6= in /etc/src.conf I made the problem go away with removing WITHOUT_INET6= and rebuilding. The system was installed by taking FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240104-8bf0882e186e-267378.img and dd-ing it to a usb3-connected hd. Where can I read about features? % man features No manual entry for "features" it's not in apropos thanks, -- From nobody Tue Jan 9 10:47: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 4T8SL434rjz575Pr for ; Tue, 9 Jan 2024 10:47:08 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8SL36kPFz4b3B for ; Tue, 9 Jan 2024 10:47:07 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=TPHhpTKi; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="K fnx1Jg"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D3B155C0388 for ; Tue, 9 Jan 2024 05:47:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Jan 2024 05:47:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=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=fm2; t=1704797227; x=1704883627; bh=mh15CXfClxpxIlwUrULEo1imWHXfsH0RPRCgrChZteU=; b= TPHhpTKiBNYNlJEiixiVMWV4ZDPOGdmMv/eHzR5ubdqIrSEvLcJy/p8fBDvEgU5g tHENkXG6qMuUwYL4GHRA3+pOIVvcUmijiuSnmjSza98fC0ngjflNxSQ6Pikyh1zF uqiuVi//O0qT2gtSmURsXfsxg/pgW5qMBhGnaleL2aRIxCMYnIp+skmDKuPQXTKM gK0bQICGYVtRg193pc+Hh9Bohac4B/sgS8oZzXla0DudI3DnYPQM/ivosuvfgZMj RKR6nxc81yJNkMvrpSZge21/ILWjS6hV4jl6LceMm23x+qf48NN9WB3FC2gZEeJp 1UKFoXaJu6nZ30lOkVidIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; t=1704797227; x= 1704883627; bh=mh15CXfClxpxIlwUrULEo1imWHXfsH0RPRCgrChZteU=; b=K fnx1JgeCvGZLOjep8ymHdiMnlAFQkxeKjq/4ChEjxKnOqbNZThwFLT79eCZjJPVx 78TwteKAdtu4pM7QPuTh1l40F81jgrmGvX6TejRC9G2NL8ek/oSwKkZ1tR/u0d+1 mUUGRX8gnGfJVmK2V6iJ3/SdHd4XWIZKI+mJ0iPekUznoJ0JFbVr9l70X9ZWLT6V d3Qm7oBVL2kx5oJ/4zcyrywIUOAU/7CfKknhqelBa37z3pOgtLQfBhiHSHxpQoQc lAdxbyBEgbbbcHs/SQOJ1vWvho/TQ14RtycSlgKfZTnOKr+dini3SjTAmxJKcstc zZp1lc3rZH5cn8eas1yyg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 9 Jan 2024 05:47:07 -0500 (EST) Date: Tue, 9 Jan 2024 10:47:05 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org 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=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26:c]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T8SL36kPFz4b3B On Mon, Jan 08, 2024 at 12:41:02PM -0800, Xin LI wrote: >On Sun, Jan 7, 2024 at 5:27 AM void wrote: > >> Hi, >> >> Does /var/mail still need atime? >> >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >> rpi4/8BG which installs into one / . If it's mounted with noatime, >> will it have consequences for /var/mail ? > > >It doesn't matter if you don't normally receive emails locally (nowadays, >it's rare). I read the periodic ones locally >If you do receive emails locally, it depends on what application(s) that >you are using. In this type of context it'll be either exim or dma with mutt used for reading the emails. It'll be in whatever the default format is (mbox?) >Most applications nowadays check both mtime and atime plus >sizes of the mailbox file and do not rely on atime (because they saved the >previous mtime). Without atime updates, some application may claim that >you have new mail when the mailbox is not empty when they first start. > >That's said, if I were you and I'm using some flash based storage (with rpi >it's highly likely) regardless if I'm using mail locally; most of the time >the data is not really useful for anything, and it does increase the wear >of your storage. Good to know. When installing, the opportunity to define partitions didn't arise because the image was installed by dd to media that will run the system (in this case a hard disk) I was concerned that email might not work right without atime. So far, it seems to be working OK. My fstab in part looks like this: /dev/ufs/rootfs / ufs rw,noatime,async 1 1 (async is fine because the system won't be used for data that needs to be kept locally, and it's connected to a UPS) -- From nobody Tue Jan 9 11:13:44 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 4T8Swq1zDsz578lR for ; Tue, 9 Jan 2024 11:13:47 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4T8Swp4615z4fxp for ; Tue, 9 Jan 2024 11:13:46 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=F6tiAUzj; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=NIRYH8g6; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 77E525C0326 for ; Tue, 9 Jan 2024 06:13:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 09 Jan 2024 06:13:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :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=fm2; t=1704798826; x=1704885226; bh=9xEHm0szG2 5zaqd+SLpAfBmM8i58HBtWvFDvELbMqD8=; b=F6tiAUzjv0LVCPp8NAwoS8H44r qDCoO3oO+Ls0LnquHIzgVL2ZbB3oORJhljmL77a4Z9ZuvpDfQ/KoWodKIwbzKakH XglBoXEEyEPIK+ZlKcjdhFeRPqdnuOsDhjS7VHyF/c22mPAKsXcus5KyYaz6yNHh KVsXXTFkFg+hu9eetDgkcQ+Faj61+yNtvTNYiRoXBHHbrwZfM78gsP3nk6S1cHto yHSecg/EveUsFyR7Nry691dr55LHIM3eJGVfVyh9T4gLk92hYn12rszaoe9FKODp R8QAJaNQO8PMDAVi8a+Ql3VOwyX8uRPZvMq9gpTocKylE/S/OfArX7l3vWGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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= fm2; t=1704798826; x=1704885226; bh=9xEHm0szG25zaqd+SLpAfBmM8i58 HBtWvFDvELbMqD8=; b=NIRYH8g6DyEWEgKjA234ViDEr0sl644xpOhCbmeLDdTD /WaOzOhTRdgEDUT4bjGATbFslZKahuukKvvkr8ifcf2AxGH0gIo6ZdFzzAPSsq0m YEjVrb3+B92cGswGxJEXJ+A9Eo7sDGO8s8FpAljQNir3RX/kmuQyL8fiT/YU/YAw j7Z/bj4bcjcZxa9TCyEtskKY0JgiFHIDfU6wwKc0hckepD8vx7zHo84IErNlCL8g rBWQRoDrEdQgBAjgK67uEEGKT9UDWlBS5NmW+UhLm8N5+UOoxD2Mm1oCa/KDOADw Xx8LbOH1vpA9tywleXdxJIVHSUhQNXOo/2brEh1a+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 9 Jan 2024 06:13:45 -0500 (EST) Date: Tue, 9 Jan 2024 11:13:44 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@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; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <6714298.qJWK8QVVMX@ravel> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26:c]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T8Swp4615z4fxp On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i > So, to me, at this point, it still sounds more than a gimmick > than something really useful. If someone has a precise use case > for it and motivation, than of course please go ahead. The only use-cases I [1] can think of are either with an email system that needs it or with something like a webserver where there's a team of devops working on the web service who need elevated access and a couple of sysadmins who need root for their general job, and audit or similar is used to log these accesses. But maybe there are more use-cases for atime? but as has been mentioned, most modern mail systems don't need it and I'm not sure how much something like audit would. Do things like tripwire/mtree need it? It's an interesting question. [1] in my limited experience. i've only seen email "needing" it and that's only in some contexts -- From nobody Tue Jan 9 12:16: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 4T8VKH3w1tz57J73 for ; Tue, 9 Jan 2024 12:16:35 +0000 (UTC) (envelope-from robert@rrbrussell.com) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4T8VKG2cPnz4pK3 for ; Tue, 9 Jan 2024 12:16:34 +0000 (UTC) (envelope-from robert@rrbrussell.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rrbrussell.com header.s=fm2 header.b=YmPgcaS2; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=88eo59FT; dmarc=pass (policy=quarantine) header.from=rrbrussell.com; spf=pass (mx1.freebsd.org: domain of robert@rrbrussell.com designates 66.111.4.26 as permitted sender) smtp.mailfrom=robert@rrbrussell.com Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C70AE5C03AD for ; Tue, 9 Jan 2024 07:16:33 -0500 (EST) Received: from imap52 ([10.202.2.102]) by compute1.internal (MEProxy); Tue, 09 Jan 2024 07:16:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rrbrussell.com; h=cc: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=fm2; t=1704802593; x=1704888993; bh=a0Vj9NwYvt ULCu0Ztt6xh2cCd+1pbE3SlQPKfvt6uQg=; b=YmPgcaS2GAhNyBmclOAqbO6zwy cUMoiEVg+5SHGMpBsTNxdCVGJj70mUU3gEw3y2SKFdF+QNhdQ5pNIHCwvM/Hiycd XUtjDsE2l7HsDUqcEc4TlVTWM4tKA6T+d2sNcN1lAoRfymzn8mUGc77TYqp246mL jiL0B00o3kpPjZf3F/UVIBkRE5ONZh+BxbiYNi/89MzVZCA/YGCy9PqeophYp6aJ RkNpr0arxMu8DLZ5DEVooZqF2q/Sw18tuE2PTqCt/kv9F3eBJfqYhEQjJXQJkeFm XBAap1ydn+pfk6YTnBZgOZbHk6GNqfI7vsm9t5Dni0iKyPzWVW8HCQtFZVpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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= fm2; t=1704802593; x=1704888993; bh=a0Vj9NwYvtULCu0Ztt6xh2cCd+1p bE3SlQPKfvt6uQg=; b=88eo59FTBaiUcQBl70lJjc5mzAlYQp4ziLQQu0nQTWIQ W+S+633YSrEltM7v1p5QymJZBC9i0ZA1Hqa/MIB8FdB7xiR7/ufSHaEsRq2fHBjh FUR54q8lQbtCd0Uq5uXggbYQhsIaubLP4oAzsoAYQKDBRAUJfsldG1eS1zjtHbxy pt2HawYptDdrJjcJVKm5jjNmDMNGzQ64WT4x3xoRdfrz2HKsvhoKFkYwIijNLbiz CnspHhB3hJmbzFlxt0CGp743z7eLGkoFEGeZONGwmTBeNQ/5HtwPF+w1ienmiFYc RngMVDS9cEC3i5dRuYm6dZMHsO0uC4v5oQNret0gMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhmnecu ggftrfgrthhtvghrnhepkefhffevveeugfetteegueegledviedvffevvddtieehvdekke elvefhhfevgedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomh X-ME-Proxy: Feedback-ID: ie421460a:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8BA36C60091; Tue, 9 Jan 2024 07:16:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 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: <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> In-Reply-To: References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> Date: Tue, 09 Jan 2024 06:16:13 -0600 From: robert@rrbrussell.com To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Content-Type: text/plain X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[rrbrussell.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[rrbrussell.com:s=fm2,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[robert]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_NO_DN(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[rrbrussell.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4T8VKG2cPnz4pK3 On Tue, Jan 9, 2024, at 05:13, void wrote: > On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i > >> So, to me, at this point, it still sounds more than a gimmick >> than something really useful. If someone has a precise use case >> for it and motivation, than of course please go ahead. > > The only use-cases I [1] can think of are either with an email system > that needs it or with something like a webserver where there's > a team of devops working on the web service who need elevated access > and a couple of sysadmins who need root for their general job, and audit > or similar is used to log these accesses. > > But maybe there are more use-cases for atime? > > but as has been mentioned, most modern mail systems don't need it > and I'm not sure how much something like audit would. Do things > like tripwire/mtree need it? It's an interesting question. No, they use other data and checksums instead of access times. > > [1] in my limited experience. i've only seen email "needing" it > and that's only in some contexts > -- From nobody Tue Jan 9 12:23: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 4T8VV53bpHz57KFk for ; Tue, 9 Jan 2024 12:24:13 +0000 (UTC) (envelope-from robert@rrbrussell.com) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8VV46qk8z4r7r for ; Tue, 9 Jan 2024 12:24:12 +0000 (UTC) (envelope-from robert@rrbrussell.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rrbrussell.com header.s=fm2 header.b=Ctz6Wv6F; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="q O8I7SI"; dmarc=pass (policy=quarantine) header.from=rrbrussell.com; spf=pass (mx1.freebsd.org: domain of robert@rrbrussell.com designates 66.111.4.26 as permitted sender) smtp.mailfrom=robert@rrbrussell.com Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CCE085C042E for ; Tue, 9 Jan 2024 07:24:12 -0500 (EST) Received: from imap52 ([10.202.2.102]) by compute1.internal (MEProxy); Tue, 09 Jan 2024 07:24:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rrbrussell.com; h=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=fm2; t=1704803052; x=1704889452; bh=OT5dh2Jin0AmbB0oCl1mzYt+eF44CvFeNL6Y6FFN8WQ=; b= Ctz6Wv6FvQ+T41RofJ3H69ZSkxk6uLMMJlKvQLWwEaIO+mP35aDEZvn6GxADsa21 QprOqwK4pMRcGP3pvpj7tOB3VYxovO8ot6chHHk6GJ28ZJQOP6U78XI/lvJLAOu+ hrliqyaqUzCGWwm4KAjVZHiwcfdkEqrxFVtkwzfiXkOZ55zLUh/cvCHNN6uwUXmo PJwCjRqW+gIXY6xtEXaegh6W61UD0mNj3r+P3bJqVGzzfPcr8G6wgeb1OkqDPw4B rRUuMoJTA+HKRH7gY2FuOQ4PUS9kwbjA11+0uAtAjBueeLh5kuRZ2zXHe5C7XuE8 K2BA2wdRIqo2diJjTVPL1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; t=1704803052; x= 1704889452; bh=OT5dh2Jin0AmbB0oCl1mzYt+eF44CvFeNL6Y6FFN8WQ=; b=q O8I7SIjyefOR6F8/r2eTtog3p6MKjq/uT4E7V9t7OBFZ6rlkZJF6qApAP9DGN262 zZ8jrHw2woJTbKpCmUinBfyfagS+y4G8wUehNYRFOKBJned9L+VOX7xjHyO4T7P2 F+CSaNAUXmRpfLeaQPYLy7h58Jh2gsYg905BhWyopo6oPmDjeg910l/rDjrAl7yj TIPPFO+wj9wWUS7S0SrxIdCH6Iuk7kFaVCQ3HySPXFO0dhezkkA6ix6usmEiDY7B yrcEfUsOMdPWIEyNUmpGY9+YhADytL4+HyBs5z/0heTeAdq55MurIRErZA36q72t I0ivd3yAJiINRMd2yrl5g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomhen ucggtffrrghtthgvrhhnpedtvdefieduffeiheeiieegieejleetveevhfevtdfhkeeike efffeigfffteetteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhm X-ME-Proxy: Feedback-ID: ie421460a:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8AD1FC60093; Tue, 9 Jan 2024 07:24:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 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: <1173b407-cb6f-4e21-af87-4f1755bfb292@app.fastmail.com> In-Reply-To: References: Date: Tue, 09 Jan 2024 06:23:15 -0600 From: robert@rrbrussell.com To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[rrbrussell.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[rrbrussell.com:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[robert]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FROM_NO_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[rrbrussell.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4T8VV46qk8z4r7r On Tue, Jan 9, 2024, at 04:47, void wrote: > On Mon, Jan 08, 2024 at 12:41:02PM -0800, Xin LI wrote: >>On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void wrote: >> >>> Hi, >>> >>> Does /var/mail still need atime? >>> >>> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >>> rpi4/8BG which installs into one / . If it's mounted with noatime, >>> will it have consequences for /var/mail ? >> >> >>It doesn't matter if you don't normally receive emails locally (nowada= ys, >>it's rare). > > I read the periodic ones locally > >>If you do receive emails locally, it depends on what application(s) th= at >>you are using. =20 > > In this type of context it'll be either exim or dma with mutt used for= reading > the emails. It'll be in whatever the default format is (mbox?) set mbox_type=3DMaildir forces Mutt to use the Maildir format. I remembe= r one or more of Postfix, Procmail, Mutt, and Dovecot assuming the Maild= ir format for any folder or spool file that ended in a /.=20 > >>Most applications nowadays check both mtime and atime plus >>sizes of the mailbox file and do not rely on atime (because they saved= the >>previous mtime). Without atime updates, some application may claim th= at >>you have new mail when the mailbox is not empty when they first start. >> >>That's said, if I were you and I'm using some flash based storage (wit= h rpi >>it's highly likely) regardless if I'm using mail locally; most of the = time >>the data is not really useful for anything, and it does increase the w= ear >>of your storage. > > Good to know. When installing, the opportunity to define partitions > didn't arise because the image was installed by dd to > media that will run the system (in this case a hard disk) > > I was concerned that email might not work right without atime. > So far, it seems to be working OK. > > My fstab in part looks like this: > > /dev/ufs/rootfs / ufs rw,noatime,async 1 1 > > (async is fine because the system won't be used for data that > needs to be kept locally, and it's connected to a UPS) > -- From nobody Tue Jan 9 12:24:40 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 4T8VVg17tDz57KW6 for ; Tue, 9 Jan 2024 12:24:43 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8VVf4MXQz4s3k for ; Tue, 9 Jan 2024 12:24:42 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=wrnPNqKj; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="5 jSXN7o"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7B7C85C03C8 for ; Tue, 9 Jan 2024 07:24:42 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 09 Jan 2024 07:24:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=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=fm2; t=1704803082; x=1704889482; bh=E/juPcgmOo96IXUdRcd7fRKbOgfhtM/fcIY1lPb884w=; b= wrnPNqKjr2vRI6wmu8XvDCVo7xOyRRdT3Pjp5MULgrVc1YzRLcTCbwtGDraXqSdi tC/NR9dOhMrCiPEs+vXwp+hWkpjGlHDI4e2+ukMMwAsj+twMHqV97oQ+PaUR+zDF aK6n71EiNm43OOv8zNjaBlP4ZkU+OkkD25if1SgBfeJ4JrX9FcBLVqj7ratCl4eQ TdqRVZkj2hJ86bTWo5X3P0pmze33QuKiApshMFwEJGYXc08KMW7D28Rv0hEwQcs0 GPGFNhrYj0w4zhQw0sMQR67ts8FmiH4uyI+DmtZdyeXzOsdrP6Z2Gu1V3d+sAqh2 +WvZtmTNo48Y+U3L4DNf9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; t=1704803082; x= 1704889482; bh=E/juPcgmOo96IXUdRcd7fRKbOgfhtM/fcIY1lPb884w=; b=5 jSXN7oPHjLTgJZxvaE19DSLcgBz14kjWmL1VPX0FrCbjY3cJNzLRlhi0d/0bjQql wg9ueMwV+ZFO2t2MhoiKfFKI9Ggf2iIOUD8rmPVXmefLHf1+SemgqBNrLGhv37oM 6g0B/sh3xYP+dwmP8l4pTRDsGgMxxZB/xYdI9IClfDLbFjJ3f76xVm3xCGXl8OkE L0/lcA8J9It6Rj/Aa88XjOLJuEg5ZqQceBT62tkb+bQLeCIInYVqvr+hB+dM5OfQ tmgwCuIRk0q9oFMzhj5OQ3R/6JmB1c2D1Ux3NsofhWsYRGKIfnnuz4bbrREqsDOS 9jFd2q0iCYIwVvjC3zIOQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 9 Jan 2024 07:24:41 -0500 (EST) Date: Tue, 9 Jan 2024 12:24:40 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.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; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T8VVf4MXQz4s3k On Tue, Jan 09, 2024 at 10:24:53AM +0000, void wrote: >On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: >> >>Was the kernel/utility built with IPv6? If not, that’s a general bug >>which should be filed (which can be easily checked/avoided using the >>FEATURES(9) subsystem)… >>Cheers! >>-Enji > >world/kernel was built with WITHOUT_INET6= in /etc/src.conf > >I made the problem go away with removing WITHOUT_INET6= and rebuilding. I'll re-add this to try and replicate the problem with the same sources (main-n267425-aa1223ac3afc) and if it happens again I'll make a PR for it -- From nobody Tue Jan 9 15:17:41 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 4T8ZLL2wdpz55Z2N for ; Tue, 9 Jan 2024 15:17:46 +0000 (UTC) (envelope-from void@f-m.fm) 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 4T8ZLJ6pTtz40JX for ; Tue, 9 Jan 2024 15:17:44 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=lcadSnTl; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="Q lFrfoS"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.29 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3E3905C052F for ; Tue, 9 Jan 2024 10:17:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 09 Jan 2024 10:17:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=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=fm2; t=1704813464; x=1704899864; bh=PiONA04yMsk/vapIYNdqD5m98TQvXQQuigmXFgr3sZw=; b= lcadSnTlyvZzQemX621TXcfKgmHInus2sESXWQ1nbYuJYLQ/VQIOJIeSNLd5yEHW 4QPUVhbc+HfNI3Bsh/ihu9piamsJnLvPfvqI1qM9VGXqzCpzfnvyuppCXU7qxh1C CHWoSkSFErwf1GbrCwtdv6tpk6DcO+Gi11URJ6dLAcykzhz5KSkYUqOSijngY79R GRIUtRCkdT7qh/RYjDtamPC5GgHb1SeUDGk80RG+YoaRxh86yZUxrUx18K9UbZHI JPJ4vOvHOq43xUHRjFki74oiMDMrC4n1sPSlQSYcdK3eebfjgHPSQNQF14FxtZsZ 8bIGmfXHdyb1NqvWpZeI5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; t=1704813464; x= 1704899864; bh=PiONA04yMsk/vapIYNdqD5m98TQvXQQuigmXFgr3sZw=; b=Q lFrfoSbFWs5K9Of0dzAXlxr+30WHdG3EvXJg5/5O8mWbluyOnYEqnt9XcK0VerYn v9qW9ts4kKuBV214NJJPledQi50Tylzx0mD4N789Z51AK3DR9laSao5rzTGJ5fV5 M5MyZgtA9CCBXPebN/ujOms+UtxRAoNrUxGBhy4i8TQdF1u2d7tWc1ymR/mBf0HG zDe3FqCbxotx5rS4QRmGlz5jd5Lnr0kc4c9dP/eB2GHx7m47JkKVNjCONL0x0OxW SdQvD9aSL4u4kTirj+VwoF2m9in7Et3+XRWd64p8QypZdaKbYNrv+zpu7Rci6H/b GrsN9VrWtuDPZLzPA3gIQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 9 Jan 2024 10:17:43 -0500 (EST) Date: Tue, 9 Jan 2024 15:17:41 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.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; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T8ZLJ6pTtz40JX On Tue, Jan 09, 2024 at 12:24:40PM +0000, void wrote: >On Tue, Jan 09, 2024 at 10:24:53AM +0000, void wrote: >>On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: >>> >>>Was the kernel/utility built with IPv6? If not, that’s a general >>>bug which should be filed (which can be easily checked/avoided >>>using the FEATURES(9) subsystem)… >>>Cheers! >>>-Enji >> >>world/kernel was built with WITHOUT_INET6= in /etc/src.conf >> >>I made the problem go away with removing WITHOUT_INET6= and rebuilding. > >I'll re-add this to try and replicate the problem with the same sources >(main-n267425-aa1223ac3afc) and if it happens again I'll make a PR for it I forgot about this line: options INET6 # IPv6 communications protocols which, on current/arm64 lives in std.arm64 which gets included by GENERIC which is included by GENERIC-MMCCAM which is included by GENERIC-MMCCAM-NODEBUG commenting it out and having WITHOUT_INET6= in /etc/src.conf and rebuilding fixes the problem. Sorry for the noise. -- From nobody Tue Jan 9 17:02:50 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 4T8cgs3Cdrz55vCd for ; Tue, 9 Jan 2024 17:03:05 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 4T8cgr2zkxz4GXJ for ; Tue, 9 Jan 2024 17:03:04 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=byt2HG+y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=delphij@gmail.com Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-50ea9daac4cso3333181e87.3 for ; Tue, 09 Jan 2024 09:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704819782; x=1705424582; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=cvQoGldGoXXEGalaWvVB+1upxrA/0EoaxuT2X99aNpo=; b=byt2HG+yvIv1ChBFHm7nm18NVJNUe4oR7k/YQw2/LSr51sERbhMx8aqu1JasCe0Fln H+LKisUzojuHXGKlGdyhTxmHNnv63DAXzgGAdjDyOejYOp5NbCtHNOD3t4eYS8B6fgKk mKWiE5Vr/tB3h4xzC0pxMuKSZgXs45xXLyenJcGmVR+pK/dJWwp0GRNWI5BbW2yB9feF bRVq2d05YC97KA3TTq74l9i2B3L9EFLhNztNyEE90u540NihwQhjdcQff2udXDJJuoLR 04PnTG85mho8TLdwdj6DkWE2mo0nTkcCd9zR36dxVm2ZPNjKHoH8j/UOO4q/gbBx2MIu +B8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704819782; x=1705424582; h=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=cvQoGldGoXXEGalaWvVB+1upxrA/0EoaxuT2X99aNpo=; b=kQodjxhLR02cpB/9g+O/bZzRbFsdy5Z5n5C8ukh23bHruDU7mWb0lXYZgPrfpmZFmv 6hPCaDwU5UhNGj8xREHaKZTiHy00ZWOnGPKSUpBU8+54QMhMu9pwYsfDzsJinQBRuL2Y 3SwANnHjrRUTnx9dvawCxoMPOn8Rta92BefDPV4VrHFrOYACL/cafXkxMvIEudF5DCl6 Z7CDfQoBtapztC559l9cMKGN+RZ/1l+TjnMoKxFOddyMGJnZHTtfPst4kQpOAiUraOGR LLPQr2YMiLl451rdo2HYwCCf5sKK6ZrDsIZCFo9jWkeDPi77Un/tCkpOOlvonIXW3REW IIKg== X-Gm-Message-State: AOJu0Yzt/C8sFlkmOqlKNqII61+T1PN4lPnwUd5evZOXQ5kgJhQIBBGl 9LF/G4Fh2iBJwfiU5LzKogESkrUxdPDOLDUnkVxtVUq7 X-Google-Smtp-Source: AGHT+IGdLIXOkazYxpHOMIFlbLOEoR6VKSReBfTlth7AM9fULcVr+va9t9UWq15CEWzn3kK/vg4qLF45+6315/JLjSY= X-Received: by 2002:a05:6512:1045:b0:50e:560c:351 with SMTP id c5-20020a056512104500b0050e560c0351mr3166522lfb.3.1704819782242; Tue, 09 Jan 2024 09:03:02 -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: Xin LI Date: Tue, 9 Jan 2024 09:02:50 -0800 Message-ID: Subject: Re: noatime on ufs2 To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000086d45d060e864902" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.97)[-0.972]; 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]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12e:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEFALL_USER(0.00)[delphij]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T8cgr2zkxz4GXJ --00000000000086d45d060e864902 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 9, 2024 at 2:47=E2=80=AFAM void wrote: > I was concerned that email might not work right without atime. > So far, it seems to be working OK. > Depending on how you define "correct". Deliveries won't be affected by atime setting in any way; telling if you have new mail _may_ be affected, but it would be at worst annoying (shell / MUA claims you have new mail while you don't, and even that it's only for their startup, once the shell is running it won't rely on atime). Cheers, --00000000000086d45d060e864902 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 9, 2024 at 2:47=E2=80= =AFAM void <void@f-m.fm> wrote:
I was concerned th= at email might not work right without atime.
So far, it seems to be working OK.

Depending on how you define "correct".=C2= =A0 Deliveries won't be affected by atime setting in any way; telling i= f you have new mail _may_ be affected, but it would be at worst annoying (s= hell / MUA claims you have new mail while you don't, and even that it&#= 39;s only for their startup, once the shell is running it won't rely on= atime).

Cheers,
--00000000000086d45d060e864902-- From nobody Tue Jan 9 17:43:18 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 4T8fBl4vbmz5673F for ; Tue, 9 Jan 2024 18:11:27 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8fBl3WDJz4T2m for ; Tue, 9 Jan 2024 18:11:27 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none Date: Tue, 09 Jan 2024 18:43:18 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: robert@rrbrussell.com Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> In-Reply-To: <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> Mail-Followup-To: robert@rrbrussell.com, freebsd-current@freebsd.org User-Agent: s-nail v14.9.24-585-g9999e323b6 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. 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-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T8fBl3WDJz4T2m 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] robert@rrbrussell.com wrote in <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>: |On Tue, Jan 9, 2024, at 05:13, void wrote: |> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i |>> So, to me, at this point, it still sounds more than a gimmick=20 |>> than something really useful. If someone has a precise use case=20 Email existence checks are in UNIX for many decades. In fact since 1974-11-26 when Ken Thompson added that to login(1). "You have new mail" is in BSD since Commit: Bill Joy CommitDate: 1978-11-05 19:59:54 -0800 Start development on BSD 3 Create reference copy of all prior development files in BSD Mail and csh(1). And today in bash(1), for example, there can be read /* If the user has just run a program which manipulates the mail file, then don't bother explaining that the mail file has been manipulated. Since some systems don't change the access time to be equal to the modification time when the mail in the file is manipulated, check the size also. If the file has not grown, continue. */ if ((atime >=3D mtime) && !file_is_bigger) continue; /* If the mod time is later than the access time and the file has grown, note the fact that this is *new* mail. */ if (use_user_notification =3D=3D 0 && (atime < mtime) && file_is_bi= gger) message =3D _("You have new mail in $_"); I would not exactly call this a gimmick. On Linux mount(8) from https://github.com/karelzak/util-linux says relatime Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than or equal to the current modify or change time. (Similar to noatime, but it doesn=E2=80=99t break mutt(1) or other applications that need= to know if a file has been read since the last time it was modified.) and this is what i use, except for some noatime mount points (/x/doc, /x/music, /x/pub, to be exact). --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 Tue Jan 9 20:23: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 4T8j7f5Pw5z56VVH for ; Tue, 9 Jan 2024 20:23:58 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8j7d5Bsrz4pw6; Tue, 9 Jan 2024 20:23:57 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rhurlin@gwdg.de designates 134.76.10.26 as permitted sender) smtp.mailfrom=rhurlin@gwdg.de Received: from mbx19-gwd-03.um.gwdg.de ([10.108.142.56] helo=email.gwdg.de) by mailer.gwdg.de with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (GWDG Mailer) (envelope-from ) id 1rNIde-0001cj-35; Tue, 09 Jan 2024 21:23:54 +0100 Received: from [192.168.178.23] (10.250.9.199) by MBX19-GWD-03.um.gwdg.de (10.108.142.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.2.1258.28; Tue, 9 Jan 2024 21:23:54 +0100 Message-ID: <423b62fc-6687-4e56-b8e7-ecaebcadfd7f@gwdg.de> Date: Tue, 9 Jan 2024 21:23:54 +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 From: Rainer Hurling Subject: kernel: fatal trap 12 on CURRENT, when using WireGuard Reply-To: Rainer Hurling To: Content-Language: en-US CC: Gleb Smirnoff Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-13.um.gwdg.de (134.76.9.222) To MBX19-GWD-03.um.gwdg.de (10.108.142.56) X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.990]; RWL_MAILSPIKE_EXCELLENT(-0.40)[134.76.10.26:from]; RCVD_IN_DNSWL_MED(-0.20)[134.76.10.26:from]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; DMARC_NA(0.00)[gwdg.de]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; FREEFALL_USER(0.00)[rhurlin]; ASN(0.00)[asn:207592, ipnet:134.76.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XOIP(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; HAS_REPLYTO(0.00)[rhurlin@FreeBSD.org] X-Rspamd-Queue-Id: 4T8j7d5Bsrz4pw6 I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very recent commit. The build and install went fine. After booting with new base, I got a page fault with the following error: Kernel page fault with the following non-sleepable locks held: shared rm netlink lock (netlink lock) r = 0 (0xfffff8005fc8ca20) locked @ /usr/src/sys/netlink/netlink_domain.c:241 exclusive rw lle (lle) r = 0 (0xfffff801951dce90) locked @ /usr/src/sys/netinet/in.c:1716 stack backtrace: #0 0xffffffff80bc6c45 at witness_debugger+0x65 #1 0xffffffff80bc7d89 at witness_warn+0x3e9 #2 0xffffffff81056b18 at trap_pfault+0x88 #3 0xffffffff81028708 at calltrap+0x8 #4 0xffffffff80dbd6a2 at nl_send_group+0x1d2 #5 0xffffffff80dc0e27 at _nlmsg_flush+0x37 #6 0xffffffff80dc4fdc at rtnl_lle_event+0x10c #7 0xffffffff80d15e32 at arp_mark_lle_reachable+0xd2 #8 0xffffffff80d15b43 at arp_check_update_lle+0x293 #9 0xffffffff80d151c5 at arpintr+0xa65 #10 0xffffffff80caaaed at netisr_dispatch_src+0xad #11 0xffffffff80c8d57a at ether_demux+0x0x17a #12 0xffffffff80c8ec53 at ether_nh_input+0x403 #13 0xffffffff80caaaed at netisr_dispatch_src+0xad #14 0xffffffff80c8d9c9 at ether_input+0xd9 #15 0xffffffff80ca66ac at iflib_rxeof+0xe4c #16 0xffffffff80ca0b5a at _task_fn_rx+0x7a #17 0xffffffff80ba0118 at gtaskqueue_run_locked+0xa8 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x30000 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80dc0a10 stack pointer = 0x28:0xfffffe006a3a8760 frame pointer = 0x28:0xfffffe006a3a8790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1. def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (if_io_tqg_0) rdi: fffffe006a3a8850 rsi: fffffe006a3a86f0 rdx: fffffe006a3a87b0 rcx: fffff80001f88740 r8: ffffffff83210090 r9: 0000000000000000 rax: 0000000000000000 rbx: 0000000000030000 rbp: fffffe006a3a8790 r10: 0000000000000001 r11: 0000000000000000 r12: fffff8005fc8ca00 r13: fffff8005fc8ca20 r14: fffffe006a3a8850 r15: 0000000000000000 trap number = 12 panic: page fault cpuid = 0 time = 1704824328 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe006a3a8430 vpanic() at vpanic+0x131/frame 0xfffffe006a3a8560 panic() at panic+0x43/frame 0xfffffe006a3a85c0 trap_fatal() at trap_fatal+0x40f/frame 0xfffffe006a3a8620 trap_pfault() at trap_pfault+0xae/frame 0xfffffe006a3a8690 calltrap() at calltrap+0x8/frame 0xfffffe006a3a8690 --- trap 0xc, rip = 0xffffffff80dc0a10, rsp = 0xfffffe006a3a8760, rbp = 0xfffffe006a3a8790 --- nl_send_one() at nl_send_one+0x20/frame 0xfffffe006a3a8790 nl_send_group() at nl_send_group+0x1d2/frame 0xfffffe006a3a8820 _nlmsg-flush() at _nlmsg_flush+0x37/frame 0xfffffe006a3a8840 rtnl_lle_event() at rtnl_lle_event+0x10c/frame 0xfffffe006a3a88e0 arp_mark_lle_reachable() at arp_mark_lle_reachable+0xd2/frame 0xfffffe006a3a8930 arp_check_update_lle() at arp_check_update_lle+0x293/frame 0xfffffe006a3a8a00 arpintr() at arpintr+0xa65/frame 0xfffffe006a3a8b60 netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfffffe006a3a8bc8 ether_demux() at ether_demux+0x17a/frame 0xfffffe006a4a8bf0 ether_nh_input() at ether_nh_input+0x403/frame 0xfffffe006a3a8c40 netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfffffe006a3a8ca0 ether_input() at ehter_input+0xd9/frame 0xfffffe006a3a8d00 iflib_rxeof() at iflib_rxeof+0xe4c/frame 0xfffffe006a3a8e00 _task_fn_rx() at _task_fn_rx+0x7a/frame 0xfffffe006a3a8e40 gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa8/frame 0xfffffe006a3a8ec0 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xd3/frame 0xfffffe006a3a8ef0 fork_exit() at fork_exit+0x82/frame 0xfffffe006a3a8f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe006a3a8f30 --- trap 0xf2b9f109, rip = 0x7afef8a176bef8a5, rsp = 0xddc963edd18963e9, rbp = 0x61f64fc36db64fc7 KDB: enter: panic [ thread pid 0 tid 100067 ] Stopped at kdb_enter+0x33: movq $0,0xe3a582(%rip) db> Since the current process 'if_io_tqg_0' and problems with netlink are mentioned, I searched in the area of my network connections. I discovered that this page fault only occurs when a connection is established with WireGuard (wg-quick up wg0). Without using WireGuard, this error does not occur. I was able to find out at which commit this behavior occurs with my box: - Up to commit main-n267347-660bd40a598a everything is fine. - The two following commits n267348-67d9023f07a4 and n267349-0ad011ececb9 do not build on my box (module/netlink broken ...). - From commit n267349-0ad011ececb9 (netlink) onwards this page fault occurs when WireGuard is started. Any help is greatly appreciated. CC'ed Gleb Smirnoff due to the affected commits. Regards, Rainer Hurling From nobody Tue Jan 9 20:40:59 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 4T8jWJ6QWNz56Xv4 for ; Tue, 9 Jan 2024 20:41:00 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from glebi.us (glebi.us [162.251.186.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4T8jWJ5J0Nz4sqh; Tue, 9 Jan 2024 20:41:00 +0000 (UTC) (envelope-from glebius@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by glebi.us (Postfix, from userid 1000) id C06826A583; Tue, 9 Jan 2024 12:40:59 -0800 (PST) Date: Tue, 9 Jan 2024 12:40:59 -0800 From: Gleb Smirnoff To: Rainer Hurling Cc: freebsd-current@freebsd.org Subject: Re: kernel: fatal trap 12 on CURRENT, when using WireGuard Message-ID: References: <423b62fc-6687-4e56-b8e7-ecaebcadfd7f@gwdg.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 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Bg+iM+vkVc6+oo40" Content-Disposition: inline In-Reply-To: <423b62fc-6687-4e56-b8e7-ecaebcadfd7f@gwdg.de> X-Rspamd-Queue-Id: 4T8jWJ5J0Nz4sqh 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:27348, ipnet:162.251.186.0/24, country:US] --Bg+iM+vkVc6+oo40 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Rainer, On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote: R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very R> recent commit. The build and install went fine. After booting with new R> base, I got a page fault with the following error: Sorry for that, my fault. Can you please test this patch? -- Gleb Smirnoff --Bg+iM+vkVc6+oo40 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="n.diff" diff --git a/sys/netlink/netlink_domain.c b/sys/netlink/netlink_domain.c index 7660dcada103..4790845d1d31 100644 --- a/sys/netlink/netlink_domain.c +++ b/sys/netlink/netlink_domain.c @@ -233,7 +233,7 @@ nl_send_group(struct nl_writer *nw) copy = nl_buf_copy(nb); if (copy != NULL) { nw->buf = copy; - (void)nl_send_one(nw); + (void)nl_send(nw, nlp_last); } else { NLP_LOCK(nlp_last); if (nlp_last->nl_socket != NULL) @@ -246,7 +246,7 @@ nl_send_group(struct nl_writer *nw) } if (nlp_last != NULL) { nw->buf = nb; - (void)nl_send_one(nw); + (void)nl_send(nw, nlp_last); } else nl_buf_free(nb); diff --git a/sys/netlink/netlink_io.c b/sys/netlink/netlink_io.c index fb8e0a46e8dd..5f50c40f71d8 100644 --- a/sys/netlink/netlink_io.c +++ b/sys/netlink/netlink_io.c @@ -194,9 +194,8 @@ nl_taskqueue_handler(void *_arg, int pending) * If no queue overrunes happened, wakes up socket owner. */ bool -nl_send_one(struct nl_writer *nw) +nl_send(struct nl_writer *nw, struct nlpcb *nlp) { - struct nlpcb *nlp = nw->nlp; struct socket *so = nlp->nl_socket; struct sockbuf *sb = &so->so_rcv; struct nl_buf *nb; diff --git a/sys/netlink/netlink_message_writer.c b/sys/netlink/netlink_message_writer.c index 0b85378b41b6..50305e3d9d80 100644 --- a/sys/netlink/netlink_message_writer.c +++ b/sys/netlink/netlink_message_writer.c @@ -65,6 +65,13 @@ nlmsg_get_buf(struct nl_writer *nw, u_int len, bool waitok) return (true); } +static bool +nl_send_one(struct nl_writer *nw) +{ + + return (nl_send(nw, nw->nlp)); +} + bool _nlmsg_get_unicast_writer(struct nl_writer *nw, int size, struct nlpcb *nlp) { diff --git a/sys/netlink/netlink_var.h b/sys/netlink/netlink_var.h index c8f0d02a0dab..ddf30b373446 100644 --- a/sys/netlink/netlink_var.h +++ b/sys/netlink/netlink_var.h @@ -130,9 +130,7 @@ void nl_osd_unregister(void); void nl_set_thread_nlp(struct thread *td, struct nlpcb *nlp); /* netlink_io.c */ -#define NL_IOF_UNTRANSLATED 0x01 -#define NL_IOF_IGNORE_LIMIT 0x02 -bool nl_send_one(struct nl_writer *); +bool nl_send(struct nl_writer *, struct nlpcb *); void nlmsg_ack(struct nlpcb *nlp, int error, struct nlmsghdr *nlmsg, struct nl_pstate *npt); void nl_on_transmit(struct nlpcb *nlp); --Bg+iM+vkVc6+oo40-- From nobody Tue Jan 9 21:08: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 4T8k6p2Sm7z56P6k for ; Tue, 9 Jan 2024 21:08:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 4T8k6n3T56z40y6 for ; Tue, 9 Jan 2024 21:08:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=NO96LfWG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62a) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a2814fa68eeso274490766b.1 for ; Tue, 09 Jan 2024 13:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704834496; x=1705439296; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=S5zfz9YeVt15VctawArXgtos2ULJxb/GQ9PlXKDeoQQ=; b=NO96LfWGcZnkE6QbvnTnK+1EDSa3RFMxPRk8/6kgsFTFbi9bwXI0Ck6dlzsxAmYR2i zDowa2djQ6R+0yjGjTDIt0g+2llKyhBzg3FO5cff9eS1Qsat9DaW7cQvrlSHa2Tagokz CLhcNIys2KUm2IkdKgv5qmTVSexoc3SeNJ6Kig7lBDSCrG9FEyxlBuCmpCkTnIArl5G3 1j306a519kG8OZotE7kxzvCafxq5JsJngSy6FBo/ZBsZWK11QPtoCnXkDeAtKPk/Wbbv E5wxVJo/mZJ/dZ6yku2beciNj5Q4ZMW1LHYaUKtBGUY+3DQOV9GRHUO+XKxVrhtYVw4e 6d4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704834496; x=1705439296; h=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=S5zfz9YeVt15VctawArXgtos2ULJxb/GQ9PlXKDeoQQ=; b=DuDHkiEXIRJtHckgYqWWhIcz5cbRK9hmdJER2CIMxinQPM4GlXXH0MwgZtaXZ5FUyZ aytqKRtxEBksXWxOX1chl5gm9Mkng7Ig2ZRS9U4p7fiVZqFlF0vOE1pztMzF8l0U1Ym4 Um+BlqS01WIm9Xeu4XO/4o5FlkhZFZYCnAe1o3FrFkC0NyqUtZ3V5Xw+FDDdwC7Q2C3k LUGq3s0vKxa9JBVcAbg+7nYBr1UiTBBvWSBjwoPHFaGLp6EfiOKy4W6V5trZTVAkJb/V eY8+G4W7M/bf4Qx01lIhdFL5iLdwH5jeBPlkiYofqfAfAU9KwoHfFIoEJDLPeAYVy22g zSOA== X-Gm-Message-State: AOJu0YywQzlIjxKfjK/wPW0si7fyORfwy7cCfqXn3Jkl9yR+rJECNk83 gXG01ICv/G9ISSgJVsLLcNnDIP4AAW6BZ4o5ZAl01R6jObjZ4p0lb6Od7fm/FhI= X-Google-Smtp-Source: AGHT+IHW1BUhbL0Y6FMy+VJwHHfqFQZuVReTT/M77QjjWZVRbfM8VPhgA1p6BZEN6roWc11AmZnmdHr6gYkBqRq1n3U= X-Received: by 2002:a17:906:80e:b0:a23:339f:3313 with SMTP id e14-20020a170906080e00b00a23339f3313mr51228ejd.55.1704834495256; Tue, 09 Jan 2024 13:08:15 -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: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> <20240109174318.MCIB6yhn@steffen%sdaoden.eu> In-Reply-To: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> From: Warner Losh Date: Tue, 9 Jan 2024 14:08:03 -0700 Message-ID: Subject: Re: noatime on ufs2 To: robert@rrbrussell.com, FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000007dae3b060e89b695" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4T8k6n3T56z40y6 --0000000000007dae3b060e89b695 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 9, 2024, 11:11=E2=80=AFAM Steffen Nurpmeso = wrote: > robert@rrbrussell.com wrote in > <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>: > |On Tue, Jan 9, 2024, at 05:13, void wrote: > |> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i > |>> So, to me, at this point, it still sounds more than a gimmick > |>> than something really useful. If someone has a precise use case > > Email existence checks are in UNIX for many decades. > In fact since 1974-11-26 when Ken Thompson added that to login(1). > "You have new mail" is in BSD since > > Commit: Bill Joy > CommitDate: 1978-11-05 19:59:54 -0800 > It has also been used for almost as long to see if log files have changed if you set your MAIL variable to that. So not just for email... Warner Start development on BSD 3 > Create reference copy of all prior development files > > in BSD Mail and csh(1). > And today in bash(1), for example, there can be read > > /* If the user has just run a program which manipulates the > mail file, then don't bother explaining that the mail > file has been manipulated. Since some systems don't change > the access time to be equal to the modification time when > the mail in the file is manipulated, check the size also. If > the file has not grown, continue. */ > if ((atime >=3D mtime) && !file_is_bigger) > continue; > > /* If the mod time is later than the access time and the file > has grown, note the fact that this is *new* mail. */ > if (use_user_notification =3D=3D 0 && (atime < mtime) && > file_is_bigger) > message =3D _("You have new mail in $_"); > > I would not exactly call this a gimmick. > On Linux mount(8) from https://github.com/karelzak/util-linux says > > relatime > Update inode access times relative to modify or change time. Acces= s > time is only updated if the previous access time was earlier than > or equal to the current modify or change time. (Similar to noatime= , > but it doesn=E2=80=99t break mutt(1) or other applications that ne= ed to > know if a file has been read since the last time it was modified.) > > and this is what i use, except for some noatime mount points > (/x/doc, /x/music, /x/pub, to be exact). > > --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) > > --0000000000007dae3b060e89b695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 9, 2024, 11:11=E2=80=AFAM Steffen Nurpmeso= <steffen@sdaoden.eu> wrote= :
robert@rrbrussell.com wrot= e in
=C2=A0<5f370bce-bcdb-47ea-aaa7-551ee0= 92a7d3@app.fastmail.com>:
=C2=A0|On Tue, Jan 9, 2024, at 05:13, void wrote:
=C2=A0|> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote= :i
=C2=A0|>> So, to me, at this point, it still sounds more than a gimmi= ck
=C2=A0|>> than something really useful.=C2=A0 If someone has a precis= e use case

Email existence checks are in UNIX for many decades.
In fact since 1974-11-26 when Ken Thompson added that to login(1).
"You have new mail" is in BSD since

=C2=A0 Commit:=C2=A0 =C2=A0 =C2=A0Bill Joy <wnj@ucbvax.Berkeley.EDU= >
=C2=A0 CommitDate: 1978-11-05 19:59:54 -0800

It has also been used for almos= t as long to see if log files have changed if you set your MAIL variable to= that. So not just for email...

Warner

=C2=A0 =C2=A0 Start development on BSD 3
=C2=A0 =C2=A0 Create reference copy of all prior development files

in BSD Mail and csh(1).
And today in bash(1), for example, there can be read

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* If the user has just run a program which man= ipulates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mail file, then don't bother e= xplaining that the mail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file has been manipulated.=C2=A0 S= ince some systems don't change
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the access time to be equal to the= modification time when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the mail in the file is manipulate= d, check the size also.=C2=A0 If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the file has not grown, continue. = */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((atime >=3D mtime) && !file_is_b= igger)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* If the mod time is later than the access tim= e and the file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has grown, note the fact that this= is *new* mail. */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (use_user_notification =3D=3D 0 && (= atime < mtime) && file_is_bigger)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message =3D _("You have new mail in= $_");

I would not exactly call this a gimmick.
On Linux mount(8) from https://github.com/karelzak/= util-linux says

=C2=A0 =C2=A0relatime
=C2=A0 =C2=A0 =C2=A0 =C2=A0Update inode access times relative to modify or = change time. Access
=C2=A0 =C2=A0 =C2=A0 =C2=A0time is only updated if the previous access time= was earlier than
=C2=A0 =C2=A0 =C2=A0 =C2=A0or equal to the current modify or change time. (= Similar to noatime,
=C2=A0 =C2=A0 =C2=A0 =C2=A0but it doesn=E2=80=99t break mutt(1) or other ap= plications that need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0know if a file has been read since the last time= it was modified.)

and this is what i use, except for some noatime mount points
(/x/doc, /x/music, /x/pub, to be exact).

--steffen
|
|Der Kragenbaer,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The= moon bear,
|der holt sich munter=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0he cheerfully= and one by one
|einen nach dem anderen runter=C2=A0 wa.ks himself off
|(By Robert Gernhardt)

--0000000000007dae3b060e89b695-- From nobody Tue Jan 9 21:09:55 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 4T8k8j4ZSvz56PLX for ; Tue, 9 Jan 2024 21:09:57 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from glebi.us (glebi.us [162.251.186.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4T8k8h5PRpz4235 for ; Tue, 9 Jan 2024 21:09:56 +0000 (UTC) (envelope-from glebius@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org Received: by glebi.us (Postfix, from userid 1000) id 008416A599; Tue, 9 Jan 2024 13:09:55 -0800 (PST) Date: Tue, 9 Jan 2024 13:09:55 -0800 From: Gleb Smirnoff To: Jakob Alvermark Cc: freebsd-current@freebsd.org Subject: Re: e179d973 insta-panics in nl_send_one() Message-ID: References: <202401062231.406MVrxT002354@critter.freebsd.dk> <202401062234.406MYJ6E004159@critter.freebsd.dk> 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 [0.63 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[glebius]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4T8k8h5PRpz4235 On Mon, Jan 08, 2024 at 10:40:52AM +0100, Jakob Alvermark wrote: J> > > --- trap 0xc, rip = 0xffff...f80d97b78, rsp = 0x... J> > > nl_send_one() at nl_send_one+0x18/frame 0xf.... J> > > nl_send_group() at nl_send_group+0x1bc/frame 0xf... J> > > _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf... J> > > rtnl_handle_ifevent() + 0xa1 J> > > if_attach_internal + 0x3df J> > > J> > > I have a picture of the full panic if desired... J> > > J> > > -- J> > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 J> > > phk@FreeBSD.ORG | TCP/IP since RFC 956 J> > > FreeBSD committer | BSD since 4.3-tahoe J> > > Never attribute to malice what can adequately be explained by incompetence. J> J> I get the same panic, with kernel and userland both installed. Sorry, that was my failure. Fix pushed and now working on a regression test that would cover Netlink group writers. -- Gleb Smirnoff From nobody Tue Jan 9 21:25:16 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 4T8kVS0wP7z56RrG for ; Tue, 9 Jan 2024 21:25:20 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T8kVR67xvz45Cr; Tue, 9 Jan 2024 21:25:19 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Authentication-Results: mx1.freebsd.org; none Received: from mbx19-gwd-03.um.gwdg.de ([10.108.142.56] helo=email.gwdg.de) by mailer.gwdg.de with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (GWDG Mailer) (envelope-from ) id 1rNJb3-0000PO-0D; Tue, 09 Jan 2024 22:25:17 +0100 Received: from [192.168.178.23] (10.250.9.199) by MBX19-GWD-03.um.gwdg.de (10.108.142.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.2.1258.28; Tue, 9 Jan 2024 22:25:16 +0100 Message-ID: Date: Tue, 9 Jan 2024 22:25:16 +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: kernel: fatal trap 12 on CURRENT, when using WireGuard To: Gleb Smirnoff CC: References: <423b62fc-6687-4e56-b8e7-ecaebcadfd7f@gwdg.de> Content-Language: en-US Reply-To: Rainer Hurling From: Rainer Hurling In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-02.um.gwdg.de (134.76.9.217) To MBX19-GWD-03.um.gwdg.de (10.108.142.56) X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4T8kVR67xvz45Cr 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:207592, ipnet:134.76.0.0/16, country:DE] Am 09.01.24 um 21:40 schrieb Gleb Smirnoff: > Rainer, > > On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote: > R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very > R> recent commit. The build and install went fine. After booting with new > R> base, I got a page fault with the following error: > > Sorry for that, my fault. Can you please test this patch? > Hi Gleb, Thanks for the very fast response. I tried your patch and it seems to work as expected. I have a running system, with WireGuard on, at commit main-n267469-0013741108bc-dirty. Many thanks again and best wishes, Rainer From nobody Wed Jan 10 09:42:07 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 4T92rn5CVNz56Q0F for ; Wed, 10 Jan 2024 09:42:17 +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 4T92rn3nB1z478q; Wed, 10 Jan 2024 09:42:17 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704879737; 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=J50KpPzwqGfc3cEQLg6DU5luj35WKDF6tF4TfcynYO0=; b=nNBzSh6urAgopZXZgn86F/vo5qlHaGXmx4+fskqa11gBiyO11St8t6mCq9xxZv382hc/1e fvYlFLvdWQs6gKE2jQRxjU/OR+/dbK8PfFRgUZgGpjV9CHndNwEf2VIAkm9jucw4g2enSy G9f02UUSPZwFM7WZyUzWxHBXSC0FAdCoO7elNhXlkLQ8pHokiTtf6kd9rCG5vRpAuejChD R1Ak1cJOj642T/chptt1M5w/U3XJgxlLMDzgEpDjYY3hjXZZ6ZJ+alsFWLwiFMiAqPx1XC PlCUYI/GIN4MAmGv6IEJCgaUR23xbdhju6v9+bxqc7zg/moJzVpXq4Qk/X5Sxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704879737; 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=J50KpPzwqGfc3cEQLg6DU5luj35WKDF6tF4TfcynYO0=; b=Xa1XDWN3Kxm06k5tqQpf3p28S9ZNd6P24nw/QW3wIjabbZh42rfK7u4wlUS4G74t9QQp11 De6wbgqoDsoI7zJ3acbd0SFQpTbav08IIZpK+plHEE74i/X+Mc/W4rJoXel3lbJdYoXAtM 9inMGf2BxmqXjXqVhvUnaJxbIwEfzciFZlmffdiX1hp4JRLBcc7zE4j3+PawZi3pQdaHB1 DTVEyRkm4Qg/COhzr1ALdTq462E5wXNn4NdE4N9nm9ONVBznqnP/FNrnk4uQgZnidBu5Nv ZcdxFl9LqT//fDrgq+WUrp/XfUokKAkCR73oTkTuKtVr3g+zTERXHLn4oN0G+A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704879737; a=rsa-sha256; cv=none; b=Ns9Uuv35VRKqczSlXkyS62gf1TiEBMlsVb0khPvqiItFnbHfUdZyJV2A1Fc/WYl9Z/p4EO raY/lC/6YuhS9TR0MossT/EES785hFRrZvEFUPd+mCmkA/0BiKlUr9QgivSdKMnH+ohorg Fmyc6kSSsPvbLH6O+G0i3d/8CAekLF7LMbh75CuVn6AeD5hbf5UO2n9//vG/fvyjWD31pG GOz3lYhHdvxPKgX96HtqCl21Wc9vTFtpRoGv+fq50b32Uwp0CnIKcw9dEa2Lzr6hUZEV9m PT+E9zIrG9RUghgoI2cW7vSfbseclu1GGdXgcadB2/MqsD9u6IRvmhUbzgL54g== 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 4T92rn0d62z12Fw; Wed, 10 Jan 2024 09:42:16 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Steffen Nurpmeso Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 10:42:07 +0100 Message-ID: <2367131.USjQqFH40Q@ravel> In-Reply-To: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> References: <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> <20240109174318.MCIB6yhn@steffen%sdaoden.eu> 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="nextPart3074382.Ovca90QLe3"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart3074382.Ovca90QLe3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Steffen Nurpmeso Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 10:42:07 +0100 Message-ID: <2367131.USjQqFH40Q@ravel> In-Reply-To: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> MIME-Version: 1.0 Hi, > I would not exactly call this a gimmick. I wish I hadn't used that term since it attracts too much attention on itse= lf, making people forget it was part of a sentence that was quite balanced = and seemingly altering their judgement. I think you're confusing the need and the mechanism (or implementation). I= n substance, we (Robert and I) were talking about turning "atime" off *by d= efault*. What I tried to convey is that the needs that justify this mechan= ism are those of a minority in my view (and I'm certainly not opposed to be= educated if it's not true), and additionally that the "atime" mechanism ad= dresses these needs poorly. With that in mind, developing "relatime" to try to alleviate the shortcomin= gs of "atime" has a low ROI: It doesn't add the crucial functionality most = needs (like auditing) would require and doesn't even really address the I/O= shortcomings in some frequent scenarios. Deactivating "atime", by contras= t, doesn't require any development, suppresses all I/O overhead, and doesn'= t suppress any functionality for an overwhelming majority of uses (at least= , this is my current view; other inputs welcome). I did not say that the needs themselves are a gimmick, e.g., having a notif= ication of new mail (although, in this case, frankly, I'm on the verge of a= rguing it). Simply, relying on "atime" (or "relatime") for this is unneces= sary, as you must have understood reading the various previous answers in t= his thread. > On Linux mount(8) from https://github.com/karelzak/util-linux says >=20 > relatime > Update inode access times relative to modify or change time. Access > time is only updated if the previous access time was earlier than > or equal to the current modify or change time. (Similar to noatime, > but it doesn=E2=80=99t break mutt(1) or other applications that ne= ed to > know if a file has been read since the last time it was modified.) >=20 > and this is what i use, except for some noatime mount points > (/x/doc, /x/music, /x/pub, to be exact). It seems that the other answers (mostly those of Robert IIRC) have shown th= at this manpage text isn't up-to-date with current practices. Which need(s) of yours are you trying to address exactly by using "relatime= "? Thanks and regards. =2D-=20 Olivier Certner --nextPart3074382.Ovca90QLe3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWeZm8ACgkQjKEwQJce JifVYQ//X8bK0vxCXlaDS8NaF6oBkhMUmOeuQtGiw0ZOBQUTyE016Q5J5eoQwEbr rMwRrcFW4T6WJdT5AjBLzpP1GoNRmYTh9DstpHkSbqEAkOFhkZYtIpR3Ju84J6d4 CHhgYunI6J4RlJcfi/f+kzvHFNmtmm2OH5v4kuOC4bz99M/Go32y3g6fXYX0xmWf 3H/Cu4KYpBB7VSaWQmiXHCTSkX2bsvZfmgbaj72vGpLMpny9OiMlUyqZt1Y3OClv jNkG/jaFHYYfKnHw4rcu3/rXMikq7lWqJsYhgGUgQg3nzYD/XFNjotW3Ja1btSK7 UWE7YIQW0CKauwobtd+FXkPxD3AIszhyVJmR7RAPdcoyJAz+dF2dq77OyBAT1bxC ceFrQpf47ZLe4eq1z7wAPyo0iEu6KCtGo5YdyURC7/4y3kcoaR9v4cwAhaiK9mRA T4aUUNpxMwfCI4C6PxS30yxy9nmy5fy7L7Yp1K1arj0mGacfO6AkpVEW1bBmWTuU uj6sHSxjTp/rfJPrA2UtxsqTWMN281WghBIcQsHknpAzLrjtv1o+/h4g1np2ehFs 1SjyIR+aOfDWdekeyveROlNLHclo2DbbQgncBZ0fgAFmCfLh6oqNZfWtnk6i1kTz mbg3HE/wpmFL/OjcGFsumOa56wPbUMf690yiCh5ME5wuHR05grw= =tguU -----END PGP SIGNATURE----- --nextPart3074382.Ovca90QLe3-- From nobody Wed Jan 10 10:01:48 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 4T93HS3hgrz56TDh for ; Wed, 10 Jan 2024 10:01:56 +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 4T93HS39Mqz4Clg; Wed, 10 Jan 2024 10:01:56 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704880916; 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=I5HgIPBKUxMe25Z/gVqLSUyYorEMi8a43kxe2h5HBTU=; b=nL2GxBYgDCuu0meJQIFTWBWHLTGop68r/Du/A8xFSSpdUa/31PoMn/2cuxlMWgBRvc6E/Q 3Bmdn+SKxbUmpqEL70sX5ebtfElERF/n6zQaDKEnnRZBnzjxESHhsUY3iXdC9YPKUjIofG QHAPLOtBXqZ7pyUlzcIIbxPj+gOfzoRhRNActCoWl9oaZdb87SrH20CAhM/DZyNSACBIFx WgnkcWlxy6A8m7ldQ9AF0XK2qW7/EH52j3rBezT09Lck2FLJfC8zsu7DFWdi8jRgAq5782 ecIy3ABB3iwHd00Ok2RTehpVbVtue6R7TTt2MMoL/mJbAurO7SGHzIcDIUIGUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704880916; 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=I5HgIPBKUxMe25Z/gVqLSUyYorEMi8a43kxe2h5HBTU=; b=JhK081cQUH9xAKrvLIaiXfImA/1pgslxn8dg/ttbfttIUDOAM8Docs8O8xc2WJ+cFO6VXv e5XxNB8rG1bQX2+hlcxaHBViLcnRuT6oRt5+LOOm+g1DXSntXzwMZS9Mo7KjZQT6IQ81Gp AlLyj08E8yE68nHOKo/srFxcTM4TyAtMFyF3WNRaaHr29o1Vc0I5a5C3HLphFOadpY6DFK 6L5DFZLN3Z3guLKx7z4dt0kqd+fKrSp88KWBqAiurHeCSAmxjb4O2wwjyXEETi2GRENvRD 94S876gq+AIy53xM5/aKmqcP5o2vNKLGelFbuCaClodYHVEOgHnDrlLSzmPQHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704880916; a=rsa-sha256; cv=none; b=VY2hFNx/nilBUBt9lK4Bmb2B7gptzwNFRJxfLH++x2x51S0s/7UcQb+ay/naXkGkHr5Lr1 K4KmDRPNx/ocERquzelIAgenDdcupKET349f/qcvNZjuFKb8o9R4hp9tJUbyuoDoYHr5Y+ vLhmdP5cx3dEfP4O04hDd7YatbWNjbpGxcN1RFdRo3BY/8GxM508NcVSYft7WHCQgkkLIm Jy3/L4HnDHoG20CPgrn0ey4L+SG3lFUUxdnWyltRh3UVtH5+PGAdC425pbn4Ej+WCbn3zs 9NbvduFF2jBeLXJOltvsl6nWKJRpZmJJPvtDDLN7X3XL0W/BMgceZ0C35OyO+w== 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 4T93HS044nz12G9; Wed, 10 Jan 2024 10:01:55 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 11:01:48 +0100 Message-ID: <1749331.ETpRK2a2Mi@ravel> In-Reply-To: References: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> 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="nextPart1841664.CR9iXFMSmR"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1841664.CR9iXFMSmR Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 11:01:48 +0100 Message-ID: <1749331.ETpRK2a2Mi@ravel> MIME-Version: 1.0 Hi Warner, > It has also been used for almost as long to see if log files have changed > if you set your MAIL variable to that. So not just for email... This seems to be an example in point of a "niche" scenario, both in terms of spread of usage (even then) and the fact that it's easy to get the functionality by other means. Again, I'm not opposing anyone from working on "relatime" if they personally have a strong need and motivation. I'm not even asking for removing the "atime" functionality, which can have its uses. What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*). And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same. So, if it's not the case, I would be interested in knowing why, ideally. Regards. -- Olivier Certner --nextPart1841664.CR9iXFMSmR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWeaw0ACgkQjKEwQJce JieiqRAAuT3ztiQXOw+PtQAzMaXXuwXQSuiROjy9SYiaLQ4Zd9mNm69RqihOqEap bD0E85RjnnpHSWWuhmxh9Q1Ne28042wVo4H2biQ3L4KDRbefT9+m/GwimnET8N0y Tm9DI5Cwk/Ac73OlBnub2jVfnZPdRDdG6nmPHTzDFDl00NoczvLT3pswFatpFlbZ 9ywK6yVsXXv1ZLM161v+giZW9oB+0cK7dTnraXt07a2e/tiTQZ0LQCACtktwcwbG e3QB0yDJOIW54Auns6KMw/SvH28pt47v6Mjc4d9rE/dh9zHzmVC8SHgVTfVx/76n BknglibQkvS/kzmIxNW9kpR+F/5kyr6xtFDiL4lIm2Wh9djO4eZ2p6ds2He86JRG VQiaJWWViUfG4AHaMJcLYGKuoX7VtgSnt03IBmhlk1EUetgPwrwxlBHirCg1zVux O0upaX/oCRAUBZ6dWYTljVq0u8Zr4IeRO6Xd6KcqI7DVzN2CrIgJKPY4htS4NMEo sm9DIjcSV+tR5JLCjNI50+kedyTnsir2JT9l/empNMdeDRMRcocJIoePjRXZvy6U /zQDR/3ZgW6w+46N0pNrIIifisGVRMdXLgNxrHQ+PzTVa2Eyc3/PZEhI7BNjyCAu kDhqiPEwH/bP+G+80qkasGK/lIM1HjO2hSDE5BboGkj5lZyFxts= =+ifL -----END PGP SIGNATURE----- --nextPart1841664.CR9iXFMSmR-- From nobody Wed Jan 10 12:13:36 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 4T96CZ4qR1z56pNn for ; Wed, 10 Jan 2024 12:13:46 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4T96CZ329Kz4VPb; Wed, 10 Jan 2024 12:13:46 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; none Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1rNXRQ-000FYo-0M; Wed, 10 Jan 2024 13:12:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wRzpybALAoss8K27JUBWyhUouI5R/fTyoQFMvW2IF7k=; b=mz4c5d1q3xW6N4UJGD9dtApcsL ROyRtBEUrfu1yvFrf2NALqoE8hIW2LyXcZOgLL+Gh0ShdJIlaQS4begHOR1drDtSKCsk/kKsXvFVi sgqNNf+3YF0l15bySECc7s/XXwJRLzup1DzalDeTcTRV3DP3J94RvEd0kAddmRgnykT2VPzd/MIiX nGKy3SF1qeS+0EIlMSUNZlBPr50yfQl2cUkL9GZWUjaRfQifsmC/5aN7QI4UpMlgBbIAZQFzci42T qDgW6njSd+nbkbVp1Bm+GGElOw/awHlT1GUJJCeJ0c7qi8ilGNLFpfZthQvBQlrwsJaF9emQIxw+K 8cIEKrhA==; Received: from office.as33885.net ([84.55.65.101] helo=[192.168.9.201]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1rNXSj-000L6n-53; Wed, 10 Jan 2024 13:13:37 +0100 Message-ID: <34945185-0de6-4cbd-91ac-dc895ecbbe60@alvermark.net> Date: Wed, 10 Jan 2024 13:13:36 +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: e179d973 insta-panics in nl_send_one() To: Gleb Smirnoff Cc: freebsd-current@freebsd.org References: <202401062231.406MVrxT002354@critter.freebsd.dk> <202401062234.406MYJ6E004159@critter.freebsd.dk> Content-Language: en-US From: Jakob Alvermark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4T96CZ329Kz4VPb 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:34971, ipnet:185.34.136.0/24, country:IT] On 1/9/24 22:09, Gleb Smirnoff wrote: > On Mon, Jan 08, 2024 at 10:40:52AM +0100, Jakob Alvermark wrote: > J> > > --- trap 0xc, rip = 0xffff...f80d97b78, rsp = 0x... > J> > > nl_send_one() at nl_send_one+0x18/frame 0xf.... > J> > > nl_send_group() at nl_send_group+0x1bc/frame 0xf... > J> > > _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf... > J> > > rtnl_handle_ifevent() + 0xa1 > J> > > if_attach_internal + 0x3df > J> > > > J> > > I have a picture of the full panic if desired... > J> > > > J> > > -- > J> > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > J> > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > J> > > FreeBSD committer | BSD since 4.3-tahoe > J> > > Never attribute to malice what can adequately be explained by incompetence. > J> > J> I get the same panic, with kernel and userland both installed. > > Sorry, that was my failure. Fix pushed and now working on > a regression test that would cover Netlink group writers. It works now, thanks! Jakob From nobody Wed Jan 10 12:27:33 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 4T96Wg10QPz56qxt for ; Wed, 10 Jan 2024 12:27:43 +0000 (UTC) (envelope-from SRS0=OkgR=IU=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4T96Wf23tBz4ZLT; Wed, 10 Jan 2024 12:27:42 +0000 (UTC) (envelope-from SRS0=OkgR=IU=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Wed, 10 Jan 2024 13:27:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1704889654; 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=gUtdUZglcdXuxjli1fQr/XAFNVqevgWr1qdVpPDkoiE=; b=F/s4W9yewdRuU2XUlPnLRxxhzxKwEDKdXkkwymjCV8b4DK4WIuyEgBzJWH5usCBMC9xnBK ks4X9v6PK4SwazAc4tH0gMwf4EOD2CIS9sXcoDOJe3rnpDmVP0JSSehfdo+DclpcqHEEj2 KTikvNgQpQizdxW8mQkMQQzQ8DEdpCDKfD4XXfxEBN2jiJkN2avFKwLHFKFcAx0OgePHzt xFaA1JdjYOEQ66Ukk/jhld8PuCfVJu0kabOGcAJRrEVy+nlPyKQaL8+aaj1/9N5ggDSrtz Uef8bVvxaoi2POR5DopYy4CXydNl9z6SMPqNBILVblgdh+j9jixM5uBlkDTgYA== From: Ronald Klop To: Olivier Certner Cc: freebsd-current@freebsd.org, Warner Losh Message-ID: <1115024984.4580.1704889653735@localhost> In-Reply-To: <1749331.ETpRK2a2Mi@ravel> References: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> <1749331.ETpRK2a2Mi@ravel> Subject: Re: noatime on ufs2 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="----=_Part_4579_969573456.1704889653729" X-Mailer: Realworks (684.61) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4T96Wf23tBz4ZLT 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:3265, ipnet:194.109.0.0/16, country:NL] ------=_Part_4579_969573456.1704889653729 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Olivier Certner Datum: woensdag, 10 januari 2024 11:01 Aan: Warner Losh CC: freebsd-current@freebsd.org Onderwerp: Re: noatime on ufs2 > > Hi Warner, > > > It has also been used for almost as long to see if log files have changed > > if you set your MAIL variable to that. So not just for email... > > This seems to be an example in point of a "niche" scenario, both in terms of spread of usage (even then) and the fact that it's easy to get the functionality by other means. > > Again, I'm not opposing anyone from working on "relatime" if they personally have a strong need and motivation. I'm not even asking for removing the "atime" functionality, which can have its uses. > > What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*). And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same. So, if it's not the case, I would be interested in knowing why, ideally. > > Regards. > > -- > Olivier Certner > > > > "And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same." This is an interesting type of argument. Ronald. ------=_Part_4579_969573456.1704889653729 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Olivier Certner <olce@freebsd.org>
Datum: woensdag, 10 januari 2024 11:01
Aan: Warner Losh <imp@bsdimp.com>
CC: freebsd-current@freebsd.org
Onderwerp: Re: noatime on ufs2

Hi Warner,

> It has also been used for almost as long to see if log files have changed
> if you set your MAIL variable to that. So not just for email...

This seems to be an example in point of a "niche" scenario, both in terms of spread of usage (even then) and the fact that it's easy to get the functionality by other means.

Again, I'm not opposing anyone from working on "relatime" if they personally have a strong need and motivation.  I'm not even asking for removing the "atime" functionality, which can have its uses.

What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*).  And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same.  So, if it's not the case, I would be interested in knowing why, ideally.

Regards.

-- 
Olivier Certner
 


"And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same."

This is an interesting type of argument.

Ronald.
  ------=_Part_4579_969573456.1704889653729-- From nobody Wed Jan 10 13:37:38 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 4T984W6qGBz56yfx for ; Wed, 10 Jan 2024 13:37:47 +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 4T984W5z27z4jtf; Wed, 10 Jan 2024 13:37:47 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704893867; 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=g+V7B5i9vooQgWTSpOg1XxsgBKu30eHzSyS7A7wY4Ys=; b=hh2/qVnYqZvaLXQ+ddblwqYIzBU2cR29fhVHoaUeLo5ZdksS4hZkZjfkcP3QtvS+5pdPzf aIHCmlLfo6U6XHc4cYtUz7fkomMMN48NUYKScmJWnr2fnE/5/bbhHlTMIsiRGbPUznKSSy VigleGdrZN5uFWqxrHT4hFhnfSvDPvEjOwkGEI5m/MTfJUVzaiOoMxZv/UR8t14rChvGhe jBUbYGm2TjDdVFfm8WC2ZA8so/dLFJ3gnUZcaWDTMeeskddpO4+6I0gUmmcqLcGjMNpTlF nzT25rqc8FF5IXB8W4HQm18I8PTPLmjT6vmugCDxhA0D37RpLR8/+lDRSaq0Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704893867; 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=g+V7B5i9vooQgWTSpOg1XxsgBKu30eHzSyS7A7wY4Ys=; b=ps5b980a2zrrEHuWQRskBCJzdqgEkH62l8aMdBV6w2LFTtZaHbTR2pJUUjBB+eaZdYFx5D kIT7APCKJZ33w3gjmmCLk+bgx1CeRsBmF11iD4/UKUz1RUkknxasZcEJBbkF5mam3iaMnU XryiPgkPi1FRd8k392QRim8U1h+fGK9KOs6KPJf/B4s1lyP1Fh05vc76PP902IFpPGLpl3 lC30VnvuIXmeaWxuSYM4Rbet34hJVIY/lIEkXseRcvFn0gQiSM0M6Rzf4cDYA2wCXgfqgE 7aTxOUdEhyVKoi7qWmp+FwOgPQrQWS9Jtqn3rh6O8qwGMI25feQOJePPEx8O9Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704893867; a=rsa-sha256; cv=none; b=qd4RXUlP/JUcllT73dUiU/dnjwFfu+iX6JFRrm+amddOY9FfZat+G8ji2bBkFd+pAIFBBS 3xweJ5RQ+AXzZ0VQYsWthsE4rTx8fg5iy7lrElN3+YkHa2G+IAQGFmq4DgjSk6PJA/55zS 7czN4JPx4u0/a5Cv4g+ZEO9mn22o4VuAa1XDBAHgbxDTCuhscw4fliKzTTKW570krGpevj QxNDvGPxcTn/CNkCjeJXI1cpPYg2hrz1mvpU0pMyXme24sDQOV08Ll93LMDlnDE/vNeh5h 5xeTns8w7ryKGNOTAottp3GKJPAISQ8WDXPHlep3es2OhfzoK4nU0mSKGVcWwg== 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 4T984W1qV7z157D; Wed, 10 Jan 2024 13:37:47 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Ronald Klop Cc: freebsd-current@freebsd.org, Warner Losh Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 14:37:38 +0100 Message-ID: <4818611.VoHcWa03dc@ravel> In-Reply-To: <1115024984.4580.1704889653735@localhost> References: <1749331.ETpRK2a2Mi@ravel> <1115024984.4580.1704889653735@localhost> 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="nextPart1710837.75zdUjLvPh"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1710837.75zdUjLvPh Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Ronald Klop Cc: freebsd-current@freebsd.org, Warner Losh Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 14:37:38 +0100 Message-ID: <4818611.VoHcWa03dc@ravel> In-Reply-To: <1115024984.4580.1704889653735@localhost> MIME-Version: 1.0 > This is an interesting type of argument. Except this is not an argument to the main discussion, as apparently you haven't understood? This kind of response is disingenuous. Either you said too much, or you didn't say enough. -- Olivier Certner --nextPart1710837.75zdUjLvPh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWenaIACgkQjKEwQJce JiemeBAAsb18Lh4rebeHnxEpl08yyCFP4WgnhwLpOK23uTmEv1WWlZJx0MIZyDBx +Co/kSiQMtc+s338TvKPf5bmPHNwAZJUlzNGsxd4HzWe9mkjybHCsu9dl5NMeB4S ZTE7MuFl4pcNhYXCKX6kzm9r0rzPUKWyGrJ6WSjfbsxExFwx7JW7jFqhygmd6TFE LBSZlAdFVKYNfcMnPg9Y+CLmhgjbBErA04XvrzjPpq8uF9GwlhiD4j1FKvWsurJF hQK10sMkdDqj27ZARkxFMwO9I9bzFxbf/2W8RZuB3my9p0Bsn0o8hJK1FbvWTjEQ 0XnZ5zc+oNHuHvXrSNm3mPR9TKhLvdUTxE4F4Fn/2LQ7P8SVw28VWxkhfCSou2ar cyApg5vs2w5I/2A18hPN+n18pznHu9X/+GiEDJLNqYAzaQ/18iPMrpiiOLD+/k4y tXAwy1kufg47tym8TER3ajOAME1zNIYReEZsnNWzsotsRRRCX0qmLRNkulDl78MO XQbr72Lxg/hmXdNlNVYTldEUaukdJ5qpLPQibinizGRjxGVP/flCJo1ttzC4k0iO oNKT+cUuqERKvUioj1i+2mfkFfTDPeUf/6l+QGXL05p/ACYpJAC+JygL2jwLpfuF NrKRXd2byrjp4nTHpjZQgWxeL1p6M5hXAZlKRG2+zHtoxKNBTIY= =dwR8 -----END PGP SIGNATURE----- --nextPart1710837.75zdUjLvPh-- From nobody Wed Jan 10 14:41: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 4T99ZP3092z576VQ for ; Wed, 10 Jan 2024 14:45:17 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T99ZN43w7z4tWc for ; Wed, 10 Jan 2024 14:45:16 +0000 (UTC) (envelope-from naddy@mips.inka.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of naddy@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=naddy@mips.inka.de Received: from mips.inka.de (naddy@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1rNZpI-005z2R-Qc; Wed, 10 Jan 2024 15:45:04 +0100 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.17.1/8.17.1) with ESMTP id 40AEfFtg079764 for ; Wed, 10 Jan 2024 15:41:15 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.17.1/8.17.1/Submit) id 40AEfFb7079763 for freebsd-current@freebsd.org; Wed, 10 Jan 2024 15:41:15 +0100 (CET) (envelope-from naddy) Date: Wed, 10 Jan 2024 15:41:15 +0100 From: Christian Weisgerber To: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> <20240109174318.MCIB6yhn@steffen%sdaoden.eu> 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.09 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; FREEFALL_USER(0.00)[naddy]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[inka.de]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4T99ZN43w7z4tWc Warner Losh: > It has also been used for almost as long to see if log files have changed > if you set your MAIL variable to that. So not just for email... I've also used it to check when I watched a movie. Not a serious usage, but since it is available... -- Christian "naddy" Weisgerber naddy@mips.inka.de From nobody Wed Jan 10 16:55:40 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 4T9DT61Lxnz55N0l for ; Wed, 10 Jan 2024 16:55:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4T9DT535Mkz3xlh for ; Wed, 10 Jan 2024 16:55:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5572a9b3420so9159886a12.1 for ; Wed, 10 Jan 2024 08:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704905752; x=1705510552; 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=oJS2ZHb7Ufva8WkIJ6uaco7UFqBj369UYUBAXCyR7S0=; b=GwVBMFyE2WpvphNfigntSyCpy+eOFFJAI3RlQoh804RhvxZmbNbPRw2HLtNQuwY/C9 5L+Tr6qnZGHYSX5cRB/uMrSxmDjJhOKGVmulhe1QBz9c4LiTOEPSBR1MkPS0/qIIV9de BrQLK0Y9d/MtNU2erCArTlTpU0s/ERtCo4N5aHAMIPmsVo0C8jo+eLXnXjGFlX0pu8Cg 6uve61+JaJ04z4UgMtU/9bj+zn6hcOiaXjdi5EG3TuhBzT1TWpKeD4QSgyGzbUAoyjEv xGWy5soOEOjOnkChG/APGCpcnLnXTO+v7eAth5Vdye5i2aK3BJSxUKCRDDkAnEYNpams X7Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704905752; x=1705510552; 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=oJS2ZHb7Ufva8WkIJ6uaco7UFqBj369UYUBAXCyR7S0=; b=UY0GmZX+/QY6/IvSb/dPtd/A0lX2SR2MFUCenixiu1r5PEeYj1jA2nugK1Qzd1LdQ1 A58/tHxX7idn5zxvfHee35BvdZas/WE8O00uU3J+MACHyJ4WgvoFOHW/N7vh85Pod+Mc DhP+o7MGzyiBFZYK6UngnefyH5t1zUAE5g0YsMVWRD9MBpvdma259ZbpVv/aYftlKg46 kEinDIjdAOMwttd91IlO7o3Mqj7D3iJXMCkHSbzckciuw5/gIVpLTMxzwZAAfmWCsne8 xWSFV5at8+2NSZf7XTfN+gkNH/L6Y2QQLCPe9huz/FvXRMuAWH+Zzn1U2XwxiGJ4KTaN rUPw== X-Gm-Message-State: AOJu0YzwdSfLK7s+zJ8dgdujjqrxLlL4UFGs1O2zDDqfNhbx5ehF1nVs N/ARdrJHBZ6abqzR6Mp/p5EKB3/nn+60Y0NYG4jBK0s6NBKUtCEDe/yJpxhmtf4= X-Google-Smtp-Source: AGHT+IGd08KPNBYdqtBjVPeVlBumbHcx5icyh6NQ/smOSG+e+jbWYoQrLlmKF8DXCieLSs3RLzawLVWu3XrPKgeA7JU= X-Received: by 2002:a17:906:d7a8:b0:a2a:c113:2677 with SMTP id pk8-20020a170906d7a800b00a2ac1132677mr356100ejb.61.1704905751808; Wed, 10 Jan 2024 08:55:51 -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: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> <1749331.ETpRK2a2Mi@ravel> In-Reply-To: <1749331.ETpRK2a2Mi@ravel> From: Warner Losh Date: Wed, 10 Jan 2024 09:55:40 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Olivier Certner Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b65b7e060e9a4da5" X-Rspamd-Queue-Id: 4T9DT535Mkz3xlh 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] --000000000000b65b7e060e9a4da5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2024 at 3:01=E2=80=AFAM Olivier Certner = wrote: > Hi Warner, > > > It has also been used for almost as long to see if log files have chang= ed > > if you set your MAIL variable to that. So not just for email... > > This seems to be an example in point of a "niche" scenario, both in terms > of spread of usage (even then) and the fact that it's easy to get the > functionality by other means. > Yea... tail -f does it too... But this is a useful way to get your shell to tell you when something has changed. It's a widely used trick (or has been in the past). But it really has nothing to do with atime... Just a clever use of MAIL variable. > Again, I'm not opposing anyone from working on "relatime" if they > personally have a strong need and motivation. I'm not even asking for > removing the "atime" functionality, which can have its uses. > Yea, relatime has some interesting use cases: Is this binary / library in use is one such case. The fact that you've completely omitted that use case suggests that the analysis of atime's usefulness (or its lack) is at least incomplete. > What I'm saying is that, based on others' input so far, my own (long, eve= n > if not as long as yours) experience and some late reflection, is that > "noatime" should be the default (everywhere, all mounts and all FSes), an= d > that working on "relatime" won't make any real difference for most users > (IOW, I think that developing "relatime" is a bad idea *in general*). An= d > I think this is a sufficiently reasonable conclusion that anyone with the > same inputs would conclude the same. So, if it's not the case, I would b= e > interested in knowing why, ideally. > relatime would work great on /usr/local where you have a lot of programs: you reduce a lot of traffic. It's quite useful to know what packages are in use or not based on when they were last accessed, not just last installed. I'm not sure this is a great notion to have everywhere. I think your analysis needs more inputs. Warner > Regards. > > -- > Olivier Certner --000000000000b65b7e060e9a4da5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 10, 2024 at 3:01=E2=80=AF= AM Olivier Certner <olce@freebsd.org= > wrote:
= Hi Warner,

> It has also been used for almost as long to see if log files have chan= ged
> if you set your MAIL variable to that. So not just for email...

This seems to be an example in point of a "niche" scenario, both = in terms of spread of usage (even then) and the fact that it's easy to = get the functionality by other means.

Y= ea... tail -f does it too... But this is a useful way to get your shell to = tell you when something has changed. It's a widely used trick (or has b= een in the past). But it really has nothing to do with atime... Just a clev= er use of MAIL variable.
=C2=A0
Again, I'm not opposing anyone from working on "relatime" if = they personally have a strong need and motivation.=C2=A0 I'm not even a= sking for removing the "atime" functionality, which can have its = uses.

Yea, relatime has some interestin= g use cases: Is this binary / library in use is one such case. The fact tha= t you've completely omitted that use case suggests that the analysis of= atime's usefulness (or its lack) is at least incomplete.
=C2= =A0
What I'm saying is that, based on others' input so far, my own (lon= g, even if not as long as yours) experience and some late reflection, is th= at "noatime" should be the default (everywhere, all mounts and al= l FSes), and that working on "relatime" won't make any real d= ifference for most users (IOW, I think that developing "relatime"= is a bad idea *in general*).=C2=A0 And I think this is a sufficiently reas= onable conclusion that anyone with the same inputs would conclude the same.= =C2=A0 So, if it's not the case, I would be interested in knowing why, = ideally.

relatime would work great on /= usr/local where you have a lot of programs: you reduce a lot of traffic. It= 's quite useful to know what packages are in use or not based on when t= hey were last accessed, not just last installed.

I= 'm not sure this is a great notion to have everywhere. I think your ana= lysis needs more inputs.

Warner
=C2=A0
Regards.

--
Olivier Certner
--000000000000b65b7e060e9a4da5-- From nobody Wed Jan 10 17:36:26 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 4T9FN54LNCz55SVd for ; Wed, 10 Jan 2024 17:36:37 +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 4T9FN53phYz449M; Wed, 10 Jan 2024 17:36:37 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704908197; 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=L/ubnpWSUR1TCeaE3Tlp35X+XVG9kVm1A5uuWWVvKZg=; b=j8ZjSrusbOOpxOFO+ZifYTPVWOwzL2S3QQT94/geJBi4scnNuikn/bAUKeueLWpgLupMrA I3WwbDV1WGTuJTb6oW9KdhAOJ6Qk5sq3OICwBeRb7ZNcR84V1ss6JQPeBMdenyQvr8o0fa thCjdqsUCkD27g6fTMPp0GYA8yGWH5vlU//ZbdWI3C4mK80JrkQM3IUxoGLQUWT1BzyUPA rq39mvt4SdJ5DzBFZ9ijxOm92M51VsRxiNeCwEQ+cS7m1Fc3oLnePnKmiNUGLYsK7jrGRO K1PVRLdNf0/Tw0R6CJO9Zz0TM8FR/yNCZSMHXg2mg/G4OBLkvVb9QxTgb60+Kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704908197; 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=L/ubnpWSUR1TCeaE3Tlp35X+XVG9kVm1A5uuWWVvKZg=; b=eeN0vVh0Z5GmbbyT73c2TH6mLr0ugFbDxMjJd5zecPlkHnBmWMYj/FQSIvStPC2f2YRjfU BQvZEPbP7AniOudsADBiVAxjBgR7cEU8Jm9rswfN6Xb49TqhyoRWtOltOsGjAD+DJ9Pzon WwcBTBPRAdk+zCL7w9C11B5n0hA0BDNW9oRT+t0+xw66NVHcbiWiYJaFZg+fkZCBRS4sdn Tr5xh702bK3kV86i/SF8jn7jQqD2OpkVTV+/baFeMEplUKJq4xRxDuPpJi6wi4RkgzABy2 NzRRDKzxn3y/9ky+h7i1iT+lgVs24A849XZ/dnRlBqzdTc7OWJLUSbSv5tO/Zg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704908197; a=rsa-sha256; cv=none; b=GOpCA0eSYtw0eUREFPUTinFAMwE4fypOd+iWhbMsJxo7LhqxKVAtJCaW48q1Kjv9I4QTF+ MalRLsOInrgYad1MpIpvCR7T/YOORiK1pwabxy7L1sS6AKbppYUgOcq1OnHRdHIwpbJBNI H/hCU8s0X4aPIWupdkdu465Vq8eu8o4hpmrdAm4wsVxio2zGbwZ2iAY4Vqe/3b58UbfGw2 g1NCoBt/vW9MGx9cQnSIel9wQVA74i+HFb2RWZV7G3r+Q+7nOHvprylaQqVw66E6ZEm7Yx 3uVb3UhDSDRPMN09wj37sIs0Qi4XkS+eSF4/NNflOtBKM1BbTeGKoYuw2P0i7Q== 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 4T9FN50TkYz19w7; Wed, 10 Jan 2024 17:36:36 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 18:36:26 +0100 Message-ID: <2136329.mxFCRLsXLg@ravel> In-Reply-To: References: <1749331.ETpRK2a2Mi@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="nextPart32170606.pBcpzhPnll"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart32170606.pBcpzhPnll Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Wed, 10 Jan 2024 18:36:26 +0100 Message-ID: <2136329.mxFCRLsXLg@ravel> MIME-Version: 1.0 > > Again, I'm not opposing anyone from working on "relatime" if they > > personally have a strong need and motivation. I'm not even asking for > > removing the "atime" functionality, which can have its uses. > > > > Yea, relatime has some interesting use cases: Is this binary / library in > use is one such case. The fact that you've completely omitted that use case > suggests that the analysis of atime's usefulness (or its lack) is at least > incomplete. Yes, but I never pretended to have completely analyzed the usefulness of 'atime'. See "which can have its uses" above. But I think there is already enough matter for the case of the *default value* for 'atime'. > relatime would work great on /usr/local where you have a lot of programs: > you reduce a lot of traffic. It's quite useful to know what packages are in > use or not based on when they were last accessed, not just last installed. Both the examples above prompt some straight objections on the current usefulness of "atime". First, unless you've disabled building the locate database in cron (enabled by default, on a weekly basis), access times on directories lose most of their usefulness. Second, if using an IDS, I'm afraid it's just game over. And even if you think you are not, '460.pkg-checksum' at least is readily there to much complicate, or even prevent you from, getting package usage information this way (it is enabled by default, and on a daily basis). The general point here is that a single access time is inherently fragile to interferences by multiple applications for multiple reasons. > I'm not sure this is a great notion to have everywhere. I think your > analysis needs more inputs. May be, but to me the case for the default value debate at least seems quite strong already. Regards. -- Olivier Certner --nextPart32170606.pBcpzhPnll Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWe1ZoACgkQjKEwQJce JidVlg//efD7QEQ3qNVQFre2IW8n0Jh+zk3qcLNmMZUQko9z63maih53V4YdIQ0v 4rMFZIO3/8/h8bKebkCjvQl5R8DNUc9zFPJmPps0rVVcZf6KLyItLuwZMOxSbtzA 5EmRR6Hi95hKSP8ssD3ttZX2fgOdxnH9CtHO8d8pSz827Vxg1rMxQLo/wq5u7L8Y 6qhM1N9V3Fbcumw1fGJZP03hTtyme0tLsWZwT/p93HxTpxmPYBeeSbhvOteT3RjW GcpspUxn3jClgg+ttDDqe8HZbzND0skaajeZmJwk1ju6EzFPkLafoeOHnsATWUbF ilK+WSUrZJPG9p9sAUy1GSHacqE7CIXVWLeZeeB16KbToFBd1BN70C+GXoyeJbXj +g8YVr9wxzwoufLKX8kZUDrQh4BV4/M3UA+TMIKimG7mrHWCPmwyllwNOt8rNuw2 cl8BUV7ZmRp2esLHk3/+ESU7xu9ODN5WONUOn5vm4rtqLjX20bPCm9uK65lG9D05 bDORpugXaD2hLi9hzDq3sPtgRdiXV7A2Lm3dvVincn86wqpLHHRj06muqgFZ/54R RXAHf/TVaAwQcvJslsszosnen9uXnTm7FGFIof3uhYoTBg+aqLsu1F8bTP7EUonv 6mJV1Rw+YH6BhrK3KZNAd0XHal895/l8jge59OtscDm9bVklLj4= =GIKt -----END PGP SIGNATURE----- --nextPart32170606.pBcpzhPnll-- From nobody Wed Jan 10 19:12: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 4T9HcL3W5Mz55gZl for ; Wed, 10 Jan 2024 19:17:22 +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 4T9HcK5JPTz4SyK; Wed, 10 Jan 2024 19:17:21 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none Date: Wed, 10 Jan 2024 20:12:15 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Olivier Certner Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Message-ID: <20240110191215.fTrYqOW3@steffen%sdaoden.eu> In-Reply-To: <2367131.USjQqFH40Q@ravel> References: <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com> <20240109174318.MCIB6yhn@steffen%sdaoden.eu> <2367131.USjQqFH40Q@ravel> Mail-Followup-To: Olivier Certner , freebsd-current@freebsd.org User-Agent: s-nail v14.9.24-588-g826cef48a3 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. 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-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T9HcK5JPTz4SyK 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] Hallo Olivier Certner wrote in <2367131.USjQqFH40Q@ravel>: |> I would not exactly call this a gimmick. | |I wish I hadn't used that term since it attracts too much attention \ |on itself, making people forget it was part of a sentence that was \ |quite balanced and seemingly altering their judgement. Sure. |I think you're confusing the need and the mechanism (or implementation). \ | In substance, we (Robert and I) were talking about turning "atime" \ |off *by default*. What I tried to convey is that the needs that justify \ |this mechanism are those of a minority in my view (and I'm certainly \ |not opposed to be educated if it's not true), and additionally that \ It is not true. |the "atime" mechanism addresses these needs poorly. I hate atime. In the past i always turned it off on most partitions, under FreeBSD. If i recall correctly reading FreeBSD documentation (which was my main UNIX learning factor; including the /usr/share stuff that i much admired) ignited that feeling of waste of prescious time (on a Cyrix 166+ with 49 MB RAM and a, uh, maybe 200 or ~250 MB hard disk -- i have forgotten!, i seem to recall about ~300 or 330 MB/sec memory and ~30 MB/sec cached disk performance (Linux), and i am pretty sure about the less than 5 MB/sec otherwise). I think i always used noatime by this time, on FreeBSD (whenever i read out the old IDE disks i hopefully will discover also that). I seem to recall "birth time" did not exist. Now it must be said that today i do not care that much. I do not even have a special partition for /var no more (on the laptop, at least). The memory and that incredible NVME disk are so unbelievable fast that i would not even have dreamed of it. Whereas i still do not truly look at access time myself consciously, i let it happen. (Unless it does not make sense; for example /x/music -- greetings to Kaiserslautern! -- is actually living on multiple disks, and (backup) sticks (well those: actually all), and it is only hm populated on one master (at the moment not NFS shared, but maybe later). That is then cloned everywhere. So. Hm. Ie, twenty and more years ago i surely would have agreed in that i turn(ed) off atime, but today, .. i for myself use relatime here. Also: as a general by-default policy: i do not think so. (But i am only a user.) |With that in mind, developing "relatime" to try to alleviate the shortco\ |mings of "atime" has a low ROI: It doesn't add the crucial functionality \ |most needs (like auditing) would require and doesn't even really address \ |the I/O shortcomings in some frequent scenarios. Deactivating "atime", \ Aha? Which? Today?? Well i mean writing must happen. |by contrast, doesn't require any development, suppresses all I/O overhead= , \ |and doesn't suppress any functionality for an overwhelming majority \ |of uses (at least, this is my current view; other inputs welcome). Not mines. |I did not say that the needs themselves are a gimmick, e.g., having \ |a notification of new mail (although, in this case, frankly, I'm on \ |the verge of arguing it). Simply, relying on "atime" (or "relatime") \ Actually it is often distress, as i work on multiple terminals, and the reported "new" mail has often already worked when the message appears. :) |for this is unnecessary, as you must have understood reading the various \ |previous answers in this thread. | |> On Linux mount(8) from https://github.com/karelzak/util-linux says |>=20 |> relatime |> Update inode access times relative to modify or change time. \ |> Access |> time is only updated if the previous access time was earlier than |> or equal to the current modify or change time. (Similar to \ |> noatime, |> but it doesn=E2=80=99t break mutt(1) or other applications that = need to |> know if a file has been read since the last time it was modified= .) |>=20 |> and this is what i use, except for some noatime mount points |> (/x/doc, /x/music, /x/pub, to be exact). | |It seems that the other answers (mostly those of Robert IIRC) have \ |shown that this manpage text isn't up-to-date with current practices. Ah ja? |Which need(s) of yours are you trying to address exactly by using "relat\ |ime"? I address that i do not turn off atime. Actually i do not, but get that automatically. But would otherwise. I only set noatime at times. Some utitilities even actively restore access time after they are doing their thing, in a standardized way. |Thanks and regards. I think i want to day that i would not like it if a global policy enforces noatime. Especially since the necessary changes are small, and could even be automatized easily. --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 Wed Jan 10 20:34:57 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 4T9KL92Zmlz565hn for ; Wed, 10 Jan 2024 20:35:13 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 4T9KL84WgNz4fly for ; Wed, 10 Jan 2024 20:35:12 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-5f69383e653so47204787b3.1 for ; Wed, 10 Jan 2024 12:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1704918910; x=1705523710; 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=yw+PcGh7o4ss2mIVHtiqf2R67WcJvHpKymB4vWzJ1EA=; b=GMSQih9Wvm4xAb5gXmMBxY5WOjbNQvAQTxJl47YeGh6aSWD5lVyD+e/wZXo9UZZ8+M Le5XivGEsSRD4IU4fxWX5iBvIns6zZ+JSkEicjRi0Gia7+p7yaAh9dk6xS74p2mcr3wJ r92yUPXKebx69HEyGWSe2t7Lqqmvlg66MrYRRwS7zxr4Qmph4dNUVCYK73xuJymDGCbM eTW4WfEGvR/zcZWys87NXJJLX6v8HXinRfOIvbfukxvLFbc/epO1njx0tVzWFhrE2vSo J/FUq5/se7Azsv4n6c73aCClMYOKHANZksGXV8RAG2ZjBrdtSYj9l+0kJ7SSb94NqUW+ EDCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704918910; x=1705523710; 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=yw+PcGh7o4ss2mIVHtiqf2R67WcJvHpKymB4vWzJ1EA=; b=MQ9nERKd4fJdU7uuyxlNAgsafYQxRfhDwgb8GULneNLS/giO9D7x8ZsqTNrIomWxmG H/zDpTcUPr4aZvm9LsMY2eZZ5jfmQ3zJdBLgyM4RzSV+6RpJjh4zPAW0cUr0VD2cr9IU 3YaiJO0a4ZemFMbYBHYjlxw/87u4F6R5YDCEY5B9ZT7VehzbXBPEHKC/Jb6yBdJBUDcj vNDFKoqcwR2GtG8/IZVbm4Rk2CGDcYS/kBfbi6TgbrBpfSXw2NXhkrxjKALHqU+7cioU 9VksYvi3JBqb9JE6ZGMC16UKvvIw32lWovdQhkjpMnL9gv6AvIWltAXjnmB8+YA/W7QK pkiQ== X-Gm-Message-State: AOJu0Yw94cnWt1cVg+xcPNDW5rhC1DAiMI/W3EGTbFTJcTgnHKfml6F7 eg93ji7kFMmzqFRinTiIOLTixbSfvVk4nHquoaZw6LYSeg== X-Google-Smtp-Source: AGHT+IHdPwo5oto0IiyZRcP0WWI2d6VwUz+/CQiro4EjSKNn/xM1NXuDhK4vIb0xcDcCx6AgtRtchw== X-Received: by 2002:a0d:ca90:0:b0:5d7:1941:ac7 with SMTP id m138-20020a0dca90000000b005d719410ac7mr181588ywd.98.1704918910398; Wed, 10 Jan 2024 12:35:10 -0800 (PST) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id i136-20020a816d8e000000b005e8fc1e90e8sm1852016ywc.111.2024.01.10.12.35.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jan 2024 12:35:09 -0800 (PST) Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-dbd721384c0so3642166276.1; Wed, 10 Jan 2024 12:35:09 -0800 (PST) X-Received: by 2002:a25:6608:0:b0:dbd:b364:69e7 with SMTP id a8-20020a256608000000b00dbdb36469e7mr184797ybc.77.1704918909452; Wed, 10 Jan 2024 12:35:09 -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: <1749331.ETpRK2a2Mi@ravel> <2136329.mxFCRLsXLg@ravel> In-Reply-To: <2136329.mxFCRLsXLg@ravel> From: Tomek CEDRO Date: Wed, 10 Jan 2024 21:34:57 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: noatime on ufs2 To: freebsd-current@freebsd.org Cc: Warner Losh , Olivier Certner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T9KL84WgNz4fly 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 Wed, Jan 10, 2024 at 6:36=E2=80=AFPM Olivier Certner wrote: > Both the examples above prompt some straight objections on the current us= efulness of "atime". First, unless you've disabled building the locate dat= abase in cron (enabled by default, on a weekly basis), access times on dire= ctories lose most of their usefulness. Second, if using an IDS, I'm afraid= it's just game over. And even if you think you are not, '460.pkg-checksum= ' at least is readily there to much complicate, or even prevent you from, g= etting package usage information this way (it is enabled by default, and on= a daily basis). > > The general point here is that a single access time is inherently fragile= to interferences by multiple applications for multiple reasons. I am reading this interesting discussion and please verify my general understanding: 1. There is a request for change in core OS / FS mechanism of file access time (atime) because of problem with mailing application? 2. Linux change of approach to atime that keeps its value only around last 24h so we should also change it in FreeBSD? 3. "realtime" is the alternative solution to keep atime intact? Why change well known standardized and widely used mechanism that is here for decades? If there is a problem with an application why change core OS/FS with all possible negative consequences and not fix the application? Wouldn't that break POSIX / backward compatiblity? Thanks :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Jan 10 20:43:33 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 4T9KWz0RSHz566wF for ; Wed, 10 Jan 2024 20:43:43 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [208.79.93.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9KWx6N99z4hlw; Wed, 10 Jan 2024 20:43:41 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lyndon@orthanc.ca designates 208.79.93.154 as permitted sender) smtp.mailfrom=lyndon@orthanc.ca Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id 67d6fad9; Wed, 10 Jan 2024 12:43:33 -0800 (PST) From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" To: Olivier Certner cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-reply-to: <6714298.qJWK8QVVMX@ravel> References: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> Comments: In-reply-to Olivier Certner message dated "Tue, 09 Jan 2024 09:47:59 +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 Content-Type: text/plain; charset="us-ascii" Content-ID: <50122.1704919413.1@orthanc.ca> Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2024 12:43:33 -0800 Message-ID: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.77)[-0.769]; R_SPF_ALLOW(-0.20)[+ip4:208.79.93.154]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:25795, ipnet:208.79.88.0/21, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[orthanc.ca]; MISSING_XM_UA(0.00)[] X-Rspamd-Queue-Id: 4T9KWx6N99z4hlw Olivier Certner writes: > I've never found any compelling reason in most uses to enable "atime", e= xcept > perhaps local mail but as addressed in other answers it is a relic of t= he pa > st mostly irrelevant today. And its drawbacks are well known and can be= seri > ous. When UNIX ran on PDP-11s and disk pack sizes were measured in the tens of megabytes, atime was very helpful in determining which files were likely candidates for archiving to tape when the disk was getting full. And in the Usenet days it was common to mount /var/spool/news noatime, which eliminated a *lot* of meta-info write traffic. These days, other than /var/mail, I can't think of a compelling use for it. I've been running my Plan 9 systems with atime disabled ever since fossil arrived (decades) without any impact. I don't see any issue with making noatime the default. For those that must have it, /var/mail can be carved out as a distinct filesystem and mounted appropriately. --lyndon From nobody Wed Jan 10 21:04:04 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 4T9KzY4cDhz5690n for ; Wed, 10 Jan 2024 21:04:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 4T9KzX72yZz4lPK for ; Wed, 10 Jan 2024 21:04:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=QCSPNo9R; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::c2c as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-59898a3db56so639846eaf.1 for ; Wed, 10 Jan 2024 13:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704920647; x=1705525447; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=daEAYH6cxEKYTj4K2Kuoe8c35FsWw/BYwoJgc/lmLsY=; b=QCSPNo9RjWzBi3CfnRr2jz20nbixoFS0IKckGRwSjm5Eaw7cmw/QOWFseJo6UYczNO YvAYRgcGjRISOqD+zkaxdeke3f57ox2B32nLJ36eUoGiod1Q3BN83jhE2CurYeqCkLdg Qa2vNxa6Cobgh888ps2q8yJDrzNGQ6MTjizQpcOAM76ess+MqlCwh/P+MMoTESRJuL+n LbPzmsMtsAsQzB+49h5udHbSGGJLiQrJhI6LZNetTIJqi25SKmicDeCOKfUWXzARM+Tn pgnxhYkkw68d7cHZw9HTdWO7zZ++kagqQSz38yRqjugKiHX/uaNGKLLW5TjS82g1LRxC cIxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704920647; x=1705525447; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=daEAYH6cxEKYTj4K2Kuoe8c35FsWw/BYwoJgc/lmLsY=; b=ZFfqhxojcseYXxNyQEwOidSWHGfWxOExFma38ZP6iXPDDgh7uFm4Q3LyMk+KyLY+Ev 1pPJUpxs/LLkjCf4kiDCwh01pivffGa0XFbgokc0FBc6knXslBEVq2/9nNQw0+grv3oa OZ3pLq31+R70Pj0N9g0eU4SWeT4T84UT5PUvl1w/NvRgUjk/F7s1aPHzNeL2/kW/YCFG pHb5wsuauwRPW54v1xHD5kjkUL+9o+OT52Jw3z4cQZgOrHRB1IFVlk76G5UL4TbEjvml TVnWPHh4xYeiJjHicupybCwkA1A8e2xDj9GKSrjGEVG+Mf2es5xypQ0p93WjaxlFyAkT prZg== X-Gm-Message-State: AOJu0YzJ/y5lQp7/3Aqc0SijynqIu4DVl+fyvqR0rUHtVSR9T6lYEqDE UdNHW3p/X6WNJDSKZxbNHsyqr9u8btO0DQ== X-Google-Smtp-Source: AGHT+IGzsOh80Ch9uHa8M2B0qJUAfRcOtlFANd/lacoxm9ZfHwxkdluyUxfIhHhLMAt1pIswany9ig== X-Received: by 2002:a05:6358:910d:b0:175:6ae7:aae0 with SMTP id q13-20020a056358910d00b001756ae7aae0mr221972rwq.16.1704920647348; Wed, 10 Jan 2024 13:04:07 -0800 (PST) Received: from smtpclient.apple ([2601:601:782:be00:9c2b:b3b7:ec79:86b6]) by smtp.gmail.com with ESMTPSA id y129-20020a633287000000b005aa800c149bsm3981042pgy.39.2024.01.10.13.04.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2024 13:04:06 -0800 (PST) From: Enji Cooper Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8DC6F902-AA0C-4C0D-AA83-002F8F3C5F63"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 \(3696.120.41.1.4\)) Subject: Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64 Date: Wed, 10 Jan 2024 13:04:04 -0800 In-Reply-To: Cc: freebsd-current@freebsd.org To: void References: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.60 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c2c:from] X-Rspamd-Queue-Id: 4T9KzX72yZz4lPK --Apple-Mail=_8DC6F902-AA0C-4C0D-AA83-002F8F3C5F63 Content-Type: multipart/alternative; boundary="Apple-Mail=_925ACBFA-3410-4BA4-AFF9-A577195598C5" --Apple-Mail=_925ACBFA-3410-4BA4-AFF9-A577195598C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 9, 2024, at 7:17 AM, void wrote: >=20 > On Tue, Jan 09, 2024 at 12:24:40PM +0000, void wrote: >> On Tue, Jan 09, 2024 at 10:24:53AM +0000, void wrote: >>> On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: >>>>=20 >>>> Was the kernel/utility built with IPv6? If not, that=E2=80=99s a = general bug which should be filed (which can be easily checked/avoided = using the FEATURES(9) subsystem)=E2=80=A6 >>>> Cheers! >>>> -Enji >>>=20 >>> world/kernel was built with WITHOUT_INET6=3D in /etc/src.conf >>>=20 >>> I made the problem go away with removing WITHOUT_INET6=3D and = rebuilding. >>=20 >> I'll re-add this to try and replicate the problem with the same = sources >> (main-n267425-aa1223ac3afc) and if it happens again I'll make a PR = for it >=20 > I forgot about this line: >=20 > options INET6 # IPv6 communications = protocols >=20 > which, on current/arm64 lives in std.arm64 which gets included by > GENERIC which is included by GENERIC-MMCCAM which is included by > GENERIC-MMCCAM-NODEBUG >=20 > commenting it out and having WITHOUT_INET6=3D in /etc/src.conf and = rebuilding > fixes the problem. Sorry for the noise. It=E2=80=99s not noise; what you found is a valid issue. Please file an issue for this, noting that the kernel was built = without INET6 support (that=E2=80=99s the key bit of info for reproing = the issue). Thank you! -Enji --Apple-Mail=_925ACBFA-3410-4BA4-AFF9-A577195598C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jan 9, 2024, at 7:17 AM, void <void@f-m.fm> wrote:

On Tue, Jan 09, 2024 at 12:24:40PM +0000, void = wrote:
On = Tue, Jan 09, 2024 at 10:24:53AM +0000, void wrote:
On Mon, Jan 08, 2024 at = 01:07:30PM -0800, Enji Cooper wrote:

Was the kernel/utility built = with IPv6? If not, that=E2=80=99s a general bug which should be filed = (which can be easily checked/avoided using the FEATURES(9) = subsystem)=E2=80=A6
Cheers!
-Enji

world/kernel was built with = WITHOUT_INET6=3D in /etc/src.conf

I made = the problem go away with removing WITHOUT_INET6=3D and rebuilding.

I'll re-add this to try and = replicate the problem with the same sources
(main-n267425-aa1223ac3afc) and if it happens again I'll make = a PR for it

I forgot about this line:

options         INET6 =             &n= bsp;     # IPv6 communications = protocols

which, on = current/arm64 lives in std.arm64 which gets included by
GENERIC which is included by = GENERIC-MMCCAM which is included by
GENERIC-MMCCAM-NODEBUG

commenting it out and having WITHOUT_INET6=3D in = /etc/src.conf and rebuilding
fixes the problem. Sorry for the noise.

It=E2=80=99= s not noise; what you found is a valid issue.
Please = file an issue for this, noting that the kernel was built without INET6 = support (that=E2=80=99s the key bit of info for reproing the = issue).
Thank you!
-Enji
= --Apple-Mail=_925ACBFA-3410-4BA4-AFF9-A577195598C5-- --Apple-Mail=_8DC6F902-AA0C-4C0D-AA83-002F8F3C5F63 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmWfBkQACgkQ5JFNMZeD GN6rxw//Ya6pxSx4nCOKGN/tYbX0z6gXb7RK5FIer0dtxxOg+OtYrZtuewd3W1wQ Qc8aL3oDR6vXqQtzqdLGxHs2E4WHIsOkR+ad5eG83aCK4ZNy/ZztXdezZGAUTB45 r52uDl04lT1YjiGyf/2jP/ivjppL1+I+17F7v4pe9LJpcCeUN6F3fX0ZwQIaMzdp SAfOe9Mr/lexnR0t9mhU1Bal5FTdqyh06xF5NUtV7npx1MMLcw5mjDQ80N01zjls TPpUfJWv9o76ZQK5r5vTybh+hvLaz2th0UkZ1/X4XpbzNrhW1Huk9Nh9BuEx7owT uJkN6NzJzr0Ptb8yX2aNkJgfExx4V4/VZB2p4Rewszd28bQsJsiaf8T1oEBYr0B0 gYxg13jQoOC1ArKZHfdprJsBoV7q4soa9tUtwhZ4wpKMTptIZiBVQ97rO1NY1X4w nA8HJH+/O8ZlkNQ3AP7mqtWigi82ZTBBfdqCVEMhSLBVj4vJGJHustwHcdVqytzg GB3cucH35Rlkk2rKq7cL21WZUAxj8A9hHvlPAa54TUSBO0+BxcG+m0teeIvN4k6A O7TBucE5BxK6dmArNpwNB04s+AxDBhOKy9w+EZtR4HhwYUdIctZy1baTT/JQwMMp 1P3P3Xe6ER8f3FnkN/VwKNm5f76aEN8BvaroYIjzp1Yqnk7vAe8= =hxwV -----END PGP SIGNATURE----- --Apple-Mail=_8DC6F902-AA0C-4C0D-AA83-002F8F3C5F63-- From nobody Wed Jan 10 21:28:16 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 4T9LWh2VWTz56CbZ for ; Wed, 10 Jan 2024 21:28:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 4T9LWh0crhz4pp4; Wed, 10 Jan 2024 21:28:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6d9a795cffbso3404418b3a.0; Wed, 10 Jan 2024 13:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704922111; x=1705526911; 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=U7sG11Xuc6omSFFwS58xhzVcqfGQTZRnB4BZPWXHi8o=; b=CxY3j/Qp3CJdljnN4HviPrkXg5F7UQFkYz8Q4w83Yiz8RjjbBrC2KEmXbbsdLIoBpx amPwOPrxcNr5alHrV+2i5nfHELB3WYK195TsiU50v/2D8UmPhkuqbuqCn2VLnFj3keEJ lNGsIXQJLEJiKHi5SRhrX2WtNnL3pzQcEhnNaDX9l8Ygz6azxDrLtG4A2Vq6mPjp9oU4 1hHX3fw0UtfAcW+27DuqPYDKbj7R4fY8cq7FGEoztWfIr4MswnKu5vu/nLz/wHA097xR MrtgqE3P2xN1fVwNrwZQGXY/PB8eoXYMCRrTyTTY8jeklr9OmJsj84cGRZjJwdASOlxz DjqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704922111; x=1705526911; 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=U7sG11Xuc6omSFFwS58xhzVcqfGQTZRnB4BZPWXHi8o=; b=BTPTkgQmnsaOVuNrNIVgoVohp6pvkffpaYi3jLExEG/sjDqknsW6nDba0Tj9RZeF9j LQiBBKYKI7wikvXEN4wHsXzgGjHNqT5DX51Cm7HIxIpGkZ9FrUzZT3EitLHMqqCl/wC8 WiX5NbBsCBj0irNzj1awcLmAh2xLMDHDvj7IWfPMdxoRT1+SZlLpoLRJRGnqblKY1ckB W7FctUDoLc3HTOVf15t0N5QjYCMRCtU7PsKrj8mdf6lTnJmvN10gsdYpJBIm57hwKw5B JZ2cq5fePi30RCwyG36WyFKovuyvXdQ5GmxS3s16eYLJMSKZzrW1lIoadsHmJix1fqo+ h7Mw== X-Gm-Message-State: AOJu0YyfFGH7zS4YVfwja0WKFjXUyrJMQScnrheN14kBcGOglBG59A/d faxeQ/zJPXnZD7/RRNQtm34XNLPAVWCiTX9QaPgi/xmIMA== X-Google-Smtp-Source: AGHT+IETKIm7tMYj/4tJGrUYvxM/uMZkkMp69Z4W0bmXnFSrLbxB2rzeA6ttq8+w7Cfc3V8O0VNEEjx2BMIY7IIsA/o= X-Received: by 2002:a05:6a00:2d15:b0:6db:984:8783 with SMTP id fa21-20020a056a002d1500b006db09848783mr939118pfb.6.1704922110712; Wed, 10 Jan 2024 13:28:30 -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: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel> In-Reply-To: From: Rick Macklem Date: Wed, 10 Jan 2024 13:28:16 -0800 Message-ID: Subject: Re: noatime on ufs2 To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" Cc: Olivier Certner , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T9LWh0crhz4pp4 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 Wed, Jan 10, 2024 at 12:44=E2=80=AFPM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Olivier Certner writes: > > > I've never found any compelling reason in most uses to enable "atime", = except > > perhaps local mail but as addressed in other answers it is a relic of = the pa > > st mostly irrelevant today. And its drawbacks are well known and can b= e seri > > ous. > > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. > > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. > > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. Just choosing the last message in the thread... I do not have a strong opinion w.r.t. atime, but I do believe that changing the default would be a POLA violation. Please look at this email thread, where the opinion w.r.t. atime seemed quite different: freebsd-hackers@ Oct. 5, 2023 Subject: copy_file_range() doesn't update the atime of an empty file I'd put a url here, but gmail always puts the subject line in here when I copy/paste the url? Basically I did not think that updating the infd's atime when copy_file_ran= ge() did not actually copy any data, but the collective disagreed, so I patched the NFSv4 client. (I do not know if markj@'s patch did get committed). They also collectively thought that Linux did a poor job w.r.t. atime. rick > > --lyndon > From nobody Wed Jan 10 21:49:36 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 4T9M0P00Rnz56FpK for ; Wed, 10 Jan 2024 21:49:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4T9M0M5zKSz4s1h for ; Wed, 10 Jan 2024 21:49:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LrqIYWbs; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704923392; bh=5J5riyHFt9ptQo/Rl1IjNTVaRqwA57o1E7u9Z52ObcU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=LrqIYWbstDtJV0E49xATYeNZ+OWfzgSaSaMqhesgMLj9k0ex2+rDTfN0u/DRa/UN0lOj6HumTf6NX5oKOIwg9j+RgT7dWg13Om0Zme/RT1LOwn9YbnA6vnfebhRikX43fhMF72GU21wNAKp6Aa+4pC7btXNwRhBzR9kAam8mONrDT/cBUfvEUKqI6biobHjUjQBKkiUwhGkue+6itUL+EFG2EfC/gawdYgFA4FFaVFAkvjPYO8ecw6iwPpvDWC63hg9ONHkZYcbogy7Juul/RqO9/fYgOExDMtLCtTb16fy1JXMWzbG3ROCtWeUPODcylS7ndWcrHv27dyClkvxCHA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704923392; bh=5zo/PhoCPY30mi/PzRekWKe0swsORlI9xDgPU51JrYb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=MNm/0+KigdZtMUSqbIbX6HeToEZBMd+QSzmX1/c/xjR6OVafLlQVmXMFK4euJd0IjfgI+9ivoCH/TO70Ts2RVtHVtADGdy/BrMovI5Mso0aJKQEIaC+k2W7a0y4vf/Bqtvx60iGbF3Tn1mPObUGDzW5HlwS27wO/VHdFgD8aBC0M8fLMSSsIM0HE6aBPvixyO/ZNkBvmqzWjNydr955t25fn8HjKPROA2Dryu1dh32E8uMQjchd4tXCRKQHEWrleoToD53lWwgsJiIJ0qHLSzglzVpASwEGfzmYUp70MsAU+H+q/gumHA6qo482e7CyhtuTw3t2HPmKPvn7S1D9WxA== X-YMail-OSG: BGuFyTkVM1mMs5_tiGVOVXQV59xV9Nhy1LSsggPwQyByMfYrcAgvM53We6V1dF1 fYPfYYWwhERqTp.j.39dUUbfHf9X70zqmbAakzEZt1Xl2t7patTuDdQRo5_y9WkGrzwxi7X6_98s gS6M_gHTVDBY2j5hMNxLuI7UzfozFmgem.D872E.rUt3tJJ5sLyi_GYQXTDW3s.azgAptvy9lG5L HrOzHy3qC5HUjEY2ij.s3Xp4fc157.lZOJVKXROBTzfumuTkEC4fJrGUor4BvSWzD5ofGCNbgdyL hmmZ_qNN6Ag6zCNuUIOMuJlfrvBaa6uxB2OEqnW9d4f7Bhi1X.nyyZmN65Ktqhnk4OMii3zpXX9I 9rgN86SFRDfcR3wbyxI_5jGnyUTdEUo.91fUjOEU0qcwYha7mJ49z7JuStoMHE9yFFaLPg2ILYjY 6Ia3MUYl1TOf7hOliCsPBghm.BgvJkMmuRB_IL.bG2PxDqJ9KBH5tuK6.DrvJoJdUuo5vBL7xfeU NxbpbIdJurkQoxMo6J73da6A5gT5h9dOL2UifclV05GtyAAFWI0o459M.h4crcspz9DOPSrYaBox GiVkhwRXFr7GUBQ3ck6gaASaSOcU6q934.nq.qO5Ar.XwOKXqydEtYC70LvbowSfzByfg7k3X_td ZbmC0YfQZJlN7ZQsfXejiBs8qj7gCzlMLAkZuShWddWr6l4TEZCLH_djbX77dyUKVl3Vp0PUWviw JCyBeeXXM8QRXWEX8CPSgQ1NmZA4MauwhrXiSpS89iMUrndnwOfvBAJvrePGt9K.7bLdiypKU_nW uGpexahDS3MLUgzImwVVdqgBa1ueyy3S9T5nI9mubp506j1Xz8eLgUPYt22Yx7vjlTdlrwaDTmbV zMrBQgMOu1kCh0N9JPjOFbM3BdBTuatC40DHngZZ9uDygmCrohaM5VavkV88vUt9_5AK5E2y4cC5 RjaSsVf4kvqGS8s34Zd3FjReXz_U.QZE5z2kvUBJJspPomwksSBdcYI39cSLKe6PTuvlQGfXdoZ2 vs0uao3ITf8lLfwxHo6wKjN5MrzQJO07YESHD7I92Q7f0eALee9.5jX.G7Rk3mO4_rMp6gthCzJx MQmzZ7a64JP5GKNAhUkqlevCUoD4WlyBJMJuqdIHIwZiTFTXD_0rTIxn7P.7AwOLjqanHzGXRpUG Po55mJbMttQLxm6bNKcBQf_.JxfcZ23rm.aepIDI2foR5fcRjomb9nf01_ECo_7EPVQyzUayxcc2 5pDPInQzQB8GW.J0pMWm79sJt9hkWaLH1DCg9kbtPX0yVBRGk5YULQ41Hs73MHbiG_PWwePAjfHv 66gBBhBP8vHL_a3Xu.IokawICbTehrO47fjp.0C9EspQOQzaCLMGtlyzwXJriuYs9V4SFbIlObxW uaA_MoTezC_t3Q99j2mAPPVn6fQAzO5cUR49qHLWswm9ZJo7IWNuKbQz4.rWCwQkodfwwWc.p2at EJPLcdTaZuVbd4Rifg1mf2xZ4DmwyAIIjchHZdwC0h1Mk5oYWu3ibGdeuXI1CzT6FIV.E3wfTcjO ATowQ4Akn3KqRR4HmNGo2yECVWDSynqMeaf04psCqq2DXNh90rGOXkzqfVaMnKgxPGe4ncECHpS3 Aw.0b8BPCYnSv0cuSgnVDLhck_kngNy1hX2nDQ13kmi7xFHHtnii7IV9Tlz4Qd9.0bihDy54fAh7 VXW.wlmaYzvH_WFuTl4ZuEeKabeStsQp1KD.5e.Xo.iWb6lfM5aRd6rRLj5_Iq1vvf3qMkjPouh. 2sxQsmWYdQPxlkYcnX1Rg.hpoN1B7q9MIDzFoXxNYaZMp7zyLxAfTBtIeK4OSI6aovYJ3WF6B7IO jWIZvDahg_wlE2.tStVMldBX6dceLggxMzK7yANYBfs5xguPmuSKnI_QyGX6Jcspj5T6LMRhbb2l XPXFn2SWDULPzEGI2uA4ivSsbWjvWt36DM6BjS6IN1cR7nEfTKmrys4g6JVUtdxnIrjJIIvFr9bp .jNcpHgeW4kZJB7FWIt.DIvbglP51gQDKs4seSa77JzFkMhJ8.Z9OlRAlwxCatsbsGEZJLB3oXkQ 1G7RhBsK.fcVYevCJfbgMqhepMca.DLPddpRdBCwqmkO50ahNCeowqJiy.wW349ArTPkvr8HcYwS 4zcq1FyJ2dh1lVWw_TPae_1bes52yRIvcZ6JgEA.HR5.XWwKoI77KONQLowxmXb1TAb52fB5SYH2 DzByqW.h26BfkETWE64aOeq40EEnzBZ.36ZzcPznzZUs3CmANWBUwQnzhYLmgBlMjtUw5n2XTHw- - X-Sonic-MF: X-Sonic-ID: f8be362d-cef9-49c8-a4d4-624bc66b1021 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 10 Jan 2024 21:49:52 +0000 Received: by hermes--production-gq1-78d49cd6df-c95sd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0d6409c4f215c900060086a7b85c3939; Wed, 10 Jan 2024 21:49:47 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 Message-Id: Date: Wed, 10 Jan 2024 13:49:36 -0800 To: olce@freebsd.org, Current FreeBSD X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from] X-Rspamd-Queue-Id: 4T9M0M5zKSz4s1h Olivier Certner wrote on Date: Wed, 10 Jan 2024 10:01:48 UTC : > What I'm saying is that, based on others' input so far, my own (long, = even if not as long as yours) experience and some late reflection, is = that "noatime" should be the default (everywhere, all mounts and all = FSes), and that working on "relatime" won't make any real difference for = most users (IOW, I think that developing "relatime" is a bad idea *in = general*). And I think this is a sufficiently reasonable conclusion that = anyone with the same inputs would conclude the same. So, if it's not the = case, I would be interested in knowing why, ideally. I never use atime, always noatime, for UFS. That said, I'd never propose changing the long standing defaults for commands and calls. I'd avoid: A) Having natives & required file systems with mismatching defaults. ("required" is for spanning efi/msdosfs partitions if the = atime/noatime makes a distinction there. So not just UFS/FFS and ZFS.) B) Having files systems that are not OS specific have unusual defaults compared to those other OS's when there is documented uniformity. (openzfs being such an example file system.) C) Having defaults unlike most other closely related operating systems that support the file system when there is generally documented uniformity. (No claim to have checked on the uniformity generally.) (Other BSDs, Unix, Linux, . . .) D) Having defaults for non-native files systems that are different than the native contexts for the file system have when they have = uniformity. (So, for example, linux ext4 use would get linux etx4 default = behavior for atime vs. noatime if such is basically uniform across most linux's.) Note: I've worded the above as if things are always per file system. Command default that apply across file systems that have the feature of allowing stored atime are also relevant. But the wording gets messy if expanded in each relevant place above. Picking openzfs as an example of documented uniformity . . . https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops.7.html = documents: QUOTE atime=3Don|offControls whether the access time for files is updated when = they are read. Turning this property off avoids producing write traffic = when reading files and can result in significant performance gains, = though it might confuse mailers and other similar utilities. The values = on and off are equivalent to the atime and noatime mount options. The = default value is on. END QUOTE Unless openzfs manges to decide to change that default across OSs, in my view FreeBSD should have it be left as documented for its use of openzfs. Given that, having FreeBSD UFS/FFS be the other way would be problematical in my view, even ignoring defaults for non-FreeBSD that support UFS/FFS use. In my view , the burden to make things work relative such defaults is not worth the consequences of making a bunch of new distinctions in a long standing subject area. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 11 00:49:55 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 4T9R0K1v9Tz56cfk for ; Thu, 11 Jan 2024 00:50:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9R0J3xZWz4LwV; Thu, 11 Jan 2024 00:50:08 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 40B0nuKJ046905; Wed, 10 Jan 2024 16:49:56 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 40B0ntj0046904; Wed, 10 Jan 2024 16:49:55 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net> Subject: Re: noatime on ufs2 In-Reply-To: To: Mark Millard Date: Wed, 10 Jan 2024 16:49:55 -0800 (PST) CC: olce@FreeBSD.org, Current FreeBSD X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4T9R0J3xZWz4LwV 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:10494, ipnet:65.75.216.0/23, country:US] > Olivier Certner wrote on > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*). And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same. So, if it's not the case, I would be interested in knowing why, ideally. > > I never use atime, always noatime, for UFS. That said, I'd never propose > changing the long standing defaults for commands and calls. I'd avoid: ... Very well said Mark ... Please folks stop tweaking defaults, especially long standing ones, if you feel the need for noatime, set it, by all means, I have been for 30 years.... ... what Mark said very well removed for brevity ... > Mark Millard > marklmi at yahoo.com -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jan 11 00:51: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 4T9R502zWLz56dLx for ; Thu, 11 Jan 2024 00:54:12 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9R4z4Cdpz4N7N; Thu, 11 Jan 2024 00:54:11 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.17.1/8.17.1) with ESMTPS id 40B0pfmC077283 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Jan 2024 16:51:41 -0800 (PST) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.17.1/8.17.1/Submit) id 40B0pe0Q077282; Wed, 10 Jan 2024 16:51:40 -0800 (PST) (envelope-from warlock) Date: Wed, 10 Jan 2024 16:51:39 -0800 From: John Kennedy To: Alexander Motin Cc: Kurt Jaeger , freebsd-current@freebsd.org, Alexander Leidinger Subject: Re: ZFS problems since recently ? 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-Spamd-Bar: / X-Spamd-Result: default: False [-0.78 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[phouka.net]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4T9R4z4Cdpz4N7N On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote: > Please see/test: https://github.com/openzfs/zfs/pull/15732 . Looks like that has landed in current: commit f552d7adebb13e24f65276a6c4822bffeeac3993 Merge: 13720136fbf a382e21194c Author: Martin Matuska Date: Wed Jan 10 09:07:45 2024 +0100 zfs: merge openzfs/zfs@a382e2119 Notable upstream pull request merges: #15693 a382e2119 Add Gotify notification support to ZED --> #15732 e78aca3b3 Fix livelist assertions for dedup and cloning #15733 7ecaa0758 make zdb_decompress_block check decompression reliably #15735 255741fc9 Improve block sizes checks during cloning Obtained from: OpenZFS OpenZFS commit: a382e21194c1690951d2eee8ebd98bc096f01c83 From nobody Thu Jan 11 01:41:55 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 4T9S8L5Hdwz56jpk for ; Thu, 11 Jan 2024 01:42:10 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 4T9S8L2bjwz4Wf1 for ; Thu, 11 Jan 2024 01:42:10 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-5f00bef973aso49898107b3.0 for ; Wed, 10 Jan 2024 17:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1704937329; x=1705542129; 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=j9wjXirvYkbEhdkjVA6u/NdLKQa2O07NfS19B7pe5+4=; b=ezkguHI/OtnBO1Q5R6mTEIDqCm7l+ck1ryJaEKyeohioXjrwA8W7o8NXz7eYF4t6VQ gXMw75ABAMslqSPFDpR22VFAH/Vf5QRAUh5GIbLtlo5qCDg9JAlSKr7rEErSlMexlolO 2O8t6nh5keYLKkrzgZ46OPHNbpA5SwWGVxrGXrsmaT9MROKjZhGLeiLkbgNeYhIo10mD mOGeiZq9ZyoBW/XHqUP9trNllSAC/LneTr+Dne41ZUOIB7OzC5nnZ9+3gSStdIXn9C+H RudkcSdfN5VA39vOEMM8nMcCyL17FeBV3fcnPzwhPxKdbXYmNsEJp8SBM0fKPiPEplSf 6Yjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704937329; x=1705542129; 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=j9wjXirvYkbEhdkjVA6u/NdLKQa2O07NfS19B7pe5+4=; b=Ec9W4sDpm48i0BhBYC3YLaA0DADrTGiDh9hvPDlPk4DizWQ9OWpZshnQopATliPGdq UWf/rtRIx7OKXl2KKCPwWRbE1IgoXgeh7XQXn0gcfMTkaUESu07/DH2PDottCVCjz1jf RDq45GuYOQBGXNbNgWF8+bN0wbhsk8W3iL426qtrFkpPQ8OfKK6p8xYoFz+pPVJANi21 ZpLA4leuFsj4ImlwnZ9blxUp1w+Bx9TIrmVzu6f6c02Wyi78/66ZkbF1I72RiU3varIM AS7DtAifml1Aswl32dew0n9xhC+e2BVWbFcgeLhSJX8+T6cwdchfC3gIGthXUsiK8Kmc Hfag== X-Gm-Message-State: AOJu0YwEbKvwWI2trG4GT34wsc18KSPwttqfXEk9SlidEkYNz05Z0D2P EXHm8KPNcTn7+7oDPxSZynYpG3DrSBGy/1NU2WvKUsflwA== X-Google-Smtp-Source: AGHT+IH82RWVBOnImt4LwNaNNJTYFeFNEwMSwiz6RRc3ifcRi/62LcPxTBM4rQABZfkqBhS5ZXmpDg== X-Received: by 2002:a0d:db86:0:b0:5f6:bc81:fc1a with SMTP id d128-20020a0ddb86000000b005f6bc81fc1amr552244ywe.103.1704937328913; Wed, 10 Jan 2024 17:42:08 -0800 (PST) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id x203-20020a81a0d4000000b00583b144fe51sm2798ywg.118.2024.01.10.17.42.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jan 2024 17:42:08 -0800 (PST) Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-dbeff495c16so3436566276.3; Wed, 10 Jan 2024 17:42:08 -0800 (PST) X-Received: by 2002:a25:d7c6:0:b0:dbe:1c7c:59e7 with SMTP id o189-20020a25d7c6000000b00dbe1c7c59e7mr503651ybg.89.1704937328104; Wed, 10 Jan 2024 17:42:08 -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: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net> In-Reply-To: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net> From: Tomek CEDRO Date: Thu, 11 Jan 2024 02:41:55 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: noatime on ufs2 To: Current FreeBSD Cc: Mark Millard , olce@freebsd.org, "Rodney W. Grimes" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T9S8L2bjwz4Wf1 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 Thu, Jan 11, 2024 at 1:50=E2=80=AFAM Rodney W. Grimes wrote: > > Olivier Certner wrote on > > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > What I'm saying is that, based on others' input so far, my own (long,= even if not as long as yours) experience and some late reflection, is that= "noatime" should be the default (everywhere, all mounts and all FSes), and= that working on "relatime" won't make any real difference for most users (= IOW, I think that developing "relatime" is a bad idea *in general*). And I = think this is a sufficiently reasonable conclusion that anyone with the sam= e inputs would conclude the same. So, if it's not the case, I would be inte= rested in knowing why, ideally. > > > > I never use atime, always noatime, for UFS. That said, I'd never propos= e > > changing the long standing defaults for commands and calls. I'd avoid: > > .. Very well said Mark ... > > Please folks stop tweaking defaults, especially long standing ones, > if you feel the need for noatime, set it, by all means, I have been > for 30 years.... > > .. what Mark said very well removed for brevity ... +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu Jan 11 02:21:19 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 4T9T1h28H4z56ncB for ; Thu, 11 Jan 2024 02:21:28 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from thyme.eden.le-Fay.ORG (THYME.EDEN.LE-FAY.ORG [81.187.47.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4T9T1g3zLRz4bsX for ; Thu, 11 Jan 2024 02:21:27 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=thyme header.b=ROgc76YA; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 81.187.47.194 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (IRIS.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106::18]) by thyme.eden.le-Fay.ORG (Postfix) with ESMTP id 56E2E28249 for ; Thu, 11 Jan 2024 02:21:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=thyme; t=1704939679; bh=jEayCg2ef331Uw0RPGaOtAQPmAfZ1RtvsiXQP88mjOE=; h=Date:From:To:Subject; b=ROgc76YALLjTkaQlWJbs8DnbzZoSy1SirP2NeUkj8qvVwJyRhiopsiQwBPTEgYsx6 T03LWCOmO58d8qXJwGjfD8niQ9HFryfTcNEj0sIbjq4s0ZFiXbKVqItRvPZgfsDWA2 bz3XMM6Etd7LLN43aLU07Os4TCg/mxmscVBym0Fk= Received: from ilythia.eden.le-fay.org (ILYTHIA.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:104:3::101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 4A4768328 for ; Thu, 11 Jan 2024 02:21:19 +0000 (GMT) Date: Thu, 11 Jan 2024 02:21:19 +0000 From: Lexi Winter To: freebsd-current@freebsd.org Subject: poudriere: swap_pager: out of swap space 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="prqL3tYSvp8X714B" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.50 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=thyme]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:81.187.47.194]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[le-fay.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[le-fay.org:+] X-Rspamd-Queue-Id: 4T9T1g3zLRz4bsX --prqL3tYSvp8X714B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi list, i'm having a recurring problem with poudriere that i hope someone might have an idea about. i'm building packages with poudriere on a system with 32GB memory, with tmpfs and md disabled in poudriere (so it's using ZFS only) and with the ZFS ARC limited to 8GB. running poudriere produces many kernel log messages like this: Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed this is despite the system having a large amount of "Inact" memory according to top(1): Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, 892M F= ree ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M Other 1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse =66rom what i can tell, these swap errors don't cause any issues with the poudriere build, but they do seem to hinder interactive usage by causing long hangs. does anyone have some idea what's going on here? i don't really understand why the system has used 100% of available swap space when it has plenty of Inact memory it could free to fulfill requirements. --prqL3tYSvp8X714B Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmWfUJsACgkQDHqbqZ41 x5nD8Qv9H4B+1bcqiD5XqFf3+m8cw7T9oVoYChO4m5CrZGBItHlOoK5giaiAlLnv pn5iQrP8eQKIu5sEu9L5mea/NFMTiylpIrMvvK3oIJmMbKxSoJ90M+KozYvsXKnu R1c2ub/msKuhV41G4nPDb0m2OPgU4cVFncvzuZjtO1kKWsJFluDq2dPbIleBv+9C YJRImYCexJDMVC2Hm0s+SACSAJeRiiQdLA/GqQo839P/k4a/RynmtZJzL5T6lnEH JvO0q3fkK+0jRKKgXvZrDXjLlxZug7ZsFr6sVHuTst9noy0NdH//Qi2rwA79Q8z5 XjY/1Fr8pWgM0fNm9dxl+Pu9QyMEuXi76Kegdgz849vvJzohRrLvwI4pNL2rOz9c euBM5+FBgAUbEq2bLxeGd+975/cpMFomZliFOsEhv8WkHP2BqkiNicf7X0ZnoNnq VxMJiLwPgVCD2J8t9/GpW8bElR+vV6NEUPrNRDIDWl4VLBZ4lM7EIjz5hp1XSDhq QR6ogk+k =S9S9 -----END PGP SIGNATURE----- --prqL3tYSvp8X714B-- From nobody Wed Jan 10 07:34: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 4T9bSx025Bz56j2Y for ; Thu, 11 Jan 2024 07:12:01 +0000 (UTC) (envelope-from zlei@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 4T9bSw4W5Sz4M2h; Thu, 11 Jan 2024 07:12:00 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704957120; 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=JpvH3xPudwk26cPVCfxBP7NL0LkJNcNMP8213cS7JPE=; b=VrNjPr7/SiAfV7R1zDeOcdfH6KqarG41e3HPn0xH68RozyL23H2Y66JTmMuHGpO6/0dmeH 6y0kG0ZwON/vmydW1+r5UFZeWjIcnin/P71mpP2ntzglSQhBHlFCa4khOen5KzvbyQxcq/ ucGPnTbqFAqEYjGS17QPH3pi++i8rFf/Y9NgQv1d6K30y+eXQFiE+Jbna5mgArJAquUSl0 Wws8Hnat70arUIpfnN/626+br5hqhiuK/zzE7/PzgbJv33yyCSL2SPTah1GY/GN7DOhYQr s30zt8ldN3bOUKHkj8SgUH2lzJbaf+Ihzjdy413HAl5F6K196lmigq8nzZlttw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704957120; 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=JpvH3xPudwk26cPVCfxBP7NL0LkJNcNMP8213cS7JPE=; b=C9HqT7FGHAy8fD5OF5vUwPS7/OGBzM8xTDM52ob4T8ouwCQBgfrrXpeixQQekVMaMP6bwl t2g+RzRW4c8jEgDwdyb6pXK+cApTiqyUxOR+52aSKT6T/yZQdL50RwhLzZaFFOjBfyJv6V LOa8EmxLkslqHa8DhPYxNCqkNQ8kpz9R5Lwlvd3NoWHnFChLR6mce/3Cu+bRwCCKtnNEqU fD4dUYkHbWdck9DyQoCfKQbaAQVUDHj4zAR0Tn8gooCNDOYJNz/YtczC/vjsB5+4sTFXjx bdHXoLCejhonlTY4ieTddc8A93aSCR4nxEGegNJFASBmWi5kh2XuVB+/QPc8qg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704957120; a=rsa-sha256; cv=none; b=Z/Aw3B3w6W0CObUYE2H4xuCO4lnfJ6rC6yOgLqMoxwyj6nX6raaH5nXUnj3XX5XMkulfGw CbybFXlwGu8s6F52k9Sb6vkoaeOF8ZPimVf82MqRwCHRZ5J9rtx3aYkZ21v1+4AZuaWzKo 17q+QcerOmE3oYrlV84FYgh7LEQxe6mi12IxyTeDE+MHfeg+nkPtpZpHa5RoZfYEjLf0x+ 0AW/TCX/VnsyWvTB9uD58S9YAlkDCFvfKvyhBL4ijq1SZP0iyMOD0dWM1IQ3IUXb13pQbp x53IMxcGQMXMUvQAKdyViwvoip7vZkz1hybN01hjOZcvM7MieRlymoHGVJSFGg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T9bSv4yT4z1SXS; Thu, 11 Jan 2024 07:11:59 +0000 (UTC) (envelope-from zlei@FreeBSD.org) 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 \(3696.120.41.1.4\)) Subject: Re: route ipv6 errors on bootup in -current main-n267425-aa1223ac3afc on arm64 From: Zhenlei Huang In-Reply-To: Date: Wed, 10 Jan 2024 15:34:49 +0800 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <32B3A657-8658-4694-90B9-F3FE56EF5225@FreeBSD.org> References: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com> To: void X-Mailer: Apple Mail (2.3696.120.41.1.4) > On Jan 9, 2024, at 6:24 PM, void wrote: >=20 > On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote: >>=20 >> Was the kernel/utility built with IPv6? If not, that=E2=80=99s a = general bug which should be filed (which can be easily checked/avoided = using the FEATURES(9) subsystem)=E2=80=A6 >> Cheers! >> -Enji >=20 > world/kernel was built with WITHOUT_INET6=3D in /etc/src.conf >=20 > I made the problem go away with removing WITHOUT_INET6=3D and = rebuilding. > The system was installed by taking = FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240104-8bf0882e186e-267378.img > and dd-ing it to a usb3-connected hd. >=20 > Where can I read about features? Features can be retrieved by `sysctl kern.features`. As for INET6 it should be `kern.features.inet6` . >=20 > % man features > No manual entry for "features" >=20 > it's not in apropos > thanks, > --=20 >=20 Best regards, Zhenlei From nobody Thu Jan 11 07:36:24 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 4T9c1p0Vgvz56lwL for ; Thu, 11 Jan 2024 07:37:02 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 4T9c1n26M2z4Pxp; Thu, 11 Jan 2024 07:37:01 +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=1704958606; 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=qMrtwYpSUo43Vgew6Wbv4XQNYJNhJThji9Y1ypgeXS4=; b=Jaq4XqUmnR+1il9UXuHzKY/aVCRIUk4qA5LiH+X1QenRQAVRH7ebNOZzZKj+kpazC7ibjY gImcbJfHK03huZtC4ln0G11ckTuflheqzBRihvvSn1vDH6Fcg/HINza9xxgM3tgHyHi/pu ciQ9fwTNMOJcNQWI0EsWuKBz/XrR+Pv00vXfhSDvK0/GwIV3a09081WbKXKDur5VVS+LdD ui5UEYnS7I/RXCzdYgOgKdEFF8krUjwbmLnj+msARy/V+jN/2Gercne5bdddXDT8W0cAnN 4MfddAVKpAGXInsfMWdrtdkrNSoTTEiTwG52HMpSYCaBVmwmBmr0ma5NXhsSoQ== Date: Thu, 11 Jan 2024 08:36:24 +0100 From: Alexander Leidinger To: Mark Millard Cc: olce@freebsd.org, Current FreeBSD Subject: Re: noatime on ufs2 In-Reply-To: References: Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_d35410f3dd5e84e7d2cf17ebf331a5c5"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4T9c1n26M2z4Pxp 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:2a00:1828::/32, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_d35410f3dd5e84e7d2cf17ebf331a5c5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-01-10 22:49, schrieb Mark Millard: > I never use atime, always noatime, for UFS. That said, I'd never > propose > changing the long standing defaults for commands and calls. I'd avoid: [good points I fully agree on] There's one possibility which nobody talked about yet... changing the default to noatime at install time in fstab / zfs set. I fully agree to not violate POLA by changing the default to noatime in any FS. I always set noatime everywhere on systems I take care about, no exceptions (any user visible mail is handled via maildir/IMAP, not mbox). I haven't made up my mind if it would be a good idea to change bsdinstall to set noatime (after asking the user about it, and later maybe offer the possibility to use relatime in case it gets implemented). I think it is at least worthwile to discuss this possibility (including what the default setting of bsdinstall should be for this option). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_d35410f3dd5e84e7d2cf17ebf331a5c5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmWfmogACgkQEg2wmwP4 2Ib/+RAAg+0jAyio4x7GDqANZe9bNLtmqc1w4V9dV5WViSm1CG9dsQHxw0ZDLxvf StyNenQOdEPimd0jdmaa/yQrSAbcPAXY0jeMXdcVtipYtqfTLJMWhspPLkHBEP05 WnMp+TKomN2TIGn9GLGMOtyewLhJOPlapF1mnEw7TG0NiZW2C/xuVtud8OrN8pCN SnhBKkwNbicbTcN+YpYq1TnR82sm3cMuh+CMT539r0sdrXIAWMKyvl4GkvVx3XRh +RE3yK1iVyDIQpg1GRyeNI+c2Hs6MGVr1VKOjyytBgglfA9cHcl6VHJyDacQx0BR PpLD0JQwdzV6eQxzdSIkwhc33FiXjUFR5+5Io3N16gjaaKUBib/3XnticspaVqbL Af6+DAftn7bfxsZZeStmYU+XWFge0KtgRvw0kETcEHj+e/JD/tdirH/3mhlkU6tY 6dofpt2uwY5kn/NrWXGljaJE/Mo39qoqq7Uw8HtRB2W4okCYGEyMYPDWBhXRROc4 KG28iZ3WbjJJfUAswqzExH8zDCfhP4iwLncCq1sAhfYgVY7Q+FklOn+GDO7ECIR3 wSQjSR9yTeGSHJ1bcjeA4lNstDmFvQPHKlSpjgvt1aEEaNXKO09A5j6X9+VEkWp/ hY6rtLnhofSb+HWJcoZmfz4TCAXpOgVe+fkiJpAXj+ZnVCFPzTg= =SSje -----END PGP SIGNATURE----- --=_d35410f3dd5e84e7d2cf17ebf331a5c5-- From nobody Thu Jan 11 08:54:30 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 4T9dlL1vMfz56vjk for ; Thu, 11 Jan 2024 08:54:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4T9dlK3CCrz4Z8R; Thu, 11 Jan 2024 08:54:36 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40B8sUPf068744; Thu, 11 Jan 2024 17:54:31 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 11 Jan 2024 17:54:30 +0900 From: Tomoaki AOKI To: Alexander Leidinger Cc: Mark Millard , olce@freebsd.org, Current FreeBSD Subject: Re: noatime on ufs2 Message-Id: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (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: 7bit X-Rspamd-Queue-Id: 4T9dlK3CCrz4Z8R 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:7684, ipnet:153.125.128.0/18, country:JP] On Thu, 11 Jan 2024 08:36:24 +0100 Alexander Leidinger wrote: > Am 2024-01-10 22:49, schrieb Mark Millard: > > > I never use atime, always noatime, for UFS. That said, I'd never > > propose > > changing the long standing defaults for commands and calls. I'd avoid: > > [good points I fully agree on] > > There's one possibility which nobody talked about yet... changing the > default to noatime at install time in fstab / zfs set. > > I fully agree to not violate POLA by changing the default to noatime in > any FS. I always set noatime everywhere on systems I take care about, no > exceptions (any user visible mail is handled via maildir/IMAP, not > mbox). I haven't made up my mind if it would be a good idea to change > bsdinstall to set noatime (after asking the user about it, and later > maybe offer the possibility to use relatime in case it gets > implemented). I think it is at least worthwile to discuss this > possibility (including what the default setting of bsdinstall should be > for this option). > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF A different aspect of view. Nowadays, storages are quickly moving from HDD, aka spinning rust, to SSD. And SSD has a risk of sudden-death of wearing out. In ancient days, HDD dies not suddenly and at least some cases admins could have time to replace suspicious drives. But SSD dies basically suddenly. IMHO, this could be a valid reason to violate POLA. In limited use cases, atime is useful, at the cost of amplified write accesses. But in most cases, it doesn't have positive functionality nowadays. Anyway, we should have time to discuss whether it should be done or not until upcoming stable/15 branch. stable/14 is already here and it wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point to introduce this, unlike discussion about vi and ee on forums. -- Tomoaki AOKI From nobody Thu Jan 11 09:02: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 4T9dx340D7z56wjK for ; Thu, 11 Jan 2024 09:03:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4T9dx10scPz4c8F for ; Thu, 11 Jan 2024 09:03:00 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40B92wLs070161 for ; Thu, 11 Jan 2024 18:02:58 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 11 Jan 2024 18:02:58 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: poudriere: swap_pager: out of swap space Message-Id: <20240111180258.ad42faf5d5ff05c8c80a30c6@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (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: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4T9dx10scPz4c8F On Thu, 11 Jan 2024 02:21:19 +0000 Lexi Winter wrote: > hi list, > > i'm having a recurring problem with poudriere that i hope someone might > have an idea about. > > i'm building packages with poudriere on a system with 32GB memory, with > tmpfs and md disabled in poudriere (so it's using ZFS only) and with the > ZFS ARC limited to 8GB. > > running poudriere produces many kernel log messages like this: > > Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space > Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed > Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space > Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed > Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space > Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed > Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed > Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed > > this is despite the system having a large amount of "Inact" memory > according to top(1): > > Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, 892M Free > ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M Other > 1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio > Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse > > from what i can tell, these swap errors don't cause any issues with the > poudriere build, but they do seem to hinder interactive usage by causing > long hangs. > > does anyone have some idea what's going on here? i don't really > understand why the system has used 100% of available swap space when it > has plenty of Inact memory it could free to fulfill requirements. I'm currently building www/chromium, consuming 23.1GiB of memory and 11.4GiB of swap in use. 32GiB of physical memory but not intentionally limiting ZFS arc. If you don't build such a large ports, you could lower the number of poudriere jail with option -J, for example, from auto-tuned value to reduce memory usage. FYI: When chromium built around 87%, with USE_TMPFS=yes. 172 processes: 16 running, 156 sleeping CPU: 91.2% user, 1.5% nice, 6.7% system, 0.6% interrupt, 0.0% idle Mem: 13G Active, 1670M Inact, 6499M Laundry, 6985M Wired, 347K Buf, 3490M Free ARC: 3183M Total, 393M MFU, 2102M MRU, 2980K Anon, 34M Header, 643M Other 1826M Compressed, 3471M Uncompressed, 1.90:1 Ratio Swap: 64G Total, 12G Used, 53G Free, 18% Inuse -- Tomoaki AOKI From nobody Thu Jan 11 09:23:25 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 4T9fNF6xK3z56yk9 for ; Thu, 11 Jan 2024 09:23:09 +0000 (UTC) (envelope-from ronald@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 4T9fNF67Dqz4g4H; Thu, 11 Jan 2024 09:23:09 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704964989; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tEDAoPiB0PPWDH/trfW1vADZcHLAdQzZzVAdmJ4TR/Q=; b=yNGHetEybMaGgsBWWKkJZIsCkX115F8vD3Yw/ITXO8wud+hmsijpCQXgs0koaZx8rAMQ2x ur2tNClhoyt7Z02rh3Re2R/RwJ9BemJblT/7GEGZzUClxsuA/tSYmxmPixT5gNJ6qnyGq4 tZ4NNQYoflwVlJBiDT7PMLR4dlFeJ0U6+yu0rQPt8cePWawT9f5OBdHfwwzkTPQyEPUMje X684LLcmasdBzrQLyEChi31YANBj1xiilS2mVjlaDFLToNZW/9kFTTzdEvYs+wExJYQ4jb WyFCrWxzT2L3tuoRf5O6YXRZttTFFg8vQe3bfuFEjQyYX5dY8eyJ88fNJz4A1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704964989; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tEDAoPiB0PPWDH/trfW1vADZcHLAdQzZzVAdmJ4TR/Q=; b=fTcfMoc6aa7zTkicURE1Iw0kwdbBmA2hiMzYw3TKZM+/3tPE0LJPHU5ubjs0ymA+PtlFWQ EQLNcOhd0Hqb0fC5HbN1sya5Vdseb1cv2s7gHX1ZqRp/dQqahvm38aRLK4qAutl5+fjZZk WQtMn22uhokcki9XZIfel2ipLboaMUGllKoirLIy6uvIUsJI6ymFazyGP4mBFzgDCzCtu0 pHRaVP/0mn3S0SSuWJUJoEecJ2+vNzSeYbivhYsEZyKzB5bamdIMMqjUAzFgqx35X6/wA5 oAhSYa18HwEv8yiN0XK4ezPH7aEw3nM1TD7V9II3QMidaeWZQzTM4dQuNjhJ7Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704964989; a=rsa-sha256; cv=none; b=HfW06nUx1POszmfC/BkGgL9A1bEMxqDKEJWlbkP45w8npdmK6xb69i71HvNCMYXOCARopb Tv152uRLJZhokeCWn+XK20K/XDnSmF5acOGYFfqqvRlumeRjdBX0xQiE9aaiTVSbaGT+gj 8+VX9u0GVBq2oP8SB+WrCCUtVmiQqEshphk7tnUOqpUmgv7qLDdTn2R6ZfGJtieWQXEdBf N6erhZAdBzz13GS/pFcslqZTnxfaiC9ltVHruhqc+EpZbqUyfyXczjFKGie8d0xCQsDi0H dmixOmez/BiVLC0qo5rjGQFqOBglcItwDNHJpOX4ZsuicmVcZg8WxIC1dlwydg== Received: from [IPV6:2001:1c00:2709:2010:493e:9031:fcc0:f007] (2001-1c00-2709-2010-493e-9031-fcc0-f007.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:493e:9031:fcc0:f007]) (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) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T9fNF0HNszGNl; Thu, 11 Jan 2024 09:23:08 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: <94c6cf1b-10e4-49c4-aa1d-e87f8e8c3d09@FreeBSD.org> Date: Thu, 11 Jan 2024 10:23:25 +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: poudriere: swap_pager: out of swap space To: Lexi Winter , freebsd-current@freebsd.org References: Content-Language: en-US From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/11/24 03:21, Lexi Winter wrote: > hi list, > > i'm having a recurring problem with poudriere that i hope someone might > have an idea about. > > i'm building packages with poudriere on a system with 32GB memory, with > tmpfs and md disabled in poudriere (so it's using ZFS only) and with the > ZFS ARC limited to 8GB. > > running poudriere produces many kernel log messages like this: > > Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space > Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed > Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space > Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed > Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space > Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed > Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed > Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed > > this is despite the system having a large amount of "Inact" memory > according to top(1): > > Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, 892M Free > ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M Other > 1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio > Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse > > from what i can tell, these swap errors don't cause any issues with the > poudriere build, but they do seem to hinder interactive usage by causing > long hangs. > > does anyone have some idea what's going on here? i don't really > understand why the system has used 100% of available swap space when it > has plenty of Inact memory it could free to fulfill requirements. My first guess would be that you are using a tmpfs tmp dir which uses swap as the backing-storage which is now full. Configure poudriere with USE_TMPFS=no to prevent this. Hope this helps. Regards, Ronald. From nobody Thu Jan 11 12:26:12 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 4T9kRZ35pLz55blD for ; Thu, 11 Jan 2024 12:26:18 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4T9kRY4YyBz42gn for ; Thu, 11 Jan 2024 12:26:17 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=Rh0U6BQ4; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=DzUVoeB7; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CB85E5C0116 for ; Thu, 11 Jan 2024 07:26:16 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 11 Jan 2024 07:26:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :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=fm2; t=1704975976; x=1705062376; bh=CNRU1efqLs J7hPy2ikYXEMxXz9lOFV1Q3BhHsTZrQSA=; b=Rh0U6BQ43Q23mTwYsQidLFG6Cj DhuDS/8rdZeDZZUeZPAAyJZA/VfGIYGTdELIwPRwCF5lMnwh2tazNMxZlq56iuNG SqAnVt7l3H1xyFWnb+hz37FivSJcVC8+iAAE1ddBdALTRED5kzEMjsmYPhDot6VK H8BzuH6gTTYdJg1vtRPAEdE5lTJkqi4L3156tZXJGdh/o+Y2fcZatPvXQ52ARxcM ZatpSSe2JUyh4muE55qHbPh1MLE5zFG2DhhvJ7cZcMvffw/1ZQpAWPqY0IA5NaPn ao2j4XCWbT83+9+PCTfEASy3e6wFZmA64WCogFOq0ieNoissURJ8d93UklIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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= fm2; t=1704975976; x=1705062376; bh=CNRU1efqLsJ7hPy2ikYXEMxXz9lO FV1Q3BhHsTZrQSA=; b=DzUVoeB7kmOtBWHaqNQnCdaFyt8uLA921zFlJ3iz7xuO UIOah1f2WEO5UA2EwYSrxwX04cDug3A1nzuUT0oSSalx9ToUanPolrE1l65DsFJ6 MCKfnXKtC6gHsmrwbJMGeVzTx+s2IwAeqvNbmf5hMY/k3wi2GEopycfDF8WEsU+0 elB7bwZIR5uuRhDYA892q3Bu8TCE+o06WBmMW/U9rAbs7ex27UCrso2Ez9OY0E4P Pwt1lT48clIUpoIK9wR3fKCwfhzF6t6rw7regu/gfhtbfjDlFODyTeTKdtTFifX5 /NYYxqIvDSLdHYPb2ZOsZz8PVHnqWsNGW9jtJvVkVQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeifedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 11 Jan 2024 07:26:16 -0500 (EST) Date: Thu, 11 Jan 2024 12:26:12 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: poudriere: swap_pager: out of swap space Message-ID: Mail-Followup-To: freebsd-current@freebsd.org 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4T9kRY4YyBz42gn On Thu, Jan 11, 2024 at 02:21:19AM +0000, Lexi Winter wrote: >hi list, > >i'm having a recurring problem with poudriere that i hope someone might >have an idea about. > >i'm building packages with poudriere on a system with 32GB memory, with >tmpfs and md disabled in poudriere (so it's using ZFS only) and with the >ZFS ARC limited to 8GB. > >running poudriere produces many kernel log messages like this: > >Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space >Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed >Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space >Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed >Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space >Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed >Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed >Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed I also have a 32GB system. My way of dealing with this is to set, in the global poudriere.conf USE_TMPFS=all TMPFS_BLACKLIST="rust llvm* electron* libreoff* iridiu* chromium* qt* gcc*" TMPFS_BLACKLIST_TMPDIR=${BASEFS}/data/cache/tmp PARALLEL_JOBS=1 ALLOW_MAKE_JOBS=yes and, in /etc/sysctl.conf # filesystem vm.pageout_oom_seq=120 vm.pfault_oom_attempts=-1 vm.pageout_update_period=0 # avail memory = 33303379968 (31760 MB) / 8 = minimum for vfs.zfs.arc.max vfs.zfs.arc_max=4162922496 The most important settings out of the lot is PARALLEL_JOBS=1 and ALLOW_MAKE_JOBS=yes otherwise building things like rust overwhelm the system. This is on 14-stable amd64. The TMPFS_BLACKLIST_TMPDIR= is on SSD (not a particularly performant one, but it's quicker than spinning rust) -- From nobody Thu Jan 11 13:30: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 4T9lsS6xr2z55lBV for ; Thu, 11 Jan 2024 13:30:20 +0000 (UTC) (envelope-from SRS0=kULW=IV=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9lsS3HZVz4HwR; Thu, 11 Jan 2024 13:30:20 +0000 (UTC) (envelope-from SRS0=kULW=IV=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 32336D7894; Thu, 11 Jan 2024 14:30:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1704979812; bh=5Fpf5ZtRsn54FgDtCn8t14WffSVVpxIOPokj8r+t7Fk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=nEvjhFnPEYZO8+0cjxo5laAPocsmKENmkzb1NBXpGSDk8ZCAQLx/qi5cmxSZVi1gy 5rAvQPUXLpM1sTXetTBP5mnJX56lfH7y35GnPh2vqKZWhu0p4PtGK/YfgSZrVmFz6e IzZna4d6UyWZScmWDtBsN9DEuADE0yW2JU2k3/8s= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 0C1C2D7888; Thu, 11 Jan 2024 14:30:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1704979811; bh=5Fpf5ZtRsn54FgDtCn8t14WffSVVpxIOPokj8r+t7Fk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=wtMdBu+ktb6NwHJe/RKXAD6uOEPLtOivkCqTga4GwotTE4Lo8VM9UcJm2FmE9MYpo VO52ZFeXowG3HkZgOYyhdJKa0HBdTOGm+Aed6cxaWfmRf7zmF+MutvcqJRqo8P8h2k NMdKoDbgmRTzfFNC6kwF51xhIkxairgr+NZr8vmQ= Message-ID: <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> Date: Thu, 11 Jan 2024 14:30:10 +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: noatime on ufs2 To: Tomoaki AOKI , Alexander Leidinger Cc: Mark Millard , olce@freebsd.org, Current FreeBSD References: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> Content-Language: cs-Cestina, en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4T9lsS3HZVz4HwR 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:42000, ipnet:94.124.104.0/21, country:CZ] On 11/01/2024 09:54, Tomoaki AOKI wrote: > On Thu, 11 Jan 2024 08:36:24 +0100 > Alexander Leidinger wrote: [..] >> There's one possibility which nobody talked about yet... changing the >> default to noatime at install time in fstab / zfs set. >> >> I fully agree to not violate POLA by changing the default to noatime in >> any FS. I always set noatime everywhere on systems I take care about, no >> exceptions (any user visible mail is handled via maildir/IMAP, not >> mbox). I haven't made up my mind if it would be a good idea to change >> bsdinstall to set noatime (after asking the user about it, and later >> maybe offer the possibility to use relatime in case it gets >> implemented). I think it is at least worthwile to discuss this >> possibility (including what the default setting of bsdinstall should be >> for this option). [..] > A different aspect of view. > Nowadays, storages are quickly moving from HDD, aka spinning rust, to > SSD. > And SSD has a risk of sudden-death of wearing out. In ancient days, HDD > dies not suddenly and at least some cases admins could have time to > replace suspicious drives. But SSD dies basically suddenly. > > IMHO, this could be a valid reason to violate POLA. In limited use > cases, atime is useful, at the cost of amplified write accesses. > But in most cases, it doesn't have positive functionality nowadays. > > Anyway, we should have time to discuss whether it should be done or not > until upcoming stable/15 branch. stable/14 is already here and it > wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point > to introduce this, unlike discussion about vi and ee on forums. The default values change over time as the needs of people, programs and hardware change. Many values for sysctls changed over time. If "noatime" can help people to not trash SSD / SD storage, I can imagine that bsdinstall will detect the storage type (simple guess can be made by diskinfo -v) and offer a "noatime" option that the user can check/uncheck. This option can be pre-selected for flash based storage. I don't care defaults for my-self, I can change them, but sane defaults should be beneficial for new users without much background knowledge. Kind regards Miroslav Lachman From nobody Thu Jan 11 13:58:56 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 4T9mVj2v8tz55pRn for ; Thu, 11 Jan 2024 13:59: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 4T9mVj0wXhz4MD2 for ; Thu, 11 Jan 2024 13:59: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 40BDwvoU054960; Thu, 11 Jan 2024 07:58:57 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1704981537; bh=NDmKjn+kx+2dJwpwB9UEe4Bae3kw2gQQV2CVpQ2PPnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hF1Si5/OQvW09awwy5uMDGvFxNtihp7zSEhf20xAOsZY8MAiR7bcK6GO6WV6F9IQf QRPCVn0b/DyOlJOXK7rTDqqTe356pkynr5gkhuc82PQUWT9q566oRbskS6tCKZSUmL 4DV0pwFTzvoftkNkzpR5jHx5fqnC2vFx0fgKGcyIQ1QHHKG4+8eGUB8rvBVEWX2RLR +gkjzgQFZQIyAldBXSUcl1BKasersTXOXQ489yNgtJtTFPXljk274f1LUiANoCTa3U hUrrR/Nr+530iEMylSNNEqHI2iCKsFAhl0fr8bncZoEfcm3EH0t916u0+i1oBKoH+w KFIh3vHZH5qTA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id GuglFSH0n2Wu1gAAs/W3XQ (envelope-from ); Thu, 11 Jan 2024 07:58:57 -0600 From: Mike Karels To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Tomoaki AOKI , Current FreeBSD Subject: Re: noatime on ufs2 Date: Thu, 11 Jan 2024 07:58:56 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> In-Reply-To: <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> References: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> 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: 4T9mVj0wXhz4MD2 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 11 Jan 2024, at 7:30, Miroslav Lachman wrote: > On 11/01/2024 09:54, Tomoaki AOKI wrote: >> On Thu, 11 Jan 2024 08:36:24 +0100 >> Alexander Leidinger wrote: > > [..] > >>> There's one possibility which nobody talked about yet... changing the= >>> default to noatime at install time in fstab / zfs set. >>> >>> I fully agree to not violate POLA by changing the default to noatime = in >>> any FS. I always set noatime everywhere on systems I take care about,= no >>> exceptions (any user visible mail is handled via maildir/IMAP, not >>> mbox). I haven't made up my mind if it would be a good idea to change= >>> bsdinstall to set noatime (after asking the user about it, and later >>> maybe offer the possibility to use relatime in case it gets >>> implemented). I think it is at least worthwile to discuss this >>> possibility (including what the default setting of bsdinstall should = be >>> for this option). > > [..] > >> A different aspect of view. >> Nowadays, storages are quickly moving from HDD, aka spinning rust, to >> SSD. >> And SSD has a risk of sudden-death of wearing out. In ancient days, HD= D >> dies not suddenly and at least some cases admins could have time to >> replace suspicious drives. But SSD dies basically suddenly. >> >> IMHO, this could be a valid reason to violate POLA. In limited use >> cases, atime is useful, at the cost of amplified write accesses. >> But in most cases, it doesn't have positive functionality nowadays. >> >> Anyway, we should have time to discuss whether it should be done or no= t >> until upcoming stable/15 branch. stable/14 is already here and it >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point >> to introduce this, unlike discussion about vi and ee on forums. > > The default values change over time as the needs of people, programs an= d hardware change. Many values for sysctls changed over time. > If "noatime" can help people to not trash SSD / SD storage, I can imagi= ne that bsdinstall will detect the storage type (simple guess can be made= by diskinfo -v) and offer a "noatime" option that the user can check/unc= heck. This option can be pre-selected for flash based storage. > I don't care defaults for my-self, I can change them, but sane defaults= should be beneficial for new users without much background knowledge. > > Kind regards > Miroslav Lachman I like the idea of an option in bsdinstall, but I don't think it is neces= sary to check the storage type. It could simply default to noatime. I think we should automatically use noatime on SD card images (where bsdi= nstall doesn't get used). Separately, I think a relatime option would be a good compromise, and I w= ould probably use it. Mike From nobody Thu Jan 11 17:15:19 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 4T9rs926BGz56Vkp for ; Thu, 11 Jan 2024 17:15:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9rs90clqz50FB; Thu, 11 Jan 2024 17:15:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 40BHFJpV049601; Thu, 11 Jan 2024 09:15:19 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 40BHFJ3Q049600; Thu, 11 Jan 2024 09:15:19 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202401111715.40BHFJ3Q049600@gndrsh.dnsmgr.net> Subject: Re: noatime on ufs2 In-Reply-To: To: Alexander Leidinger Date: Thu, 11 Jan 2024 09:15:19 -0800 (PST) CC: Mark Millard , olce@FreeBSD.org, Current FreeBSD X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4T9rs90clqz50FB 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:10494, ipnet:65.75.216.0/23, country:US] > Am 2024-01-10 22:49, schrieb Mark Millard: > > > I never use atime, always noatime, for UFS. That said, I'd never > > propose > > changing the long standing defaults for commands and calls. I'd avoid: > > [good points I fully agree on] > > There's one possibility which nobody talked about yet... changing the > default to noatime at install time in fstab / zfs set. Perhaps you should take a closer look at what bsdinstall does when it creates a zfs install pool and boot environment, you might just find that noatime is already set everywhere but on /var/mail: /usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O compress=lz4 -O atime=off} /usr/libexec/bsdinstall/zfsboot: /var/mail atime=on > > I fully agree to not violate POLA by changing the default to noatime in > any FS. I always set noatime everywhere on systems I take care about, no > exceptions (any user visible mail is handled via maildir/IMAP, not > mbox). I haven't made up my mind if it would be a good idea to change > bsdinstall to set noatime (after asking the user about it, and later > maybe offer the possibility to use relatime in case it gets > implemented). I think it is at least worthwile to discuss this > possibility (including what the default setting of bsdinstall should be > for this option). Little late... iirc its been that way since day one of zfs support in bsdinstall. > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jan 11 19:56:30 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 4T9wR81y54z56qJ8 for ; Thu, 11 Jan 2024 19:56:36 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4T9wR72l5Mz45qp; Thu, 11 Jan 2024 19:56:35 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:7400:8808:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-current@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 40BJuUVs045686; Thu, 11 Jan 2024 19:56:30 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 40BJuURB045685; Thu, 11 Jan 2024 19:56:30 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401111956.40BJuURB045685@donotpassgo.dyslexicfish.net> Date: Thu, 11 Jan 2024 19:56:30 +0000 Organization: Dyslexic Fish To: olce@FreeBSD.org, imp@bsdimp.com Cc: freebsd-current@FreeBSD.org Subject: Re: noatime on ufs2 References: <1749331.ETpRK2a2Mi@ravel> <2136329.mxFCRLsXLg@ravel> In-Reply-To: <2136329.mxFCRLsXLg@ravel> User-Agent: Heirloom mailx 12.4 7/29/08 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: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Thu, 11 Jan 2024 19:56:30 +0000 (GMT) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.26 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.56)[-0.564]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCPT_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jamie]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4T9wR72l5Mz45qp Olivier Certner wrote: > Both the examples above prompt some straight objections on the current usefulness of "atime". First, unless you've disabled building the locate database in cron (enabled by default, on a weekly basis), access times on directories lose most of their usefulness. Second, if using an IDS, I'm afraid it's just game over. And even if you think you are not, '460.pkg-checksum' at least is readily there to much complicate, or even prevent you from, getting package usage information this way (it is enabled by default, and on a daily basis). I've often wished there was the ability to set a process to "noatime" - where all accesses to the filesytem by the process and its children don't alter atime. It would be handy for those cases you describe above, such as backups and locate, but these days, where it matters, and is suitable, I instead create a filesystem snapshot, and run the process on that instead. (which is how "live" backups should be done anyway!) Cheers, Jamie From nobody Thu Jan 11 22:01:21 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 4T9zCM0f4Yz56b7h for ; Thu, 11 Jan 2024 22:01:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 4T9zCL6615z4KRq for ; Thu, 11 Jan 2024 22:01:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40d6b4e2945so67857605e9.0 for ; Thu, 11 Jan 2024 14:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1705010493; x=1705615293; 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=F6zr19gB6JE3cDJs01yzwr0q0xpjVlb9lYfI8MvDV9I=; b=PDGqSt/0dtKI7KOdhAjBHljT07a0pkovQd5CMaqFkx9fyPw2fgo4Pb1mZ10pFTtR5n Ou2f1khl06+zvRu/HxgMVbsCSqsNFrlfY2G1aK9GUHFfHOtRI7TjZQO4vdO79Fm4giCk bcb/DEH3pRaQ8+oAwGze3VyYl5/PAPP5Yzcgl63VfUnhQ3kkiBsrmSSiRY+XgEPcuk6U S9Z20mb0voyOtEW81MYUu4PPj157/1k4mWGqo5qqVSFgeJ/WzhboPFrmf5Iup4yKdwyR XhtRvw2SDRMQWI5BpzFCbXZF02hdh3uyf0NqNxBwH1niGY8q6r9vckoZxmr63gPZd9bq Gdlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705010493; x=1705615293; 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=F6zr19gB6JE3cDJs01yzwr0q0xpjVlb9lYfI8MvDV9I=; b=BgR5fIFzwb5YE2FB2Vv1RP818wyNPQthfydaRGfpVXBJe5Jeqd87MLZ+DoD2xul1d/ s4T51VKim7c5PFXsCT0Mm+y/SVvE01LkBaiXziBjvM38ajY594iv2E+pFTIYF494OFQw P9b6vD19EaAKtOPUkTqcFxFYsUYweCnWhSijGZBPDwyJScDpE0mOrONOusNlxSgwpA54 xWEQ+JqGtawughKhP3u5Wqy5BjCdU2G04YAX4La0HZ4kJnginTIQyNpCwmb2OO3uadbq KaSeoMB4e6IYxtPCBxzN88C26orop96GHZgDY/rzquKz68r/+VnfcR4pzg3r1pZ7pX4J 5YHQ== X-Gm-Message-State: AOJu0Yy6VQlHfLpp9DPl0G47P/iX9MC8raJK8wm7cw/cV2WgsKkkldG8 CSPq/H+AvlHbe287GRcr5gFyw8r22hmWhxaTWiyy25nGwyeXTg== X-Google-Smtp-Source: AGHT+IHQ+itKzg3uzkaKjtWCgFJHKq6RX/ZwDk9l+An6z8nxWa70osR+TqRfLpC5/uhI1q1+A8qOLGTsrJHQ/GiYFOk= X-Received: by 2002:a05:600c:c9:b0:40e:629a:b7c9 with SMTP id u9-20020a05600c00c900b0040e629ab7c9mr183468wmm.40.1705010492502; Thu, 11 Jan 2024 14:01:32 -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: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> In-Reply-To: <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> From: Warner Losh Date: Thu, 11 Jan 2024 15:01:21 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Mike Karels Cc: Miroslav Lachman <000.fbsd@quip.cz>, Tomoaki AOKI , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000be8c39060eb2b0c2" X-Rspamd-Queue-Id: 4T9zCL6615z4KRq 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] --000000000000be8c39060eb2b0c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2024 at 6:59=E2=80=AFAM Mike Karels wrote= : > On 11 Jan 2024, at 7:30, Miroslav Lachman wrote: > > > On 11/01/2024 09:54, Tomoaki AOKI wrote: > >> On Thu, 11 Jan 2024 08:36:24 +0100 > >> Alexander Leidinger wrote: > > > > [..] > > > >>> There's one possibility which nobody talked about yet... changing the > >>> default to noatime at install time in fstab / zfs set. > >>> > >>> I fully agree to not violate POLA by changing the default to noatime = in > >>> any FS. I always set noatime everywhere on systems I take care about, > no > >>> exceptions (any user visible mail is handled via maildir/IMAP, not > >>> mbox). I haven't made up my mind if it would be a good idea to change > >>> bsdinstall to set noatime (after asking the user about it, and later > >>> maybe offer the possibility to use relatime in case it gets > >>> implemented). I think it is at least worthwile to discuss this > >>> possibility (including what the default setting of bsdinstall should = be > >>> for this option). > > > > [..] > > > >> A different aspect of view. > >> Nowadays, storages are quickly moving from HDD, aka spinning rust, to > >> SSD. > >> And SSD has a risk of sudden-death of wearing out. In ancient days, HD= D > >> dies not suddenly and at least some cases admins could have time to > >> replace suspicious drives. But SSD dies basically suddenly. > >> > >> IMHO, this could be a valid reason to violate POLA. In limited use > >> cases, atime is useful, at the cost of amplified write accesses. > >> But in most cases, it doesn't have positive functionality nowadays. > >> > >> Anyway, we should have time to discuss whether it should be done or no= t > >> until upcoming stable/15 branch. stable/14 is already here and it > >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point > >> to introduce this, unlike discussion about vi and ee on forums. > > > > The default values change over time as the needs of people, programs an= d > hardware change. Many values for sysctls changed over time. > > If "noatime" can help people to not trash SSD / SD storage, I can > imagine that bsdinstall will detect the storage type (simple guess can be > made by diskinfo -v) and offer a "noatime" option that the user can > check/uncheck. This option can be pre-selected for flash based storage. > > I don't care defaults for my-self, I can change them, but sane defaults > should be beneficial for new users without much background knowledge. > > > > Kind regards > > Miroslav Lachman > > I like the idea of an option in bsdinstall, but I don't think it is > necessary > to check the storage type. It could simply default to noatime. > > I think we should automatically use noatime on SD card images (where > bsdinstall > doesn't get used). > > Separately, I think a relatime option would be a good compromise, and I > would > probably use it. > I think these are sensible steps. We already do something similar for ZFS. Warner --000000000000be8c39060eb2b0c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 11, 2024 at 6:59=E2=80=AF= AM Mike Karels <mike@karels.net&g= t; wrote:
On 11 = Jan 2024, at 7:30, Miroslav Lachman wrote:

> On 11/01/2024 09:54, Tomoaki AOKI wrote:
>> On Thu, 11 Jan 2024 08:36:24 +0100
>> Alexander Leidinger <Alexander@Leidinger.net> wrote:
>
> [..]
>
>>> There's one possibility which nobody talked about yet... c= hanging the
>>> default to noatime at install time in fstab / zfs set.
>>>
>>> I fully agree to not violate POLA by changing the default to n= oatime in
>>> any FS. I always set noatime everywhere on systems I take care= about, no
>>> exceptions (any user visible mail is handled via maildir/IMAP,= not
>>> mbox). I haven't made up my mind if it would be a good ide= a to change
>>> bsdinstall to set noatime (after asking the user about it, and= later
>>> maybe offer=C2=A0 the possibility to use relatime in case it g= ets
>>> implemented). I think it is at least worthwile to discuss this=
>>> possibility (including what the default setting of bsdinstall = should be
>>> for this option).
>
> [..]
>
>> A different aspect of view.
>> Nowadays, storages are quickly moving from HDD, aka spinning rust,= to
>> SSD.
>> And SSD has a risk of sudden-death of wearing out. In ancient days= , HDD
>> dies not suddenly and at least some cases admins could have time t= o
>> replace suspicious drives. But SSD dies basically suddenly.
>>
>> IMHO, this could be a valid reason to violate POLA. In limited use=
>> cases, atime is useful, at the cost of amplified write accesses. >> But in most cases, it doesn't have positive functionality nowa= days.
>>
>> Anyway, we should have time to discuss whether it should be done o= r not
>> until upcoming stable/15 branch. stable/14 is already here and it<= br> >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be th= e point
>> to introduce this, unlike discussion about vi and ee on forums. >
> The default values change over time as the needs of people, programs a= nd hardware change. Many values for sysctls changed over time.
> If "noatime" can help people to not trash SSD / SD storage, = I can imagine that bsdinstall will detect the storage type (simple guess ca= n be made by diskinfo -v) and offer a "noatime" option that the u= ser can check/uncheck. This option can be pre-selected for flash based stor= age.
> I don't care defaults for my-self, I can change them, but sane def= aults should be beneficial for new users without much background knowledge.=
>
> Kind regards
> Miroslav Lachman

I like the idea of an option in bsdinstall, but I don't think it is nec= essary
to check the storage type.=C2=A0 It could simply default to noatime.

I think we should automatically use noatime on SD card images (where bsdins= tall
doesn't get used).

Separately, I think a relatime option would be a good compromise, and I wou= ld
probably use it.

I think these are sens= ible steps. We already do something similar for ZFS.

Warner=C2=A0
--000000000000be8c39060eb2b0c2-- From nobody Fri Jan 12 07:28:43 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 4TBCp236B2z56Dkj for ; Fri, 12 Jan 2024 07:28:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4TBCp11g2Wz4MjD for ; Fri, 12 Jan 2024 07:28:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tzb2aFqL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705044534; bh=UsTkBgl2aIHXWUfBmH7YA2LOBsnI8xYGa3HkJcmhwzc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=tzb2aFqL8J6a58FUjngyWC53CkgeuowCyv4qZhIrEQk7q/5CkEgAxsj1sYLkaHp+d+D2TKn72EKv32q0QCNsk/vc3d1c2vEVqnTlQSFHcfUeBSLwxBSft0f2VwT7YJKxKVKA/gE7eqH8sAFWmhVLvCnSe6/7SP7g29ZIb3YWPpM+W5DTey8ZaHOjdx3Q8E+8iBrMRP2MdmVLPe121hesRQ9mRdb7UF26dy6rd4caIi6qhjiiTOwK0VeUffOHx8E4CsIGSqPhL+X+2CItH2CoGOYa+4CQxhMypyawZjkFonD10WAGrJtzf3t4uL6hIul79Xa0uoL1zn7Zhx1o/RaDbQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705044534; bh=+L2cWswTUmUq83Hfrj+a4fJVQW9iPvG2dqKwlEewoi4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=B7Qb1DvJRjR9uCQHh5pfdijaNwoL0IQPTPg4169zegwi1GJav9/7+KRkYaBsNKI+Zo1Rt4Padaf935u9bySNQYNMIl4TaIzHvU6t+PuMy1rzPpQIT3hQSVZYZVPBOYtyBhlbNZo3bkWr0ZOj3cfmWPkbKsXUKIr8sbhc/EQgwF9vk5MtuuzHBqDIic1zitcMl1JHZjkbcEkYw9NzplpJZeT0qELiLZJHjgeaIhyZJaAkFCAIcKvL47IelNY6HW6HdcIc49fC6STrBr02LKJ9LZ2/ueV9Em7aR1wCM+x6KLhiSmTF8ga+R/9d+xTP5NcgtCAhbtX1Cy5EdPojwQHM8g== X-YMail-OSG: eoFZzREVM1lufV47wrpZKGE9yhzYYNkdQnHoHOFdFKDfpA0UsGrbBGbGn_BorUW chW_1viruHDGMFC4mCdgxO7_DG.R_SxpCrvDA45FF9L_6Oyi40s6666xFUbl3CFmbzcSX.j7RiyE hEV3.BVOeU7xeUfUkxFd0tSUTSlV2A4RkNKzJZp8VVRd8Kq0tqWQKrGGfQWREJn0nAYkIHNmpRLK 4kgNZK_w.nWRJcWP3iv.oWDGAAVvlGJlp8lZ.2ASVQPjiv92z8_bfxi2yv_lpkKDli82ldiyKVOq HWAATJBLotB1XOJmBAv13XE54zZzIIK0kYU0pkoWxw16rn3VHJIkS3_AlKIwGVroLSgL40lu7m7o uI1xgbMiRx3YfY5PC2vVBzrgOAUeYOo_N2EqbvTy2d_BYn2UuNk_jXyPYikQyQF5KuPRO8bd2DnA yEomP98sZeO39.gSCwJm009GX54f._vwfRcCubayHntHG9aL1iYMEqi_MjgsOBOEoHkWYw3kuhTt 11feQ0tgZZ7J7hVFGRtsb6tsP1DvbTSRgFd8NDH890kGL_FVMDB2cuqoG4VUtE79gk9lYn.Wp1xk 8_gbpkgGnzi3hRtz_y.sKhNYuQEc9dRhzjZ1NYE159MsD_RR5g2JvpvOoGXoXXFD1QiqHeeyU65I Mc80czsvlnp0muNB0y7p5F6c0v9PRhpz91HuGyGPwmsp7prgsfL7IPKSJolSya1zl5zblrJ29q.z VOzWW5otg__VwBRpFjenzvhFi7Yd2VHERidpyM11TRGTqRSbbkY3ZPKyprwj_qC_HYgjILeQCJCu JfAdMOBIeBo1U_bnCGP.01t4BQVBxbRfqAczeeccSWzkETZe_VkFxSZrHann_WVuutv8pN2.XGes 2U996FIFPrqoAnMUl0KX.vD.mcBjSrZHccVMeME9KZqJ0VrmqaNZyygPS498Zs3sgPohvHhyjU2T HkY.CeJfuPaxdzPvUdl172ANk7UtdAwgb_Cmajh_U64iQt1sDYrhlAfjUu4dTQxLmUwKm0.ukgC3 Y2P0lx5FCSrrMd8bp__r04IfypbOjx9FKwJBMFQ71FSnjkuk1AqP1xPs8i4OQVACib6LztLR.Nyw m5NR6paalGU272cUZq4vr_ye6BS1lY.8bNR5kAmfbxpfTFqcdgUI2gFYafGLnn4AQKDcTSJnQAtZ lL9_rA2hI4aW2qOIquibO5HUvapMZHpoJWUMyMgRNG8j_F5A6zN.P2y2mHSUWdS5sHt.tHydxynH jzeeJ3eznWLCdvvA0YppGG2WL4qcipkh8Igtc3uNIQao2Zc9p.s2nzIcfccg.DKtE5Ki33yFB_Ps .999rATpio_sPr0Y1NVXY8NEx063xmzlOy9BFUSOIh7vOmonVQaepFc.M1u.KANt77rQOOEoMax4 lP05bHlHXSjfG_If4p_pRwU1Fqh1mEcLESAwD9.f3RBPpcy1nBqI0bJAZyrqSt1e2_ZceuZ72UnL 56kH_eJpDGU.DgJesvrMO5C0YDoN9tw8bDpmNLl.buuRxufurc8EqJ7OD_.9tNz02Gpf2_.uIy7N prkYY9B2qm5SFaFDSr1u6V0pnqQdR8j2gDSC.3XZmSNCteFm3hwyeEXASXLCyVNyCRmTGOVIghbG _MX_BVoXjjgb4AofGJfOVnyppO.3gnCeW8iI.L8vJJsEPa7hldGJC7H2c8thKr9AG3lrvi511cQ3 WJQ7S1lIYgWWlGCPtTpgOZB34iZO1CmyUWr5KphyltmYvv4KNOOLJ66xUVdsAyDCVDaX2i0aaLqH _182uXNT_keaZn24zY8chBvictZSf5Uplz.Fpj8wtrhtOSC8x1BmLykgw5fGsndUTSUNdjqg1YP. J4AcJajI30rgi1buqss4A1Hx_QNUQ7ogzBvVPjQupmbpgqz1wo3LGy5tRMacMmmSEXdxbVWxMa0X S5fzF.XVHTvbUGeE0z4yF9kX71Sh1rOY4Nkhvi3qHlz0dRpeNL5A00ScKFNkHEVSOzLoSgw2BF_k IJK50DQmB9lB_gENShOx9xzV2xq9JQXbQpof7uoq55rHP2zWPy1cqnF67ODnn3HTHikvjOlbEVqX PJTk2uZqybi9l2.SKP9dG_HoIbhgbJiJCbWne9HJUbO4FANh1m4irmuumY3YfFfmmGYGJvcIVpXF pMoRmvNgT4fOMYHWhf8XKFPqHcATaxLsMilSrvEbTr_23tE0Db8SPSf2ZrpKUG7jVW0kLo9c3Fmb aRYGZxsQo8mK0I7cmwOfoSq0awnyDS9_8y_HTV8_eadeDuDXHkRkzwl.1S_2ZKEsFNIikK9I0alS r X-Sonic-MF: X-Sonic-ID: 1de3f01f-a97f-4bec-ad68-85bc58af8fbe Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 07:28:54 +0000 Received: by hermes--production-gq1-78d49cd6df-vkd75 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 562b56eca66319da0257e7876cb45201; Fri, 12 Jan 2024 07:28:54 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 Message-Id: Date: Thu, 11 Jan 2024 23:28:43 -0800 To: "Rodney W. Grimes" , Current FreeBSD X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from] X-Rspamd-Queue-Id: 4TBCp11g2Wz4MjD Rodney W. Grimes wrote on Date: Thu, 11 Jan 2024 17:15:19 UTC : > > Am 2024-01-10 22:49, schrieb Mark Millard: > >=20 > > > I never use atime, always noatime, for UFS. That said, I'd never=20= > > > propose > > > changing the long standing defaults for commands and calls. I'd = avoid: > >=20 > > [good points I fully agree on] > >=20 > > There's one possibility which nobody talked about yet... changing = the=20 > > default to noatime at install time in fstab / zfs set. >=20 > Perhaps you should take a closer look at what bsdinstall does > when it creates a zfs install pool and boot environment, you > might just find that noatime is already set everywhere but > on /var/mail: >=20 > /usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=3D-O = compress=3Dlz4 -O atime=3Doff} > /usr/libexec/bsdinstall/zfsboot: /var/mail atime=3Don >=20 > >=20 > > I fully agree to not violate POLA by changing the default to noatime = in=20 > > any FS. I always set noatime everywhere on systems I take care = about, no=20 > > exceptions (any user visible mail is handled via maildir/IMAP, not=20= > > mbox). I haven't made up my mind if it would be a good idea to = change=20 > > bsdinstall to set noatime (after asking the user about it, and later=20= > > maybe offer the possibility to use relatime in case it gets=20 > > implemented). I think it is at least worthwile to discuss this=20 > > possibility (including what the default setting of bsdinstall should = be=20 > > for this option). >=20 > Little late... iirc its been that way since day one of zfs support > in bsdinstall. >=20 > > --=20 > > http://www.Leidinger.net Alexander@Leidinger.net: PGP = 0x8F31830F9F2772BF > > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF The UFS based snapshots are more of a mix. The one that I just dd'd to media has: # more /etc/fstab # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw 1 = 1 /dev/msdosfs/EFI /boot/efi msdosfs rw,noatime = 0 0 tmpfs /tmp tmpfs rw,mode=3D1777 0 = 0 /dev/label/growfs_swap none swap sw 0 = 0 So the UFS does not have noatime set up for its mount but the msdosfs does. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 12 08:08:12 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 4TBDh34KQ5z56JhB for ; Fri, 12 Jan 2024 08:08:51 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 4TBDh31B3sz4RXX; Fri, 12 Jan 2024 08:08:51 +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=1705046917; 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=MOGgk0QQL/fIjC0yRekWkXitKrR0iHZYi4CPuKsc3lU=; b=wuSOn5eoE3KvICbvxQxTciOt4ZRWyBGnYNwXJ/4DtqnegEdidmmgMCqN7yBO1msTNoaAH/ 9i0ejGgS/slof8VneA+l3WH3D3pWpqrElxknW9qnP60zEhMVHQY9Ol9uiAljz67R9bLs6Z kx1pRNUcxDHyhaafbODTv1TGcxv9vBDjN8ZD5Xem+Aj8xcLCiFXSXPyh8eyTUAEZFm4d/R 8DSq4opYCflcu77iaPX2nWKyARCx3noafx6Tv9cRsjlrO601+PPz9yYRazG8dcLiZzPZyf N0gHtRUXLDDtfejenlmh4PSP2BfVH2DAdVCovOjPfgwf/YEtWxVTR7+s/MMNBA== Date: Fri, 12 Jan 2024 09:08:12 +0100 From: Alexander Leidinger To: "Rodney W. Grimes" Cc: Mark Millard , olce@freebsd.org, Current FreeBSD Subject: Re: noatime on ufs2 In-Reply-To: <202401111715.40BHFJ3Q049600@gndrsh.dnsmgr.net> References: <202401111715.40BHFJ3Q049600@gndrsh.dnsmgr.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_9423ef4cea3d84be08c8eda0bc982c46"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4TBDh31B3sz4RXX 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:2a00:1828::/32, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_9423ef4cea3d84be08c8eda0bc982c46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-01-11 18:15, schrieb Rodney W. Grimes: >> Am 2024-01-10 22:49, schrieb Mark Millard: >> >> > I never use atime, always noatime, for UFS. That said, I'd never >> > propose >> > changing the long standing defaults for commands and calls. I'd avoid: >> >> [good points I fully agree on] >> >> There's one possibility which nobody talked about yet... changing the >> default to noatime at install time in fstab / zfs set. > > Perhaps you should take a closer look at what bsdinstall does > when it creates a zfs install pool and boot environment, you > might just find that noatime is already set everywhere but > on /var/mail: > > /usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O > compress=lz4 -O atime=off} > /usr/libexec/bsdinstall/zfsboot: /var/mail atime=on While zfs is a part of what I talked about, it is not the complete picture. bsdinstall covers UFS and ZFS, and we should keep them in sync in this regard. Ideally with an option the user can modify. Personally I don't mind if the default setting for this option would be noatime. A quick serach in the scripts of bsdinstall didn't reveal to me what we use for UFS. I assume we use atime. >> I fully agree to not violate POLA by changing the default to noatime >> in >> any FS. I always set noatime everywhere on systems I take care about, >> no >> exceptions (any user visible mail is handled via maildir/IMAP, not >> mbox). I haven't made up my mind if it would be a good idea to change >> bsdinstall to set noatime (after asking the user about it, and later >> maybe offer the possibility to use relatime in case it gets >> implemented). I think it is at least worthwile to discuss this >> possibility (including what the default setting of bsdinstall should >> be >> for this option). > > Little late... iirc its been that way since day one of zfs support > in bsdinstall. Which I don't mind, as this is what I use anyway. But the correct way would be to let the user decide. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_9423ef4cea3d84be08c8eda0bc982c46 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmWg83wACgkQEg2wmwP4 2IbcTg//RmfEBJV+eG9a0zxjb9cSn6G1oEa5ItVtJAlO2nOagkXrfOud7mbxRD4Z QuMDnfN4NkOnEjzHB94dHE3OimZjkscauXmPFRkREuG72nZPzrpNTctDtV1+MK66 cS0BiTjrtWs3W+JwEOJMFsRYQRwJPlxsfYLUjoNJK5GWn1nIOKxnVs7ih5tv0K3Q W86MNrFa4WZsNZZxDB1C8OSgymjQ40wmqpNtYy1QlIEMTSrXrDQChF3Q6OK6xWms bpQbYIVdvlNAlnXqpXsF1duzOmUgn4Bq08mH517aP+IUblBqLeuNGb15ySif2XRf QERQcPy1U7AfhDlJ1A1CWCACYnxNAaUI+nMiZbpRt4sY/r8eUxr4ZAwNYUk4A4Eb qwxOVIQQBJSiQtme27+x1fmsyojwZrPHPHSLzBjF9mTLOdMUcXL4RChJRjG71R+U VLicWxyOag7nKCSbGnNP3HKcWoNgzsT/7bPJTVTjifPKh3z4R6lJj0o+PYl7ZUFA HZsaCOqsYsZPJ95zgdMBrrykHrRtl4gCIghg/4uhz9sobLCq2kBB148AE+Hb4/iL K5BPdQPAVssptG1RnB6d3vCdVr+yrto9HiF5Q5HQQe//9GxJrben2aD3TKBkspZu SNxZUFPC6QRiXasMyiEqte7Yj0AyTKUTvMutJmgevqfAyPeZ+hw= =aLUJ -----END PGP SIGNATURE----- --=_9423ef4cea3d84be08c8eda0bc982c46-- From nobody Fri Jan 12 17:15:41 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 4TBSq46KqMz57BsC for ; Fri, 12 Jan 2024 17:15:44 +0000 (UTC) (envelope-from des@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 4TBSq45XdPz4cGj; Fri, 12 Jan 2024 17:15:44 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705079744; 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=w0Bq3wwww9vp//zfOSZt1KYvFXq4PBAMCs2wI+RG6As=; b=GThmMArZvhsFYZ7cyHEHZ1I6oAJUtpMGlHQiJPn5uQLMXJODvjz1lI2n7Zc3zOevn8rHkj zpNq9LKt7G7uox6oYTEeVcutqfe6ED/HOp9FGcBDQjjtsI0l2EQQ6EoPPHiKDafIGp6AQO f3aoggQwW94gXLnW3WqiZ+V51u18MIDgBclZs2iCUf6D28O9fgLhaE29FM+wRd4ZGkgOKN yTAoUifp9TIR+4elAu3BeU+u3+RkJSDsYsiMB+GUgxjB1+I9DdE9krZiqPjboytlGym/ND zKByn5pY5LS0pXUiJWJa3/XxyD0xlLyzraHAhjUnXHmX7puKJypDOQhmVFjsgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705079744; 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=w0Bq3wwww9vp//zfOSZt1KYvFXq4PBAMCs2wI+RG6As=; b=o6SOoSEGCoy3lp+N/qguh18akltBEm4y8COm/a0rrBAWaraeH33998RAtSVjSvcF2UQlHm v+XOLuD37n/z5/hl53I6UUYiAMs6wMmGI8kvdAbpSt+/aXGbJbwwxnZvtXjOFIAUfwgXB3 Lvs4W7Qc/bQk+4peA3oSbMmdz87Is1EhvMJkJfyglEZwIPvhfgG90UpbSiZiKe3N/SBIpa kQuLd5kxzU7BJDwzlotlVV0a6ODYHJe2AJBXJ3/AABFO4xWRGOttDFJIlaLOy1nNPXVQTD /fPZvzkhlwaDCvH5ZxqC1ixAWNtwJt9a9Fv6F9iS8OHUOLgBJyjZNrbHbA9oCA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705079744; a=rsa-sha256; cv=none; b=FhRb+Tu+u0SjOe8drC0Ub80vXLjONUftB2mWNPkBuEujzlSPBiSqHDs/nAatmlXhXXcueX EPNv0vfu58+7W4h+Qhi90dfhTpwEaIkmqDYmUGuHNbmvBaUExsj0lJ+RQMgtBJciQajblg y98UTbVtsQxTIq1HJi3ysw1YcILOJwY/XyJX6ZHYSfGJPszopC9wwGVKmHeWCfjyg02koI SUIiO92zeEPoiCvIrszLWqYKVNm/1LgAaP6izHVTheL8letBuCBEAfrJ8kofS8oAEjcqz7 W55T13663M/VSNccJhGTCBjiKJ1L1QEA1iJ6Y2PPhwMmO6Gn7CyZe2AT9JDb/A== Received: from ltc.des.no (2a02-8428-0993-f001-922e-16ff-fef1-acef.rev.sfr.net [IPv6:2a02:8428:993:f001:922e:16ff:fef1:acef]) (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: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TBSq43spBz175n; Fri, 12 Jan 2024 17:15:44 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id 5A1498050F; Fri, 12 Jan 2024 18:15:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tomek CEDRO Cc: freebsd-current@freebsd.org, Warner Losh , Olivier Certner Subject: Re: noatime on ufs2 In-Reply-To: (Tomek CEDRO's message of "Wed, 10 Jan 2024 21:34:57 +0100") References: <1749331.ETpRK2a2Mi@ravel> <2136329.mxFCRLsXLg@ravel> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 12 Jan 2024 18:15:41 +0100 Message-ID: <86v87y4gn6.fsf@ltc.des.no> 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-Transfer-Encoding: quoted-printable Tomek CEDRO writes: > I am reading this interesting discussion and please verify my general > understanding: > > 1. There is a request for change in core OS / FS mechanism of file > access time (atime) because of problem with mailing application? The atime mechanism is considered harmful by many because every file access results in a write which (even if coalesced) not only impacts performance but also increases wear on SSDs. Many people turn it off. Even the FreeBSD installer turns it off when installing to ZFS, except on `/var/mail` which is a separate filesystem precisely so that it can have atime enabled independently of the rest of the system. There is a proposal to turn it off by default. > 2. Linux change of approach to atime that keeps its value only around > last 24h so we should also change it in FreeBSD? > > 3. "realtime" is the alternative solution to keep atime intact? The Linux approach is an alternative mechanism dubbed =E2=80=9Crelatime=E2= =80=9D (relative access time) which instead of updating the access time on every access, does so only if the previous atime is either older than the current mtime or more than 24 h ago. > Why change well known standardized and widely used mechanism that is > here for decades? Because it's harmful and most people don't use it. > If there is a problem with an application why change core OS/FS with > all possible negative consequences and not fix the application? There is not =E2=80=9Ca problem with an application=E2=80=9D. No applicati= on actually requires atime to function properly because developers knows that atime is a) not universally supported and b) often disabled even when supported. There is however a problem with disk performance and lifetime being degraded. > Wouldn't that break POSIX / backward compatiblity? No. Many people, and the FreeBSD installer, already turn it off. The relatime mechanism would restore atime functionality while causing much less harm, in theory. I'm not sure it would make much difference in practice considering that we have nightly scripts which would trigger atime updates even with relatime. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Jan 12 17:57:30 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 4TBTlV1rVCz57G57 for ; Fri, 12 Jan 2024 17:57:42 +0000 (UTC) (envelope-from dfr@rabson.org) 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 4TBTlT1NcJz4m9s for ; Fri, 12 Jan 2024 17:57:41 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20230601.gappssmtp.com header.s=20230601 header.b="QAjxWG/M"; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::b30 as permitted sender) smtp.mailfrom=dfr@rabson.org Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-dbed85ec5b5so5495154276.3 for ; Fri, 12 Jan 2024 09:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705082260; x=1705687060; 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=qM4tWqQDfZoLSufw8tZE+YKA3Igv9zj1c8H834BTqlQ=; b=QAjxWG/Me1hJv05m/XakLXy7ctrZckQZepYo7duS2LB6RxJjRhU/WB54RIbpObbBmT C2ykBV7fxFkoY0DV0C91QRtSPlY9C9cBW1oqp38+XrL/7uipb62mRlXk+9hNtPHVe/0s jMusY3myShbjcyw5EYrm8Xnic72MQodObtBAc5HAj5sxeclNHnaKK+4BAP4ZaSizJBHc vNoe7WZDRdqZVlj15E3/0FuAx9yeutwt8MrDDzTyGfxVJBLdgrA663eG9iVvNZGfFpjs 42KPh69JSDTPCQ0uVGlj0Tht4N7OIaIRsNGthDh5tIwGk7Y8nryMVQy2fR8rl+7gm3gc UQHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705082260; x=1705687060; 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=qM4tWqQDfZoLSufw8tZE+YKA3Igv9zj1c8H834BTqlQ=; b=S9zdveJz4vULFg3oR2poWPGkSMas/XUnq53WKbS/pM7K84HZzC9SGnS/c1ZuRT4pY9 uBJJry+1Yz3rEm1Q9sbsIwWqD5PCREjcDwdcRFcq8OaQ3FtrJAiWWJy3FkWMUgC9z6ow ApUsJaAw12e+arZ0jKaAndZmCjso+lx9uMbFKtQM2O6MZUb5jcEgkwaWHfw+occ0LJwp m2gQF/bjJwfqp9XViybJr0kGRtShfCJXCZM5+IgiH9ic9rWq88tUkBaY/yAkTvprPoHO oXodZaF5RRgQfOSBA35VPHglDLRnEBpl8ztj5vsuzJw8tsAElF2Zy7+wzsdGj/7b2Q7T W4Jw== X-Gm-Message-State: AOJu0Yz1P8Ho+iH92HU2aPPbToF2i15o9Qmbobg0nze7i4skE87bRKtT J6cgSa11v1rz58bMOAcVHGALjwcCLZHh2gtJOJgtqgz9iXIf1zzqRQglmG9unY3gOA== X-Google-Smtp-Source: AGHT+IHvML+kf0qsvmuK4n9CWqZPIGtlANuO82waX+AGnx1t5x6eJSzSOj68wtbMUFj4yJCo1d0uHbK+qmK3xfb1FUI= X-Received: by 2002:a25:ae48:0:b0:dbd:ac49:223 with SMTP id g8-20020a25ae48000000b00dbdac490223mr871043ybe.90.1705082259965; Fri, 12 Jan 2024 09:57:39 -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: <3CB904C2-D983-4EF7-84D3-6BDED0700B08.ref@yahoo.com> <3CB904C2-D983-4EF7-84D3-6BDED0700B08@yahoo.com> In-Reply-To: <3CB904C2-D983-4EF7-84D3-6BDED0700B08@yahoo.com> From: Doug Rabson Date: Fri, 12 Jan 2024 17:57:30 +0000 Message-ID: Subject: Re: 15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid) To: Mark Millard Cc: Current FreeBSD , FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="0000000000006b1e9f060ec36675" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[rabson-org.20230601.gappssmtp.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEFALL_USER(0.00)[dfr]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b30:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[rabson.org]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com]; DKIM_TRACE(0.00)[rabson-org.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4TBTlT1NcJz4m9s --0000000000006b1e9f060ec36675 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote: > ram_attach is based on regions_to_avail but that is a problem for > its later bus_alloc_resource use --and that can lead to: > > panic("ram_attach: resource %d failed to attach", rid); > > Unfortunately, the known example is use of EDK2 on RPi4B > class systems, not what is considered the supported way. > The panic happens for main [so: 15] and will happen once > the cortex-a72 handling in 14.0-* is in a build fixed by: > > =E2=80=A2 git: 906bcc44641d - releng/14.0 - arm64: Fix errata workaro= unds that > depend on smccc Andrew Turner > > The lack of the fix leads to an earlier panic as stands. > > > sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring > phys_avail and using only hwregions and exregions. In other words, > in part: > > * Initially dump_avail and phys_avail are identical. Boot time memory > * allocations remove extents from phys_avail that may still be included > * in dumps. > > This means that early, dedicated memory allocations are treated > as available for general use by regions_to_avail . The distinction > is visible in the boot -v output in that: > > real memory =3D 3138154496 (2992 MB) > Physical memory chunk(s): > 0x00000000200000 - 0x0000002b7fffff, 727711744 bytes (177664 pages) > 0x0000002ce3a000 - 0x0000003385ffff, 111304704 bytes (27174 pages) > 0x000000338c0000 - 0x000000338c6fff, 28672 bytes (7 pages) > 0x00000033a30000 - 0x00000036efffff, 55377920 bytes (13520 pages) > 0x000000372e0000 - 0x0000003b2fffff, 67239936 bytes (16416 pages) > 0x00000040000000 - 0x000000bb3dcfff, 2067648512 bytes (504797 pages) > avail memory =3D 3027378176 (2887 MB) > > does not list the wider: > > 0x00000040000000 - 0x000000bfffffff > > because of phys_avail . But the earlier dump based on hwregions and > exregions shows: > > Physical memory chunk(s): > 0x001d0000 - 0x001effff, 0 MB ( 32 pages) > 0x00200000 - 0x338c6fff, 822 MB ( 210631 pages) > 0x33920000 - 0x3b2fffff, 121 MB ( 31200 pages) > 0x40000000 - 0xbfffffff, 2048 MB ( 524288 pages) > Excluded memory regions: > 0x001d0000 - 0x001effff, 0 MB ( 32 pages) NoAlloc > 0x2b800000 - 0x2ce39fff, 22 MB ( 5690 pages) NoAlloc > 0x33860000 - 0x338bffff, 0 MB ( 96 pages) NoAlloc > 0x33920000 - 0x33a2ffff, 1 MB ( 272 pages) NoAlloc > 0x36f00000 - 0x372dffff, 3 MB ( 992 pages) NoAlloc > > which indicates: > > 0x40000000 - 0xbfffffff > > is available as far as it is concerned. > > (Note some code works/displays in terms of: 0x40000000 - 0xc0000000 > instead.) > > For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource > that is used as bus_alloc_resource . It ends up rejecting the > RPi4B boot via using the result of the call in ram_attach: > > if (bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, start, > end, > end - start, 0) =3D=3D NULL) > panic("ram_attach: resource %d failed to attach", > rid); > > as shown by the just-prior start/end pair sequence messages: > > ram0: reserving memory region: 200000-2b800000 > ram0: reserving memory region: 2ce3a000-33860000 > ram0: reserving memory region: 338c0000-338c7000 > ram0: reserving memory region: 33a30000-36f00000 > ram0: reserving memory region: 372e0000-3b300000 > ram0: reserving memory region: 40000000-c0000000 > panic: ram_attach: resource 5 failed to attach > > I do not see anything about this that looks inherently RPi* > specific for possibly ending up with an analogous panic. So > I expect the example is sufficient context to identify a > problem is present, despite EDK2 use not being normal for > RPi4B's and the like as far as FreeBSD is concerned. > I'm not quite clear why phys_avail changes and why that is triggered by the 906bcc44641d commit. I'm wondering if it makes sense to arrange for ram_attach to happen before acpi, e.g. using BUS_PASS_ORDER_FIRST? Doug. --0000000000006b1e9f060ec36675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 30 Sept 2023 at 08:47, Mark M= illard <marklmi@yahoo.com> w= rote:
ram_attach is based on regions_to_avail but= that is a problem for
its later bus_alloc_resource use --and that can lead to:

panic("ram_attach: resource %d failed to attach", rid);

Unfortunately, the known example is use of EDK2 on RPi4B
class systems, not what is considered the supported way.
The panic happens for main [so: 15] and will happen once
the cortex-a72 handling in 14.0-* is in a build fixed by:

=C2=A0 =C2=A0 =E2=80=A2 git: 906bcc44641d - releng/14.0 - arm64: Fix errata= workarounds that depend on smccc Andrew Turner

The lack of the fix leads to an earlier panic as stands.


sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring
phys_avail and using only hwregions and exregions. In other words,
in part:

=C2=A0* Initially dump_avail and phys_avail are identical.=C2=A0 Boot time = memory
=C2=A0* allocations remove extents from phys_avail that may still be includ= ed
=C2=A0* in dumps.

This means that early, dedicated memory allocations are treated
as available for general use by regions_to_avail . The distinction
is visible in the=C2=A0 boot -v output in that:

real memory=C2=A0 =3D 3138154496 (2992 MB)
Physical memory chunk(s):
0x00000000200000 - 0x0000002b7fffff, 727711744 bytes (177664 pages)
0x0000002ce3a000 - 0x0000003385ffff, 111304704 bytes (27174 pages)
0x000000338c0000 - 0x000000338c6fff, 28672 bytes (7 pages)
0x00000033a30000 - 0x00000036efffff, 55377920 bytes (13520 pages)
0x000000372e0000 - 0x0000003b2fffff, 67239936 bytes (16416 pages)
0x00000040000000 - 0x000000bb3dcfff, 2067648512 bytes (504797 pages)
avail memory =3D 3027378176 (2887 MB)

does not list the wider:

0x00000040000000 - 0x000000bfffffff

because of phys_avail . But the earlier dump based on hwregions and
exregions shows:

Physical memory chunk(s):
=C2=A0 0x001d0000 - 0x001effff,=C2=A0 =C2=A0 =C2=A00 MB (=C2=A0 =C2=A0 =C2= =A032 pages)
=C2=A0 0x00200000 - 0x338c6fff,=C2=A0 =C2=A0822 MB ( 210631 pages)
=C2=A0 0x33920000 - 0x3b2fffff,=C2=A0 =C2=A0121 MB (=C2=A0 31200 pages)
=C2=A0 0x40000000 - 0xbfffffff,=C2=A0 2048 MB ( 524288 pages)
Excluded memory regions:
=C2=A0 0x001d0000 - 0x001effff,=C2=A0 =C2=A0 =C2=A00 MB (=C2=A0 =C2=A0 =C2= =A032 pages) NoAlloc
=C2=A0 0x2b800000 - 0x2ce39fff,=C2=A0 =C2=A0 22 MB (=C2=A0 =C2=A05690 pages= ) NoAlloc
=C2=A0 0x33860000 - 0x338bffff,=C2=A0 =C2=A0 =C2=A00 MB (=C2=A0 =C2=A0 =C2= =A096 pages) NoAlloc
=C2=A0 0x33920000 - 0x33a2ffff,=C2=A0 =C2=A0 =C2=A01 MB (=C2=A0 =C2=A0 272 = pages) NoAlloc
=C2=A0 0x36f00000 - 0x372dffff,=C2=A0 =C2=A0 =C2=A03 MB (=C2=A0 =C2=A0 992 = pages) NoAlloc

which indicates:

=C2=A0 0x40000000 - 0xbfffffff

is available as far as it is concerned.

(Note some code works/displays in terms of: 0x40000000 - 0xc0000000
instead.)

For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource
that is used as bus_alloc_resource . It ends up rejecting the
RPi4B boot via using the result of the call in ram_attach:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (bus_alloc_resou= rce(dev, SYS_RES_MEMORY, &rid, start, end,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 end -= start, 0) =3D=3D NULL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 panic("ram_attach: resource %d failed to attach", rid)= ;

as shown by the just-prior start/end pair sequence messages:

ram0: reserving memory region:=C2=A0 =C2=A0200000-2b800000
ram0: reserving memory region:=C2=A0 =C2=A02ce3a000-33860000
ram0: reserving memory region:=C2=A0 =C2=A0338c0000-338c7000
ram0: reserving memory region:=C2=A0 =C2=A033a30000-36f00000
ram0: reserving memory region:=C2=A0 =C2=A0372e0000-3b300000
ram0: reserving memory region:=C2=A0 =C2=A040000000-c0000000
panic: ram_attach: resource 5 failed to attach

I do not see anything about this that looks inherently RPi*
specific for possibly ending up with an analogous panic. So
I expect the example is sufficient context to identify a
problem is present, despite EDK2 use not being normal for
RPi4B's and the like as far as FreeBSD is concerned.

I'm not quite clear why phys_avail changes and why th= at is triggered by the 906bcc44641d commit. I'm wondering if it makes s= ense to arrange for ram_attach to happen before acpi, e.g. using BUS_PASS_O= RDER_FIRST?

Doug.
=C2=A0
--0000000000006b1e9f060ec36675-- From nobody Fri Jan 12 20:12:07 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 4TBXkt0wCCz56G2t for ; Fri, 12 Jan 2024 20:12:22 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 4TBXks6R0jz4Hmt for ; Fri, 12 Jan 2024 20:12:21 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-5f8cf76ef5bso63477717b3.0 for ; Fri, 12 Jan 2024 12:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1705090340; x=1705695140; 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=4KSarCJMUxXc1cJW0D4yUFO3iUCcElqWIbEoMAIfUw0=; b=PuIXiv7OwWs3RkSytX7kIn2RpUf9whzrcS2GJeCOqF6n83DEAOqTB/e4nOQ+N+aR4f 0JoPzFOkSmxRGrK8qtd0XRZNxOQl4K4Kz2YrnUQVff3VzlRD2W33HyLV6g+K0oAuUtbj rJBGWcavIoDTvkR+TFbGoFKcRvtrjZQNnMAuiCa9qQXN54ij15tnFvki/Z43g8pvKo4P fVQMY5Rxa7z6tPQkS8YsY4wUdqGcd+rEcorC/Tx4QbjmnZgVwFk0mM1ij+yJSTxQr8h9 zW9DYHoDv2UO8wu8t2HpbzuF2jqqfrlOrGur9h7CZUFXT4WscXWBQUXZ1+ZwlWmrjzSd 8o/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705090340; x=1705695140; 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=4KSarCJMUxXc1cJW0D4yUFO3iUCcElqWIbEoMAIfUw0=; b=nsRSaBm5sL2GDXcqQU3gWBa9BhDfMcej6xUvnv2MxkD2Du3JVfyy86ixpHRLC1rzEF P3iOIp9IbvuKKLRd0ddfmSoRYFA+TXiTOViNJTNsGetdT+STMdUbsANf+8/GaLQcyxTV iUni//U7fIvsHpPR/QLGYnX6vOdOwYJ9IGBPnv4Z4IEalbFsnYK/MaCFXUsiywHhhGs2 PLz7pkmLQzo6dh+4/zaTtgcz8VkVqCEs21auzKy2z+GF4sq93AvOh/UXdJEvan6AseMM xniCch29YQ4mMOctf5fIM7oa8S061ipHFC9OBnuADL4GYBzHPXmUbbpC2UDJvAmenjEy 6dWA== X-Gm-Message-State: AOJu0YzOTFRvh7/yz6IoChQpkzRmttAGQuTHabk5RRqRjI+9Awf8LPt4 scsUh9jllUfhGUcQMl6IsuhC+2y50yX1rmpVcUQk+0LSoA== X-Google-Smtp-Source: AGHT+IGZpCHT+A0AJik1gmkPfoEdqKygEjBSRhyGBfez31Ww2S9xd0bbFXhvF4cFmtRyClowZKN+sw== X-Received: by 2002:a81:f103:0:b0:5f6:d1e6:61f6 with SMTP id h3-20020a81f103000000b005f6d1e661f6mr1759496ywm.44.1705090340705; Fri, 12 Jan 2024 12:12:20 -0800 (PST) Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com. [209.85.128.182]) by smtp.gmail.com with ESMTPSA id fl13-20020a05690c338d00b005f692a0c3f0sm1588874ywb.63.2024.01.12.12.12.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jan 2024 12:12:20 -0800 (PST) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-5e7c1012a42so66810757b3.3; Fri, 12 Jan 2024 12:12:20 -0800 (PST) X-Received: by 2002:a81:8486:0:b0:5f9:72b3:6561 with SMTP id u128-20020a818486000000b005f972b36561mr2202272ywf.89.1705090339625; Fri, 12 Jan 2024 12:12: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: <1749331.ETpRK2a2Mi@ravel> <2136329.mxFCRLsXLg@ravel> <86v87y4gn6.fsf@ltc.des.no> In-Reply-To: <86v87y4gn6.fsf@ltc.des.no> From: Tomek CEDRO Date: Fri, 12 Jan 2024 21:12:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: noatime on ufs2 To: freebsd-current@freebsd.org Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Warner Losh , Olivier Certner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TBXks6R0jz4Hmt 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 Fri, Jan 12, 2024 at 6:15=E2=80=AFPM Dag-Erling Sm=C3=B8rgrav wrote: > Tomek CEDRO writes: > > I am reading this interesting discussion and please verify my general > > understanding: > > 1. There is a request for change in core OS / FS mechanism of file > > access time (atime) because of problem with mailing application? > > The atime mechanism is considered harmful by many because every file > access results in a write which (even if coalesced) not only impacts > performance but also increases wear on SSDs. Many people turn it off. > Even the FreeBSD installer turns it off when installing to ZFS, except > on `/var/mail` which is a separate filesystem precisely so that it can > have atime enabled independently of the rest of the system. There is a > proposal to turn it off by default.(..) Okay, the discussion got some (and enough) traction, and its about changing defaults only, not the underlying kernel or filesystem code to change the atime behavior, so this can be done as an option that user will see and can change easily in the installer.. and still good old atime can be used where necessary whoever needs it :-) > > 2. Linux change of approach to atime that keeps its value only around > > last 24h so we should also change it in FreeBSD? > > > > 3. "realtime" is the alternative solution to keep atime intact? > > The Linux approach is an alternative mechanism dubbed =E2=80=9Crelatime= =E2=80=9D > (relative access time) which instead of updating the access time on > every access, does so only if the previous atime is either older than > the current mtime or more than 24 h ago. rel-atime roger! :-) :-) Thanks DES :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Fri Jan 12 21:53: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 4TBZzf5v0pz56S8d for ; Fri, 12 Jan 2024 21:53:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4TBZzf3QCqz4cdS for ; Fri, 12 Jan 2024 21:53:34 +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=1705096411; bh=BRrGmWDSgk3+66fQMJlET9RSeFG8z6+hvUTU+ANvlBI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KnF96TyrgMXbkwghHZtocVoXzS1atwQbhZICdHcHs4/zjSAFlkfuY667QuIIQjVWjGlCLi+5OogfOQNt5zz9hYuDHafuzqSCL0vqbArPdZeoXfdcSVmPUrgiy21K45JrWo0+8ecIrM/wyFbEGxIjNfVdwYsULxDRoiCKYZ33ytISkT7jxRVeWE+dbbVSKGhjdS0WW0xP67GMVoDpKsKa0KQi4xjG4zQTQq1TX2LtklZmBdtyqBex5uZHU6XO3rRpVMEzrtNt0oR2LyKY2XxcEasQ/Mz/XougjFi9TJmqdd7zOkmFx8rCpz/sFW4r78VEnyOKeYYYnwI9IDUkTJcs6A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705096411; bh=QG7iZq3eG/eiUt0mE7OZLYDtLtmrqk9SJTPgyWKt/aQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UAXsIJQoMflkqhtKmEPVwAj2isNgZNkvPf9fOIjYEU88Ka0JYEpSyo4rhFSt6AJ9tvH6cEE4PzacTeA/2u+pv/LEf3/kiXR/OLckyixOiAB1w8mbhNCedy33wa43XjyjIi8z9IPeXTeLdj0fK9WB/Wx6DmSz/qfbxvOOdo5RZT8hDW7HO/GnwhsYsAiKskP2FPE9k1gKf1jrxeBKYSsnlsvFewHlOSndHhRFn+LJZ1kwQ5vABqesFjkStVwHCSxF5NqSQ3lk3tXss5QXwdnYuhUzKzdz2BTLmzZZ+b0dxHDfMMxT/W2qJ2G6GXdhKpEj1tPhZrPZLazTkW4rOy5pwg== X-YMail-OSG: vTj8hDcVM1nQxat8nwNeY.odmaZKAnRbMDd7eOmrn6MJWiE_iXLIL6E3V81aK74 X7SRGDZSrXemjrdpFMgR9unKOQtHZuHAPEKgay36ONI.zhEQDNvsAq5gHXmesEK0y8lzvRFlbxrg owv435NNiU2bDsu2NdIdi5lHU2AiAlLL_XE2zIFUJuoMB4jTCXTiOgm73Bk8t021zb3Lhv8aYdm5 WE_.7EFE.KFUnUvu3hwk8Yz9tlYSUx1yO18Gnskasb1rJ7Y6ssnlAM_7G1cCqam16lKRPhknus9Y 2UfVNTu0Lehjf_kzjzsT3.zLtLMxlYbtYvkkDVLmtHjOolky4OhA3KY0gMCwUOgrO885J_0OQhJz 5R1dGTxR98p_Dq6.EAby05oH7FlqlhOAbcu_4ct8XPhp1crWtJ5q1KZfwNEXbSl0MLifxvKBmh.1 O_yfPYFA7Q1WpS7U3iKk2e238FQLF7VmvI4TQ9U.w2jVXuC53372_rO3zt6nMLbNwKH_h9tGlYsB Ot4wpmdpmOCPmT6TxdxpfPrIrgLNQDx0l2wZGKTpZITSCEHhu1Uqdto3SMtrLbGTUujqx3fax_Rl cHmdcQyYS55ivMYdKxMPIjmMHTuPu0k4XlhSBCu19j7zhtAanxY2GYLQtAu6JF1MQbqct7oYTF1z KMgbfm0tRaUZoxdZNyq7xRPmkfsKVwMpLKFbbaHTrVyMZFCzXfTG.ptN5YIw6famDKo9aBPN3Uyg DEvYRj6Kfj97nsmnY7euwFZxEC6Bcz_FJqqU7cS8L9O2LVPxgbSvE9eKBFzs0XHS1AxThoRo8CV1 767Mffp1sDQSZTvNpFqmHJqSWiXLp7Rt.zz5zC4cUL6RcFY46u75AgNtK9Wxru.VnDo_ndTSU_LB wWrbQzZ1u6bJ68FDcRtL6Cl8zfUi_ySbbwZPCq_y7HaVnMjKHst687lxH3dwV0hspy3hbfzKtlwo FQOMQrX7XJPYVdLCjWlw_XVX9DxTiwOWkAUT4YwZE4_F9HE.Iwk_eooJIZCYf_EEFwamaq0kw2Bo ucovqmqKX8PgaVYTICjK6BwDcSGrR7bJlf1UbnvBVtwNEPDkoFd7FOC.LN.TUJ5UsDNlvXuqUMXf PPO5OrbKhaEsAzY3fL8yOtFAdbf9MFpSMbWUiIXv492sOK_hTohMX.5TFb3F1AR.JyoXhcQzd3Pe 3QH7E0zCsjc2E.GotOd6eWIG2L6Kkx0AbhXLAyQfnodvTiGHmuJM11tVIsB2Q_nlyh43Z9JPxIDj Q3X4DEzlffyUprthwAaC1EKFB27UuPSIPyvuG0hQZIJlRdmdbqZQP6zuxw9cj1mR4Hw_s7jaxxxu JBwJe6kKBcvG1WE_1jdP0YoV7z_CbB6jEN_lnR5kVcx8CitnuA4hHbKWzbbFnwMcZgBAoQXYXGpW CsCP7kR3cNtxV6lxoJ4BX9IAYKNKJlXGL7Ok7U6YtrjTUSmL73FYgcPLMiylKYtgIzRm6QG1Ihsw PijtMLN3767B5i3CCoFhoFGfhK1Q7ZT_LQcfopkjxdAcd1GYmcP6lJVe209IREF_dgVY1PcHKP24 Uuap8aIoEgcScsfvKk4TM5h8PcF4P1dabTzfRuoh4b3gjHjdgesCq5Nm3n8yl._rHPuR6HGb89JV .ASV0hYqJ54WxiubFUsw2L7H0IY3JwTYxxohEu1zRTAkgpTdOvCgbmgHEYmVGP4a6NFUeYBbhrPY 8Ctbd7W.squbO3fa6I5GtBikVmONFUyXBG.KHtFC0Bp7FpV7B9n63G7m0QzFUhppn74UpUXswKqp BgKgKmzG..4u.Os7hMznLyir7cCayMt1Jbp7sy3kR_OU4WY_0Vp7hmPu34sfWI_1mDiRg1Kw6b8x 61Jpoipzh__mhA5kzOmE_k7k5KHV9UEHX4F7SAJVD_BTWDSkJm4oDjG_u6_gRqcHBDfy1OqQEj4i 1oJEqVF24tQN6kL68LkNWOsWOfF6t3trj4kbQMsXNaHN3c40l2XbOxTTqUHqE5sJdBG.Kl3_m4dH r7aBZdJrvLttowZMslpjBv7gyQpQ7WA2B5nRsn.9ufufP6QYvIvkgRTjBqksBouaw.r2yD98vBZK hyfmWJ4qgeIvGjRetkoVG283cGJMM4dT51ZmO0UZq6Ccead2AnVEo3oFsCVdTcYbZ4vl8hrPRsCE ULlwCvbdi8WcHkrDfqfVNcR1YfGCh_8u2ajf5xgK49tLz5IRE1O.SAyesZeZtXtaI_ida1UKliMP bxxBTITTQkxqyPmcq29EQK8aCJyEkD2qcd4VeiBH5TENFpdc1LuBuGWVENsRteLRf0wl9NRXlkyF W3w-- X-Sonic-MF: X-Sonic-ID: f35c313c-4174-4ff6-9b5a-658b8f3e69e8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 21:53:31 +0000 Received: by hermes--production-gq1-78d49cd6df-4xktb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2054c6487691fb4b5323ace5ced448ff; Fri, 12 Jan 2024 21:53:26 +0000 (UTC) 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.300.61.1.2\)) Subject: Re: 15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid) From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 13:53:15 -0800 Cc: Current FreeBSD , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <3CB904C2-D983-4EF7-84D3-6BDED0700B08.ref@yahoo.com> <3CB904C2-D983-4EF7-84D3-6BDED0700B08@yahoo.com> To: Doug Rabson X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBZzf3QCqz4cdS 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 12, 2024, at 09:57, Doug Rabson wrote: > On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote: > ram_attach is based on regions_to_avail but that is a problem for > its later bus_alloc_resource use --and that can lead to: >=20 > panic("ram_attach: resource %d failed to attach", rid); >=20 > Unfortunately, the known example is use of EDK2 on RPi4B > class systems, not what is considered the supported way. > The panic happens for main [so: 15] and will happen once > the cortex-a72 handling in 14.0-* is in a build fixed by: >=20 > =E2=80=A2 git: 906bcc44641d - releng/14.0 - arm64: Fix errata = workarounds that depend on smccc Andrew Turner >=20 > The lack of the fix leads to an earlier panic as stands. >=20 >=20 > sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring > phys_avail and using only hwregions and exregions. In other words, > in part: >=20 > * Initially dump_avail and phys_avail are identical. Boot time = memory > * allocations remove extents from phys_avail that may still be = included > * in dumps. >=20 > This means that early, dedicated memory allocations are treated > as available for general use by regions_to_avail . The distinction > is visible in the boot -v output in that: >=20 > real memory =3D 3138154496 (2992 MB) > Physical memory chunk(s): > 0x00000000200000 - 0x0000002b7fffff, 727711744 bytes (177664 pages) > 0x0000002ce3a000 - 0x0000003385ffff, 111304704 bytes (27174 pages) > 0x000000338c0000 - 0x000000338c6fff, 28672 bytes (7 pages) > 0x00000033a30000 - 0x00000036efffff, 55377920 bytes (13520 pages) > 0x000000372e0000 - 0x0000003b2fffff, 67239936 bytes (16416 pages) > 0x00000040000000 - 0x000000bb3dcfff, 2067648512 bytes (504797 pages) > avail memory =3D 3027378176 (2887 MB) >=20 > does not list the wider: >=20 > 0x00000040000000 - 0x000000bfffffff >=20 > because of phys_avail . But the earlier dump based on hwregions and > exregions shows: >=20 > Physical memory chunk(s): > 0x001d0000 - 0x001effff, 0 MB ( 32 pages) > 0x00200000 - 0x338c6fff, 822 MB ( 210631 pages) > 0x33920000 - 0x3b2fffff, 121 MB ( 31200 pages) > 0x40000000 - 0xbfffffff, 2048 MB ( 524288 pages) > Excluded memory regions: > 0x001d0000 - 0x001effff, 0 MB ( 32 pages) NoAlloc=20 > 0x2b800000 - 0x2ce39fff, 22 MB ( 5690 pages) NoAlloc=20 > 0x33860000 - 0x338bffff, 0 MB ( 96 pages) NoAlloc=20 > 0x33920000 - 0x33a2ffff, 1 MB ( 272 pages) NoAlloc=20 > 0x36f00000 - 0x372dffff, 3 MB ( 992 pages) NoAlloc=20 >=20 > which indicates: >=20 > 0x40000000 - 0xbfffffff >=20 > is available as far as it is concerned. >=20 > (Note some code works/displays in terms of: 0x40000000 - 0xc0000000 > instead.) >=20 > For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource > that is used as bus_alloc_resource . It ends up rejecting the > RPi4B boot via using the result of the call in ram_attach: >=20 > if (bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, = start, end, > end - start, 0) =3D=3D NULL) > panic("ram_attach: resource %d failed to = attach", rid); >=20 > as shown by the just-prior start/end pair sequence messages: >=20 > ram0: reserving memory region: 200000-2b800000 > ram0: reserving memory region: 2ce3a000-33860000 > ram0: reserving memory region: 338c0000-338c7000 > ram0: reserving memory region: 33a30000-36f00000 > ram0: reserving memory region: 372e0000-3b300000 > ram0: reserving memory region: 40000000-c0000000 > panic: ram_attach: resource 5 failed to attach >=20 > I do not see anything about this that looks inherently RPi* > specific for possibly ending up with an analogous panic. So > I expect the example is sufficient context to identify a > problem is present, despite EDK2 use not being normal for > RPi4B's and the like as far as FreeBSD is concerned. >=20 > I'm not quite clear why phys_avail changes Do not be confused by common labeling to distinct data: Note the "phys_avail" vs. "hwregions" despite the label "Physical memory chunk(s):" : static void cpu_startup(void *dummy) { vm_paddr_t size; int i; printf("real memory =3D %ju (%ju MB)\n", = ptoa((uintmax_t)realmem), ptoa((uintmax_t)realmem) / 1024 / 1024); if (bootverbose) { printf("Physical memory chunk(s):\n"); for (i =3D 0; phys_avail[i + 1] !=3D 0; i +=3D 2) { size =3D phys_avail[i + 1] - phys_avail[i]; printf("%#016jx - %#016jx, %ju bytes (%ju = pages)\n", (uintmax_t)phys_avail[i], (uintmax_t)phys_avail[i + 1] - 1, (uintmax_t)size, (uintmax_t)size / = PAGE_SIZE); } } . . . vs. physmem_dump_tables(int (*prfunc)(const char *, ...) __printflike(1, 2)) { size_t i; int flags; uintmax_t addr, size; const unsigned int mbyte =3D 1024 * 1024; prfunc("Physical memory chunk(s):\n"); for (i =3D 0; i < hwcnt; ++i) { addr =3D hwregions[i].addr; size =3D hwregions[i].size; prfunc(" 0x%08jx - 0x%08jx, %5ju MB (%7ju pages)\n", = addr, addr + size - 1, size / mbyte, size / PAGE_SIZE); } prfunc("Excluded memory regions:\n"); for (i =3D 0; i < excnt; ++i) { addr =3D exregions[i].addr; size =3D exregions[i].size; flags =3D exregions[i].flags; prfunc(" 0x%08jx - 0x%08jx, %5ju MB (%7ju pages) %s = %s\n", addr, addr + size - 1, size / mbyte, size / = PAGE_SIZE, (flags & EXFLAG_NOALLOC) ? "NoAlloc" : "", (flags & EXFLAG_NODUMP) ? "NoDump" : ""); } . . . In other words, phys_avail does not change: It is just that phys_avail and hwregions are for different purposes and can get distinct values but ultimately both are involved overall and a net-result has to be generated from them. > and why that is triggered by the 906bcc44641d commit. I'm wondering if = it makes sense to arrange for ram_attach to happen before acpi, e.g. = using BUS_PASS_ORDER_FIRST? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 13 03:27:29 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 4TBkP65s33z5736r for ; Sat, 13 Jan 2024 03:27:38 +0000 (UTC) (envelope-from lexi@le-fay.org) Received: from thyme.eden.le-Fay.ORG (THYME.EDEN.LE-FAY.ORG [81.187.47.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4TBkP50FZWz4Ckv; Sat, 13 Jan 2024 03:27:36 +0000 (UTC) (envelope-from lexi@le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=le-fay.org header.s=thyme header.b=Of764e1t; dmarc=none; spf=pass (mx1.freebsd.org: domain of lexi@le-fay.org designates 81.187.47.194 as permitted sender) smtp.mailfrom=lexi@le-fay.org Received: from iris.eden.le-Fay.ORG (IRIS.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:106::18]) by thyme.eden.le-Fay.ORG (Postfix) with ESMTP id BC29A2827A; Sat, 13 Jan 2024 03:27:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=le-fay.org; s=thyme; t=1705116449; bh=8/+5DKk9ehP73ni+uJ/ESE/iMQ9YzL/NZhn819/brIw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Of764e1tlwkPj6Gp5tr8k9Qsf05F2mblz9+ONCXqPaVp/Wxc2EeOA3LACiCdMJMY1 XATq7LlS4JAfctwVIShIqQMeOH/v46+VfAiDhurWIIm/9DoAamPmZ6PcCafkfJUvDu CUAbnOFOGQvRKxux/ItjPqleYn9ltSItuvslkH0A= Received: from ilythia.eden.le-fay.org (ILYTHIA.EDEN.LE-FAY.ORG [IPv6:2001:8b0:aab5:104:3::101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id AFA7382C1; Sat, 13 Jan 2024 03:27:29 +0000 (GMT) Date: Sat, 13 Jan 2024 03:27:29 +0000 From: Lexi Winter To: Ronald Klop Cc: freebsd-current@freebsd.org Subject: Re: poudriere: swap_pager: out of swap space Message-ID: References: <94c6cf1b-10e4-49c4-aa1d-e87f8e8c3d09@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-sha256; protocol="application/pgp-signature"; boundary="gckceoOOfb3YE19U" Content-Disposition: inline In-Reply-To: <94c6cf1b-10e4-49c4-aa1d-e87f8e8c3d09@FreeBSD.org> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.50 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[le-fay.org:s=thyme]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:81.187.47.194]; RCVD_NO_TLS_LAST(0.10)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[le-fay.org:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[le-fay.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[le-fay.org:+] X-Rspamd-Queue-Id: 4TBkP50FZWz4Ckv --gckceoOOfb3YE19U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ronald Klop: > On 1/11/24 03:21, Lexi Winter wrote: > > i'm building packages with poudriere on a system with 32GB memory, with > > tmpfs and md disabled in poudriere (so it's using ZFS only) and with the > > ZFS ARC limited to 8GB. > My first guess would be that you are using a tmpfs tmp dir which uses > swap as the backing-storage which is now full. Configure poudriere > with USE_TMPFS=no to prevent this. hello, tmpfs is already disabled in poudriere.conf: USE_TMPFS=no a couple of people suggested changing PARALLEL_JOBS or similar settings. i'm still trying to find the best combination of PARALLEL_JOBS and MAKE_JOBS_NUMBER, but what's confusing me here is that system is claiming out of memory while having plenty of free memory - so it doesn't seem that too many PARALLEL_JOBS is eating the memory. in the mean time i've added 16GB of extra swap (previously it had 2GB), and this seems to have fixed the errors, but i'm not sure why this is necessary. Mem: 2440M Active, 18G Inact, 1696M Laundry, 8580M Wired, 1565M Buf, 1143M Free ARC: 1959M Total, 548M MFU, 371M MRU, 22M Anon, 29M Header, 987M Other 404M Compressed, 1439M Uncompressed, 3.56:1 Ratio Swap: 18G Total, 3090M Used, 15G Free, 16% Inuse thanks, lexi. --gckceoOOfb3YE19U Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmWiAx4ACgkQDHqbqZ41 x5naBgv+Lt0FhdBa9+ODqFPHN5KgmOuarYiAYvkztT4gzHwDCN0nAASOCXGRtI+H zxnBaIt/E3kmSEs0hilVtbL8y/dxv/JbWgOa/mkxBp7JS8w19z1VPpz/cp3n5cMS gs6MePCgqyoFpl6miwQxn22wnUbbxxFA+3J1cBIR7LssVVlqLtNT4RdsS2N2KbEr 8Ser8XV4KF0FIapix34153UJXP2weX8y4Nnxv/7EW/l4q/HT/y3KMB/qHU7uCuCX gOuhctNX5jhXsfp1YSZVurLlIuHJuCPnoKEx7sCc1Uvi61vSfBt1MfLe5ujVHTWI oAICBaYMhEsNcBxxaKOBjhuFE+Vo10AcRsmpSgbLpi3BXD8qD2EcEsERqti+7VRx wNfFVtizDHVXP0gxE9LNHxABci5vCTeI7s1k8oOuX4ncu7lGI9rGzmi+bt2mGp6F qgpMxkvgvGAV+oqcBJpzlFOqCv+1f9cUcIFcWfF/Ev2GQNYZZNia1G1Emlw/s5h8 MAAaPRRq =CTEd -----END PGP SIGNATURE----- --gckceoOOfb3YE19U-- From nobody Sat Jan 13 15:26:19 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 4TC2LS2QbZz57lMh for ; Sat, 13 Jan 2024 15:26:24 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4TC2LQ6dJBz4RFv for ; Sat, 13 Jan 2024 15:26:22 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=L2xP+Gms; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=qEBJrH7R; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BCEBA5C018F for ; Sat, 13 Jan 2024 10:26:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 13 Jan 2024 10:26:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1705159581; x=1705245981; bh=DOYZgLDSQZyOSU+fnoYmgZLZaiTemwzH /+D5TcOr7Sw=; b=L2xP+GmsYb4rDYhKHdhnLNMPYrVFUZUS+p226bwvFdMmF0qz lvSkjZQFJm+EnwU9OAopeLu5uOta+Ij2wA3mAxZ/KKf69xvXaIHcHfaeWwfIPRcx 8U8sOjdSM41Ld4xkywD8AkKP7H1FRRPX5gaaoHAmrUQNL0V+LI6vZy5gqffY+KcE r0YS/yPxN1gSXBOxdpXicCXwE6jujuQWUdMq1nq3PZUoakKMindfbMh5Vz+dZ7EL IjIWSfMgcBweXtMqD85wFYeeIcYirBhDT1aGx/FS+j1IDaVQyv8upH0u3t9KOwqn zr+bjNKDBupHq/jy7Mder5P5K24FtJiw+Vfgrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1705159581; x=1705245981; bh=DOYZgLDSQZyOSU+fnoYmgZLZaiTemwzH/+D 5TcOr7Sw=; b=qEBJrH7RHB301t+5Nugvz2kWFv+c+J0yIRRuYqtqs0W7ra+a5y7 bsiWWYvnLlwbEq8Os1VK7Ypll29RvNqhoIl7FqDLfNPgVid57ckFJ7Y5wtsd2gAI wfHmq6QsoJ5l2KVQvXn+Pv/zTIZ55boH3q4ELQOKRH9/SkmmWViLhTfSNgLYtgv9 sAYU1muo4dh8xawkL7YqHOxO5lzbXJDpo4301zLZIMjiW8hYIvr6TGV1a1yuw+pN e5QlZAgJbX3tHRIinKBqne1D5D0Q82w9A9iHLnWdUTSUnZgyFgc3Nx+fbCZyujRT tFaOc75XbcrcAIqVOlNQZVUObx5XMefWXVA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeijedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepjeejvdejhfejjeelhfffheduhfduleeiuddvfeegtefhudeigffgheetvdehke fhnecuffhomhgrihhnpehushgvrhdrfhhmnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 13 Jan 2024 10:26:21 -0500 (EST) Date: Sat, 13 Jan 2024 15:26:19 +0000 From: void To: freebsd-current@freebsd.org Subject: bsdinstall use on rpi4 Message-ID: Mail-Followup-To: freebsd-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: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.27:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4TC2LQ6dJBz4RFv Hi, I'm trying to use bsdinstall on FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img to install to usb3-connected HD, using the 'expert mode' for UFS, after having initially booted from mmcsd. The goal is to boot to usb3 with freebsd on UFS filesystem, and to have that filesystem split into partitions, and the partitions having various properties. IOW not to have it all on /. I'd like to use GPT instead of MBR. Is this (bsdinstall) method 'correct' or should I use some other method? I've tried this method but get errors after the fetching phase. 1. "manifest not found on local disk and will be fetched from an unverified source..." http://void.f-m.fm.user.fm/error1.png 2. "error while extracting base.txz: can't create /usr/share/untrusted/Sonera_Class_2_Root_CA.pem" http://void.f-m.fm.user.fm/error2.png 3. "could not set root password. An installation step has been aborted. Would you like to restart the installation or exit the installer?" http://void.f-m.fm.user.fm/error3.png -- From nobody Sat Jan 13 16:24: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 4TC3d861Gkz5669y; Sat, 13 Jan 2024 16:24:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC3d76gXKz4Zxx; Sat, 13 Jan 2024 16:24:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40DGOE0h021021 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 13 Jan 2024 08:24:14 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40DGOEL8021020; Sat, 13 Jan 2024 08:24:14 -0800 (PST) (envelope-from fbsd) Date: Sat, 13 Jan 2024 08:24:13 -0800 From: bob prohaska To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: bsdinstall use on rpi4 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-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zefox.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TC3d76gXKz4Zxx On Sat, Jan 13, 2024 at 03:26:19PM +0000, void wrote: > Hi, > > I'm trying to use bsdinstall on > FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img > to install to usb3-connected HD, using the 'expert mode' for UFS, > after having initially booted from mmcsd. > > The goal is to boot to usb3 with freebsd on UFS filesystem, and to have > that filesystem split into partitions, and the partitions having various > properties. IOW not to have it all on /. I'd like to use GPT instead of MBR. > > Is this (bsdinstall) method 'correct' or should I use some other method? > > I've tried this method but get errors after the fetching phase. > > 1. "manifest not found on local disk and will be fetched from an > unverified source..." http://void.f-m.fm.user.fm/error1.png > > 2. "error while extracting base.txz: can't create > /usr/share/untrusted/Sonera_Class_2_Root_CA.pem" > http://void.f-m.fm.user.fm/error2.png > > 3. "could not set root password. An installation step has been > aborted. Would you like to restart the installation or exit the > installer?" > http://void.f-m.fm.user.fm/error3.png > I tried this using 14-release on a Pi3 with a usb mechanical hard disk. I don't recall seeing the errors reported above, but found that the msdos partition wasn't populated. I copied files manually. The resulting host is finicky about booting, sometimes requiring intervention at the serial console to prod u-boot to find the usb disk. This particular Pi is booting without a microSD, it's possible the usb-sata adapter contributes to the problem. It might be worth trying the "bootcode.bin-only" method to see if that helps. Perhaps others can say more. Once FreeBSD is up there have been no obvious problems. Thanks for reading, hth bob prohaska From nobody Sat Jan 13 17:03:41 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 4TC4Vn44Qbz56C7C; Sat, 13 Jan 2024 17:03:45 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 4TC4Vm6hlCz4j29; Sat, 13 Jan 2024 17:03:44 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=YtHfL4OQ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=9XmHSYSa; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D14B35C0172; Sat, 13 Jan 2024 12:03:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 13 Jan 2024 12:03:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :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=fm2; t=1705165423; x=1705251823; bh=qLTjQ2vWWs dA1LvdP8jG4injCGDoHqoCg0OP8MRPkAo=; b=YtHfL4OQbnr7n1wb8lNtY7uAXJ jnjV/+yRiTPIp/1nfiXwDBEimHfmWvMEELwEDlPJCVTX+5wFdzN8i+UZVmlGK+kx l/y0NHobgblAhe/qldI/HQY6uXsHqtkovrUwJwqsXEcUQfZb9ftYghZdkIcbunUy o9d/ZT6iv+QNlgvPE7N/4Bq4DiC1jI8kzWHUyRdqj840Js8Y6OvQyBuGGkqjx8Jk CHXd/ycyqzT5J46kOqw71TAYJzqnP0D16045gXtXPLxYxEFy1lBzzQDOKPKL4xRI yUxMQcn/cX9vSxLM+C8u9AbqPYGPKw0ZUKuBCJUWZ8X3sgofgPiQuSQnd5jw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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= fm2; t=1705165423; x=1705251823; bh=qLTjQ2vWWsdA1LvdP8jG4injCGDo HqoCg0OP8MRPkAo=; b=9XmHSYSa4x8FYu+2VcCHT4esyg82FAJrgEdQKQcevKSm 3oxZjV6NEVrR8a73XZSsAwdBQ0jVRyaeQae0wwTgoEPNj5xebex6mdpDWMI0b0T2 XTR83sPaLh6RzMHBhsk+lBDQgwAtMhyz9JmB7tgCsmVGr3/+vB77lxMpGrpWF6C+ qahE/cPArb6JNuMMpae0bLzuf9cXJA0bLzo6HFOyumIt8Vna98x4prneCKYZi7+O PnukB73JaW9CwikswQIuqa2gmqO6DIaCEONF5exBlYPiXwHNrxBI8ZzUMpoFkE6I CJs9H+AgzSg3Iqk4XfmkVCTRj0XekZZdfji2b2jyNw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeijedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepleevvefhheeffeffheefffekvedvfffgtdffjefhfedvgeelveevudejje ejleehnecuffhomhgrihhnpehushgvrhdrfhhmnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 13 Jan 2024 12:03:43 -0500 (EST) Date: Sat, 13 Jan 2024 17:03:41 +0000 From: void To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: bsdinstall use on rpi4 Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.27:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4TC4Vm6hlCz4j29 On Sat, Jan 13, 2024 at 08:24:13AM -0800, bob prohaska wrote: >On Sat, Jan 13, 2024 at 03:26:19PM +0000, void wrote: >> Hi, >> >> I'm trying to use bsdinstall on >> FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img >> to install to usb3-connected HD, using the 'expert mode' for UFS, >> after having initially booted from mmcsd. >> >> The goal is to boot to usb3 with freebsd on UFS filesystem, and to have >> that filesystem split into partitions, and the partitions having various >> properties. IOW not to have it all on /. I'd like to use GPT instead of MBR. >> >> Is this (bsdinstall) method 'correct' or should I use some other method? >> >> I've tried this method but get errors after the fetching phase. >> >> 1. "manifest not found on local disk and will be fetched from an >> unverified source..." http://void.f-m.fm.user.fm/error1.png >> >> 2. "error while extracting base.txz: can't create >> /usr/share/untrusted/Sonera_Class_2_Root_CA.pem" >> http://void.f-m.fm.user.fm/error2.png >> >> 3. "could not set root password. An installation step has been >> aborted. Would you like to restart the installation or exit the >> installer?" >> http://void.f-m.fm.user.fm/error3.png >> > >I tried this using 14-release on a Pi3 with a usb mechanical >hard disk. I don't recall seeing the errors reported above, >but found that the msdos partition wasn't populated. I copied >files manually. > >The resulting host is finicky about booting, sometimes requiring >intervention at the serial console to prod u-boot to find the >usb disk. This particular Pi is booting without a microSD, it's >possible the usb-sata adapter contributes to the problem. It >might be worth trying the "bootcode.bin-only" method to see >if that helps. Perhaps others can say more. > >Once FreeBSD is up there have been no obvious problems. I've used this method with 13-stable and 14-stable, but wondered if maybe it was depreciated in 15-current. The showstopper is the error marked [2] which is within seconds followed by [3]. If it was just [1] then I could work around it. -- From nobody Sat Jan 13 18:00:31 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 4TC5mG3XkZz56JQ2; Sat, 13 Jan 2024 18:00:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TC5mF3RKFz4sJP; Sat, 13 Jan 2024 18:00:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 40DI0Ve6021238 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 13 Jan 2024 10:00:32 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 40DI0VqD021237; Sat, 13 Jan 2024 10:00:31 -0800 (PST) (envelope-from fbsd) Date: Sat, 13 Jan 2024 10:00:31 -0800 From: bob prohaska To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: bsdinstall use on rpi4 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-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zefox.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TC5mF3RKFz4sJP On Sat, Jan 13, 2024 at 05:03:41PM +0000, void wrote: > > I've used this method with 13-stable and 14-stable, but wondered if > maybe it was depreciated in 15-current. The showstopper is the error marked > [2] which is within seconds followed by [3]. If it was just [1] > then I could work around it. IIRC I didn't use the automatic setup, but rather the manual one. Perhaps that changed something. Also, I was using the snapshot for 14-stable on Pi3, that might be quite different, intentionally or otherwise. "Can't create..." a file looks like a permissions or sequence error, with one of the intermediate directories not created yet. ISTR a thread on this general topic saying to my eye that bsdinstall either didn't or couldn't deal with partitions outside the UFS filesystem. If you got a working msdos partition then I'm badly mistaken. Can't find that thread now. Thanks for reading, bob prohaska From nobody Sat Jan 13 18:32:57 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 4TC6VT37b6z56NSj for ; Sat, 13 Jan 2024 18:33:37 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4TC6VR6ktRz3yf1 for ; Sat, 13 Jan 2024 18:33:35 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=pIoSwwoe; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id CA0E4240A96 for ; Sat, 13 Jan 2024 19:33:26 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 3D2572407DD for ; Sat, 13 Jan 2024 19:33:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1705170805; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=59SKh4PfjBlXf2HX66Nw/1jFgg8vgFYInDQZnmM9ywY=; b=pIoSwwoeg6imYgDdNG1aNUkdVVcZELqc8NsH08yFTH7UuqaqQOx5EHetWW6U6e1h7aS2xI H2REtHRiY7aihQUlVpttOJ7OcKAlwYot5LB23/g6SZCL7Fzn7d7UGzsLVzo53WfcJACHoJ p9o1Iz3CNM4AVJ6/mOWl5ZuRn6g0yz57HUKbvzyaK+5JhhGqgiUW+380nuGfaEC4gO36kk H5WYvLL3HPciD4ETIkF2alLABBspRS22crMUlVnLPk6fNl2/G9jtFeP9qrMasZfkQOcZRo sAMP3FyIQzm3ZBAp8ltEBsYQh4tO9SNuzWC1VLLx37niNK7wK6fojBmC4GUDuw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-149-119.77.183.pool.telefonica.de [77.183.149.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 07AB82404BE for ; Sat, 13 Jan 2024 19:33:25 +0100 (CET) Date: Sat, 13 Jan 2024 19:32:57 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: NFSv4 crash of CURRENT Message-ID: <20240113193324.3fd54295@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: cad607 X-Rspamd-UID: d39aaa X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4TC6VR6ktRz3yf1 Hello, running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat Jan 13 18:08:32 CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client, other is FreeBSD 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. I can crash the client reproducable by accessing the one or other NFSv4 FS (a simple ls -la). The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla access to the client host, luckily the box recovers. I have no idea what causes this problem ... Kind regards, O. Hartmann -- O. Hartmann From nobody Sat Jan 13 20:38:51 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 4TC9H763sTz56cHC for ; Sat, 13 Jan 2024 20:38:59 +0000 (UTC) (envelope-from SRS0=cu6x=IX=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4TC9H747nBz4KfS for ; Sat, 13 Jan 2024 20:38:59 +0000 (UTC) (envelope-from SRS0=cu6x=IX=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Sat, 13 Jan 2024 21:38:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1705178331; 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; bh=2ckE3eHZirzyuocojfxNsMKB6pZrj0EUTAq8SqyiGC4=; b=fYwTl15EUx0afsSyWPusGzWYQNzG2Lgt7ptQsx700X9HWn7fqq+pI9Qel5Psu1Ra/8Sy6n QQrHvNosBSGV6DXAgvzCQ2DR15fJXV+I/kN8Znp+FNu21JphQoBRZCV88QhFrLG0TSrnOh fWEbfm8tLOlr0FVcttdBNCQ8lFw+6ph8gfRUE/zjaZ0iWo3UBO+qDhV8S2FKEQAZ2d7yh1 /cZNnu3SBjxlz80/SY97faSLhN4oTaSsBnihPU/G/6z187FAcYFaoEUq2aRvnYvZ8w5C8T sjzKtccgoHTMjkTao7p62a+Wg7+mrKMmYaPLFpdWZGft/uUoN5GlbI93HLLWAw== From: Ronald Klop To: FreeBSD User Cc: FreeBSD CURRENT Message-ID: <1369645989.13766.1705178331205@localhost> In-Reply-To: <20240113193324.3fd54295@thor.intern.walstatt.dynvpn.de> Subject: Re: NFSv4 crash of CURRENT 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="----=_Part_13765_1602708230.1705178331199" X-Mailer: Realworks (685.3) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4TC9H747nBz4KfS 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:3265, ipnet:194.109.0.0/16, country:NL] ------=_Part_13765_1602708230.1705178331199 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: FreeBSD User Datum: 13 januari 2024 19:34 Aan: FreeBSD CURRENT Onderwerp: NFSv4 crash of CURRENT > > > Hello, > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat Jan 13 18:08:32 > CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client, other is FreeBSD > 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > > I can crash the client reproducable by accessing the one or other NFSv4 FS (a simple ls -la). > The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla access to the client > host, luckily the box recovers. > > I have no idea what causes this problem ... > > Kind regards, > > O. Hartmann > > > -- > O. Hartmann > > > > > Do you have something like a panic message, stack trace or core dump? Regards Ronald ------=_Part_13765_1602708230.1705178331199 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: FreeBSD User <freebsd@walstatt-de.de>
Datum: 13 januari 2024 19:34
Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
Onderwerp: NFSv4 crash of CURRENT

Hello,

running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat Jan 13 18:08:32
CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client, other is FreeBSD
13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.

I can crash the client reproducable by accessing the one or other NFSv4 FS (a simple ls -la).
The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla access to the client
host, luckily the box recovers.

I have no idea what causes this problem ...

Kind regards,

O. Hartmann


-- 
O. Hartmann



Do you have something like a panic message, stack trace or core dump?

Regards
Ronald
------=_Part_13765_1602708230.1705178331199-- From nobody Sun Jan 14 03:41:30 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 4TCLg45sd0z56w59 for ; Sun, 14 Jan 2024 03:41:52 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 4TCLg357wdz4698 for ; Sun, 14 Jan 2024 03:41:51 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6ddec7e5747so3146268a34.3 for ; Sat, 13 Jan 2024 19:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705203710; x=1705808510; 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=aTAomrFqusdSwi2z0jmQ9WQXfAngHzHGLUf9rgwxhlU=; b=QKi8Y2Ezs/oIzdWk006YMygByPfgIJIsV3RF7Kej90l4XWyh+flQIQE0K+qT5VlAVz 8VH8N/3e2rOZQUEYHJb9QJyY5m/4rGSLQRLF6hJ/Dvx58nKyrFS2SQVnfVyiwXCLxTK9 Ax1nkPAaAa0IwTg+TMXcrQgEu8kg3H9GJLuVIxzzNtWNBsXiS/66LOZaxE1f/F10+sZD wEnPxpKVDsfEl3H/o9eu/VBqZlYzZ4MnCJmScj1NwEesCU5QTid1L9PsS5tt1CRhUVJ/ Xj/Xky9hZvSjqzZ0a7EyRbyiZrtXLLQY314mUPUw37xMAqiJH/SgqCaQ5sqr8EawvNfG Q8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705203710; x=1705808510; 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=aTAomrFqusdSwi2z0jmQ9WQXfAngHzHGLUf9rgwxhlU=; b=MwzCzFVMy8VBdjBXBg8HKtyi54YH9KgI2lV6JvKKvdCCZTwym2XmK3OKcLEi26/Rqw r63PiJeyjhYYYpvAv4eatY7kffQSKLesIn8i1q/Dy4mc/hYyTQkglBcKLr6MHLkK2GUa DByO33t5oRMfJGRttuykQBypHVza9JohO+gFlNIibFZLpshBkAoORgXSoPWA82SRpqQX 2xfR/k6URNSBYyvBbfJL6QdmL+Tu0kPPF8VT3nmddKiLFF6sRPuFhi/iqEzaphyq0iOz h5CpiTuj7S6+ojtwIb0hF4CtgsIcVx4Mvt6lCuiSuLs/MoNumYiSRLnj5CkdiKM6TycO DoOQ== X-Gm-Message-State: AOJu0YzHwqjO6+IlxTgJgO2RiRIGvsJ9/h8arOGJZujx2VQFkxIpmxU3 4zJFCt9GqWqmQsHyYUO8XE3GVHnfK18/QjyRf/HsJrQ= X-Google-Smtp-Source: AGHT+IFlrH77eACurUiz8zn59RWEIu6TC1MNKNP19OAXE9i3i53Ar57BZkdZNnIkN5YZY2/ZDyxDe69ST0EPGTImzCo= X-Received: by 2002:a05:6808:2393:b0:3bd:60d4:5466 with SMTP id bp19-20020a056808239300b003bd60d45466mr4306150oib.36.1705203709989; Sat, 13 Jan 2024 19:41:49 -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: <20240113193324.3fd54295@thor.intern.walstatt.dynvpn.de> <1369645989.13766.1705178331205@localhost> In-Reply-To: <1369645989.13766.1705178331205@localhost> From: Rick Macklem Date: Sat, 13 Jan 2024 19:41:30 -0800 Message-ID: Subject: Re: NFSv4 crash of CURRENT To: Ronald Klop Cc: FreeBSD User , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TCLg357wdz4698 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 Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop = wrote: > > > Van: FreeBSD User > Datum: 13 januari 2024 19:34 > Aan: FreeBSD CURRENT > Onderwerp: NFSv4 crash of CURRENT > > Hello, > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a= : Sat Jan 13 18:08:32 > CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl= ient, other is FreeBSD > 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > > I can crash the client reproducable by accessing the one or other NFSv4 F= S (a simple ls -la). > The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a= ccess to the client > host, luckily the box recovers. Did you rebuild both the nfscommon and nfscl modules from the same sources? I did a commit to main that changes the interface between these two modules and did bump the __FreeBSD_version to 1500010, which should cause both to be rebuilt. (If you have "options NFSCL" in your kernel config, both should have been rebuilt as a part of the kernel build.) rick > > I have no idea what causes this problem ... > > Kind regards, > > O. Hartmann > > > -- > O. Hartmann > > ________________________________ > > > > Do you have something like a panic message, stack trace or core dump? > > Regards > Ronald From nobody Sun Jan 14 04:49: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 4TCNB172lvz573Gt for ; Sun, 14 Jan 2024 04:50:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4TCNB10DK5z4G74 for ; Sun, 14 Jan 2024 04:50:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aAWDAflb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705207814; bh=yMBHKiCwgUuTpDLFH2smQKvNo1/LSuFEQSzPIycrNWo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aAWDAflb01G4Zw2TKEieJyuvOu5YMBfYfNb8MyWur/i4KggIEMT+Y0NMKiMaPzvIxkXIHixkCRbAW9/XAC8tkJ9rm9ouQuE2/fh4orIoFa0dVL9o6HQ9B7RP7onI5LWwHQyxrbVMphi4m7TwAIYxn746n+XI7CrvQtyJrILr3L2g1zCqua7XZJ33VhcKlIB1njYquWU9L0ubR7qiZlilh6fCs3XYvdg1kUf1dh+nGjlD1+7Pam9p3cHmwV9b69AXWyNw7Xl7L2fn1yCA8lKX7XAxO66jCyq+LLAje781WaPQcYS19t9yEaEytWd2bE840pRlh8aq9NBptZiJHE8Yiw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705207814; bh=ROMP+UBWHcj+jfAgiKUDdCJsFw2bPFR0LfWXri97f9t=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jVXIi5X7SYpO6v6h58X/nNQ5MqwUCxADhKBV0sJnPT+mbkgzSWBzjl9r3PopMaRRPVqkMzIb7o1cXIPcOga4eTD17Ouy6lFmtO9E3VNz8OdZ6m4c89HpUCJp4ehx1ud1VEUI81Zk1UI/9NTjuLjIw1RWb24lfd5ZgyQqIFWFJ3+uX08jSBjVEeX95/wGxB6aop19DDE0ytUaa5O/7SooHptiE+L/5g0pca3ocyhnVqIYuty+TEkR6pyg5XQgpxf+uRAksJGz1ZeHgkIix29av0BvmXnt9mg+D24n+YYu7mwIMfcFIc3pddOH3BiPMqNDGbnXKO/SC6KKmx5T1mDMew== X-YMail-OSG: 3IhyUi4VM1l82vgBVR5SlLRZuJ1.Whkr7jtAMmvSir3IvgTwh.iEuZxD6t4poYb emEDlo4mU6r2KhHNp280whmrWTIuqIIIYSr18XxkWpCpkGsin7MbcPDk8sWGctbegF_odw4cDg1x J4zvWe_fjcVqzpJQw.XRytufJGUE5SGVETkLmDtMMoTeLaoMgMFh3ryGEAfB4WMvlBBU8nJOmf14 OuR0H2ulFhk1oenFbOr0jnZ1xVtQZk0HNj.yY_rRoBSJjNLNKBwBgK0comtszN8tRgNKc_MMObZJ wKGtAPi.BoSKqpMbBaqxU5w1x5kKaIHirgpZ.3kSYjImIHsPX92Njh2VEWsHxktV9TkjPmeWlC2Z Ftj1ZB1htLS1dTguehJ_.yADhY0j4W4CP8gfTJsEzhKHwvDmqEhp5YgXgNMsV9DZwWRALJ9BytE2 YZXqSPZY30MXGhSLEUnOpDHVxRVbUL3SBgKFHOr4LFuV5d1fX.oaLJTzhE5R3S7hDLYA46jkq362 z6ZMoSJKBAp6QqY5sz_MD3UgBQrXyMxSy4VaxuGZAGtpaB0x1r6jCkVG8qkRyi5dogs9DdYhkrX0 3LtrZd2VO9H5SR_Fbu7FIrv9bMxnELnZ0NiMNpq8RH7i_mX0NyDrVWav6Gyjz0UEGYmsAMpRZiD. 5v6hQfQNPwD3Z1KKq5c3Ox8Xd0km52AwkkjuIYM1qQXTruGHWd23koYwyXcf0.u4FOOLXQ6kwaPT pXjW5694VHwnmexW2mfY48ie0ZCzvn5YfMcTCkLF1IRX1fCwT82t0cYfRTejbdQicPkKtUtAHdDP kJk8MslUAkmP_WR62pRsN.45ISh7EQB8CCKm1b3brONgRGcc5mniZfMqtQAI5kwK2Lw_tUfgxD3d yf.LP1_4i_X2v2ECgiTFIQCkJjZAjNnAEbjRGiHZGQBLntrtbyADum2wzOeC1qLlNFRNPoeSGWey Yg0.uTZE9uXTqq_uqBgNT9WfmjqQKnPtGqmSYz.mjXhdQnYEBcAoX9OKho3iVggdFOSpbk7p4uDM _ReR8nefnQCoaIE9Cb8gpXFgu2pKlEnW84IqnmD9HUMsiVLUe8bcfOYNrscs7mW86SwYCF5ctUH2 BeyZeVhGnOZqix7q60R3Oq.4d_H_BwmzVKx_9Ogrxdd4NJ690w2q2Tf5pQchKGp9p7SO.1dYkSiH ITSRZ5x8rQFYmMF0bz9QigQYJ65YlT3jNzIYfTrTaMtvhBt6kCsGvZZiVzTXh1mh2ewVoshpyX_n lyJABkn2CUN__UoH5hf.qFxy_xcWBW7p_.tKTmrlxI546qifA6ASN6pQH8Np0fTMbm1Xe.r7hTFE rvOUsdmIJACGmcR_5_LZXCmNspaPapF6pdfuUEjMHmA.CAMDVyBo44brzrKCCMA0z1qAg2jw.BW0 1VtxgTpZLw2WFWWjcVion2DHnWXIVyD5tg4SVDHI_Mgn4ZUre74xuQvvvGd2B4sO.RUhIfiraDjd yEcshHw88bWGKX3HLIYu9DJYB73uFrgnN5RRff.a4cgiJrfhd6wQXFq5Aq2uBJiVS50pEQv1UpA_ 31gWSfUYgmaqiXBnSmuc0sv4US6Gze30QeyCSOrYsjRK58C7UXb9h5eq4AKe0AbYRBOvNI7EkFoR y_McYjwR0RpwUe8BY6G3RGnq1rk3xwnjDuFWYaBeQTpzPX5RVr0J8PuW.Lr8y3SIN1.o5k_gRIEv QR0HKPuBUG6xeB.SZEYBFHKHgCFb7ezaK49ukiWy_zJmrxhQSGNs3lax601UZ8PANhYChIQ4ECAO 9cJeJnBJVVIrXPjytEPvacLnE4LSjfwaGyUafGcQEC5mYo.QyLug0SDOsuuniu6_B977PZLwgbUH r37ARsrZY1tWiiQ0FjhO6Ejew4C0XNSZLs1fcUxlLLgdqQT.Ywhi1MMzb6_CQ3hVaBX7ZvQHR2eU Rw.Y1T1SaTEeFtpG4dIzft42U5w_k23evZ883yrRFfD.X4hCH.e9D8ZDdm2OR74sLD4YIv8D3ZMC XxYFDWmsHhgnh56q7GanboQ7nD2WyiAppDNL3micExdlvMTYeW2LCPbXVe1LDTlUDAcSP2VnRrn7 dOj6YVhLzDXboVWx0xS3HemH5rYBZANzt6CsbhS9KL7txXva85BnjaJxDtAkHBAHVUdLPJNYrfgP D72GweRWq_Ls9Rii5DuE8XsxP7ZzPbiU7EJMXgVZxz6YpLLWNRurta5jG9q31tKy6_2cyp6O18OW sUjPAM.261WPz91x3mVFc9YG_LcK1kt8czIBVx.n8fiTwnU9loG0hAil5qv138o746PaGap5u3.0 8 X-Sonic-MF: X-Sonic-ID: 9d5d579b-09f1-47db-9454-1b0074e3c990 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Jan 2024 04:50:14 +0000 Received: by hermes--production-gq1-78d49cd6df-4xktb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 382a3257c54ea491d7e296657689d9c3; Sun, 14 Jan 2024 04:50:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: poudriere: swap_pager: out of swap space Message-Id: <60C36CF0-43AC-4ACA-B6A5-6997F4425EC5@yahoo.com> Date: Sat, 13 Jan 2024 20:49:58 -0800 To: lexi@le-fay.org, Current FreeBSD X-Mailer: Apple Mail (2.3774.300.61.1.2) References: <60C36CF0-43AC-4ACA-B6A5-6997F4425EC5.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from] X-Rspamd-Queue-Id: 4TCNB10DK5z4G74 Lexi Winter wrote on Date: Thu, 11 Jan 2024 02:21:19 UTC : > i'm having a recurring problem with poudriere that i hope someone = might > have an idea about. >=20 > i'm building packages with poudriere on a system with 32GB memory, = with > tmpfs and md disabled in poudriere (so it's using ZFS only) and with = the > ZFS ARC limited to 8GB. >=20 > running poudriere produces many kernel log messages like this: >=20 > Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space > Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed > Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space > Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed > Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space > Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed > Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed > Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed >=20 > this is despite the system having a large amount of "Inact" memory > according to top(1): >=20 > Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, = 892M Free > ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M = Other > 1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio > Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse >=20 > from what i can tell, these swap errors don't cause any issues with = the > poudriere build, but they do seem to hinder interactive usage by = causing > long hangs. >=20 > does anyone have some idea what's going on here? i don't really > understand why the system has used 100% of available swap space when = it > has plenty of Inact memory it could free to fulfill requirements. You seem to be under the impression that "Inact" means "page is not dirty" and so can be freed without being written out to the swap space. Inact pages can be dirty and such pages can not be freed without being written out to the swap space first. If the swap space ends up filled, dirty pages that are not in active use stay or propogate into the Inact or Laundry states, accumulating there (for later potential use). ("Laundry" just means that those pages have been fully prepared to be written out to swap space. Dirty Inact pages have more work to be done before they can be written out --if there is room.) It appears that you had about 15 GiBytes of dirty pages that were not in active use but that would not fit in the 8192 Bytes of free Swap space. So they could not be freed without losing the "dirt" for which there was no other copy of around that could later be restored when needed. You do not report what sort of load average triple the context had, the number of parallel builders that were active, if you were using ALLOW_MAKE_JOBS, or if you had defined MAKE_JOBS_NUMBER or the like to limit the parallelism. I've certainly seen such memory use figures for allowing lots of parallel builders when ALLOW_MAKE_JOBS was also enabled and MAKE_JOBS_NUMBER (or the like) was not used to limit the number of make jobs each parallel builder is allowed to have going in parallel. There are also some port builds that create more parallel activity below each make-job, outside make's control. I've seen an 8 hardware thread system with the maximum observed for each of the 3 load average time frames being the likes of: 43.21, 40.44, 33.70 (from different times during the bulk run, not simulateously). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 14 08:24: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 4TCSyS61gyz57Prn for ; Sun, 14 Jan 2024 08:25:36 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4TCSyR2ZZGz4XFY for ; Sun, 14 Jan 2024 08:25:35 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=kDzTS6rp; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id F04E3240AA4; Sun, 14 Jan 2024 09:25:23 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 6080C2406DC; Sun, 14 Jan 2024 09:25:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1705220722; 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=ceV9CUY3G73evHh2DkkS4z6PI3bIBr6aLw2ToCC7FPM=; b=kDzTS6rpIYwciTTtjpLBq4ECLUriuPDLSQ8acjEoD0cedl0yYAA96dn/pUV11vGSfPS3hf AR5mTPy3cGLMMce6SS/gTcqlCQsL1szVZzrCr8b0p5yPyKqKyCV8j62hBC90Xss8324mEt vlzsgM8YbsMwq0+dJeNpv3P1s+67RjSZDVCK7Dsbedj034a/OWNvPmDatm10cXSAB2TnES v0DYUm/J9VnWqs/mSLFywkslUWfk1gYH6FDbTBxRZVaxtVhyk3q+DE28jRWrAaf+npwXAT N3c0Vsjndp4Z9w9qkta1HQWxvTgaTHjmQkIx0kk061Klnjja2Wz0MpKxHfGoAQ== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-011-154-128.77.11.pool.telefonica.de [77.11.154.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 0429424048F; Sun, 14 Jan 2024 09:25:21 +0100 (CET) Date: Sun, 14 Jan 2024 09:24:54 +0100 From: FreeBSD User To: Rick Macklem Cc: Ronald Klop , FreeBSD CURRENT Subject: Re: NFSv4 crash of CURRENT Message-ID: <20240114092521.65287a17@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20240113193324.3fd54295@thor.intern.walstatt.dynvpn.de> <1369645989.13766.1705178331205@localhost> Organization: walstatt-de.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 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: 1a289a X-Rspamd-UID: a76e04 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4TCSyR2ZZGz4XFY Am Sat, 13 Jan 2024 19:41:30 -0800 Rick Macklem schrieb: > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop wrote: > > > > > > Van: FreeBSD User > > Datum: 13 januari 2024 19:34 > > Aan: FreeBSD CURRENT > > Onderwerp: NFSv4 crash of CURRENT > > > > Hello, > > > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e8= 2a: Sat Jan 13 > > 18:08:32 CET 2024 amd64). One NFSv4 server is same OS revision as the m= entioned client, > > other is FreeBSD 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-ker= berized. > > > > I can crash the client reproducable by accessing the one or other NFSv4= FS (a simple ls > > -la). The NFSv4 FS is backed by ZFS (if this matters). I do not have ph= ysicla access to > > the client host, luckily the box recovers. =20 > Did you rebuild both the nfscommon and nfscl modules from the same source= s? Yes, as requested, as soon as the commit occured. I recompiled the whole OS= from a "make -j4 cleanworld cleandir" . But I have a custom kernel with several custom options statically compiled = in. > I did a commit to main that changes the interface between these two > modules and did bump the > __FreeBSD_version to 1500010, which should cause both to be rebuilt. > (If you have "options NFSCL" in your kernel config, both should have > been rebuilt as a part of > the kernel build.) Monday I will try to compile in several debug options whe I get hands on th= e machine again and I can test Tuesday on several other boxes running CURRENT (after update) ho= w they interact with themselfes (CURRENT) and other (FBSD14, FBSD13) via NFSv4. >=20 > rick > > > > I have no idea what causes this problem ... > > > > Kind regards, > > > > O. Hartmann > > > > > > -- > > O. Hartmann > > > > ________________________________ > > > > > > > > Do you have something like a panic message, stack trace or core dump? > > > > Regards > > Ronald =20 >=20 --=20 O. Hartmann From nobody Sun Jan 14 11:49: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 4TCYTv10crz57kNq; Sun, 14 Jan 2024 11:49:39 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4TCYTt0qkRz4xDk; Sun, 14 Jan 2024 11:49:38 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=AMxR2TM0; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id E696F24082D; Sun, 14 Jan 2024 12:49:34 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 52988240486; Sun, 14 Jan 2024 12:49:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1705232973; 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=HOnvODjHjpCDhv8hvItAj2aytdze9QiSyeAXXrGz7dQ=; b=AMxR2TM0EwIgThgpPkk6sWIGrD+hQsm3B+hdX76u4l71uUxplPRPgNWpgt2dAcbXRRqnuk 2iEtTWfik4TJMzR7nQgiiqmZMd3ap2E2z37g9sKb1pBR2HROunf4pKpBFDjcsmp08sNXPt Ai2oG9SUqQFoYQDcVHRX2JjJ9Aw9gnVPgNdh9/o++ctHG1bBJi6hVINPb9NgykJTdDb7VH 8RLRt1cpF6Px0CAH/d0S5nx9sbKfwvov3gGzY8/k5iU6MtYJI3HubWk7gfTIscxiSbg0ce 3CR+Iupj1mPjn7gF0FdTHe5Vgdl0IzHc5Pqd4NON/ijGyuNUopgFm/vcuJiGvQ== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-011-154-128.77.11.pool.telefonica.de [77.11.154.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 0C00724002E; Sun, 14 Jan 2024 12:49:33 +0100 (CET) Date: Sun, 14 Jan 2024 12:49:05 +0100 From: FreeBSD User To: Felix Reichenberger Cc: FreeBSD CURRENT , FreeBSD CURRENT Subject: Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6) Message-ID: <20240114124932.2db7ef36@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20240107185133.68824d89@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: a2c514 X-Rspamd-UID: 9086ea X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4TCYTt0qkRz4xDk Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024 amd64 > > > > Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP and ICMP > > (ipfw is configured via rc.conf in this case, host is listening on both protocol families > > IPv4 and IPv6). > > > > The host itself has openldap-server 2.6 as a service. The host's interface is igb0 with > > assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces via a bridge > > with the same physical device as the host (igb0). After a while (the time elapsed is > > unspecific) the jail is unable to contact the host via IPv6: neither UDP, TCP nor ICMP > > sent from the JAIL is reaching the host. IPv4 is working like a charme! No problems there. > > > > When pinging the Jail from the main host via ping -6, the jail is responding! After the > > first ping -6, the jail now is able to ping -6 the main host. > > > > After a fresh reboot, the problem is not present and occurs after a while and it seems to > > happen first to very active jails. > > > > Kind regards, > > > > oh > > > > > > -- > > O. Hartmann > > > > Hello, > > This behavior might be caused by IPFW blocking some IPv6 neighbor discovery/advertisement > messages. > After some time, the link layer addresses of the IPv6 neighbors in the NDP cache may expire, > making the associated IPv6 addresses inaccessible. > Do your IPFW rules allow ICMPv6 messages to and from IPv6 multicast addresses? > > Regards. > Thank you for responding. Thank you for his valuable hint! The jail(s) itself/themselfes as well as the host use the regular ipfw rc setup script as provided with the base system, adding simply those ports open which provide services - a plain and simple approach. Checking the jails on the host in question (jails are contacting OpenLDAP server on host, OpenLDAP server configured for test purposes to listen only on IPv6) leaves me with inconclusive results. Assuming a jail, called host-git, and a host, master. Deleting the NDP entries aon hostgit via "ndp -c" leaves me with the initial reported issue here, the solution is to ping the host-git first from host-master to "magically open" the IPv6 connection. After that, ldapsearch or any other IPv6 connections originating on the host-git work again. That seems odd. jails are vnet. Jails reside on a bridgeXX interface, sharing the physical NIC of the master host. Just for the record. I use a similar setup on a XigmaNAS host (13.2-RELEASE-p8), also with active IPFW on the master host's side as well as IPFW enabled on the Jail's side. Difference to the above mentioned setup: The jail is located on a different host, contacting master-host via a switched network. Regards, oh -- O. Hartmann From nobody Sun Jan 14 16:38: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 4TCgv04BhHz56c8T for ; Sun, 14 Jan 2024 16:38:20 +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 4TCgv029Pyz4JWF; Sun, 14 Jan 2024 16:38:20 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250300; 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=eDnKqXMS9gTwijFGu0Mxu+ZIJRgZ06VxXSNxygZWtWI=; b=TcG3izOdBwbKkP9l/soAWgatalTKEd558AL4ZIH3gtPYpJQfJaZL5ejJFEdWNYZFdZuDrE ueIJX5gct+nFN5CEP9jt62UOJ+Jq2HHjoU4jOTQTIpg9X6JHcj7TFRtiL9VK+LuIXiOo3S 2mA85CI0YE2xgvkSlVpl7mCgNkie9XsD3LpY7m0Cdb9HDJOHfGdUN4GAV+Ra/lByl+Bv1Z T4XEfIwHl0EaPVKehzGUwXjA41yJS2vTYwzaDKmLTCGoTX2ri7xq1Dy35Vw+1g6OnMwpdO r4Yt8tCl2LMHxCpwdbVGoq2HytMHSpGJqwtO99LqHSGe7i6VUm5TPd3rJZyA8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250300; 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=eDnKqXMS9gTwijFGu0Mxu+ZIJRgZ06VxXSNxygZWtWI=; b=CyDCxQjR9NspFN+ug0WF9UgGY2vG4Ia6ZNIhtxh01WeVrA3elN+udt+62nJCcjp+Bxu3nL 3FodVZH+2Wt6SjGdnIiI5EICIgyYEx2OzFytrhmzvINviJK4SFa2b/88YZywo+xBdOB1WY JZRbwUUTHdmajePLpkN35J8fodASXqBpVPAcZ4cMwa6qqS70+v6XcxaiyFPYmPrDxqW4c6 ipiKDR35eplYzyVzLyOa7+cC5IM4tXU2PU5e3wrMjPh+kgMsySQaD+EL1UAwqKAFpGoqjy WgzVaDlQvVJq/S7djxLeVN8JQkdvniYbm0oxaNauPgRtJ5AJLK7HwUKuVDwdpA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250300; a=rsa-sha256; cv=none; b=Hw0m53qJOHDXjHzXOSVEqNibsVCuMsOOrf/Db++TEpOqQpCiJ34X1MpyDPKOCnDuVsVcID mZ6ZNA4bKi3jypUIvIIb5UAf+e2PDaOmKPSoZ4KwOXR2ps5qr59s1/SHbHvx6T1g+zS+gv guoDt0mlpUHDMIXrtjO5r0TknSeXKuMdCGrHEaOcsaRZ7rYFr0mkQj7HIlLIKAmhzObWiQ fotZMO6JXEdSyuyKEsw0lQSxbl9b8fRxCrVCInF/hNx/1PHD+fQ2jkd4WwjBB0/gnnGKQw Hm7nn0fyHsKPoaqykNaGVJMBp+cZ4szoSQ+6bm4bmecodxMkgSsfPyLxZQvDBQ== 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 4TCgtz613cz156d; Sun, 14 Jan 2024 16:38:19 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:11 +0100 Message-ID: <6716110.NahNnZtspv@ravel> In-Reply-To: References: <6714298.qJWK8QVVMX@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="nextPart1705252824.Ej03iQjLZH"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1705252824.Ej03iQjLZH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:11 +0100 Message-ID: <6716110.NahNnZtspv@ravel> In-Reply-To: MIME-Version: 1.0 Hi Lyndon, > > I've never found any compelling reason in most uses to enable "atime", > > except perhaps local mail (snip). > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. I appreciate this kind of historical information. According to Wikipedia, = most of the PDP-11's lifespan after my birth date overlaps only with my chi= ldhood and teenage years, and I had never the chance (or curse, I don't kno= w) to get around to one (actually, I only learned about its existence years= later, much after after its phasing out). This purpose, i.e., "determine which files to archive", was achieved by rel= ying on 'atime' I guess by selecting those whose access times were the olde= st (perhaps combined with other criteria). The mean employed here is exact= ly the same as for the use cases reported by Warner: Being able to know whi= ch executables / libraries / packages are effectively used. So this approach has exactly the same problems. As I explained in a respon= se to Warner, it is currently almost unpracticable on FreeBSD, because some= periodic processes mess up with the access times (for more details, please= read it). But more deeply, as sketched in that response, the problem is "g= eneral": Relying on access times is bound to be fragile, simply because the= y are updated implicitly, without the applications asking for it at all and= for most neither being aware. The use cases presented for 'atime' so far = all assume that the access times will be updated only on some action that i= s relevant to their scenarios. But you can't prevent other actions not in = your scenario from updating these access times, and it can be very hard in = practice to predict which can occur on a given install (depending, e.g., on= how many software packages you've installed, their provenance, etc.). In = some answer, Jamie Landeg-Jones suggested to have a per-process flag to con= trol the implicit access times update, which is a workaround that is probab= ly enough in some use cases, but not for all (see my response there). At t= he same time, I'd like people to realize that it is still no more than a wo= rkaround, or a "clever" way to solve one's problem in particular circumstan= ces, but is not a generally reliable solution. What I'm evoking here concerns more the "usefulness of 'atime'" discussion = than the "default should be 'noatime'", but has non-negligible bearing on t= he latter. > And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. A logical, completely predictable move. =20 > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. I agree. That's exactly the reason why I wanted to seize the occasion of r= obert@rrbrussell.com's question to present my take, because I had been wond= ering about that a few times in the last 5 to 10 years and also never encou= ntered a compelling reason for why it should be the default. And I insist: The initial discussion, and my main focus, is about 'noatime'= becoming the default. The discussions about the usefulness of 'relatime' = and 'atime' are very interesting, and I'm even participating to those, but = to me are secondary in the end. The usefulness of 'atime' is of course in = part connected to the default to use, but they are still very different que= stions. For example, concerning the former, the frequency of needs (how ma= ny uses?) is not very important, whereas it matters a lot when it comes to = which default to choose. > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. The summary of the technical side of this discussion so far is that there m= ost likely won't be any issue at all for the vast majority of users if 'noa= time' becomes the default. We'll see if more reports for other scenarios a= re to come (or if we can find or guess some ourselves; irrespective of whet= her they validate or not the current evaluation). And, as reported by others, even /var/mail should not need it in most uses = given that all prominent MUAs have long departed from using the access time= comparison alone. (I won't pronounce myself on this since I'm not persona= lly using them, but I'm not seeing any reason not to trust the reports. If= some people have contradictory facts, I hope that they will present them.) Thanks and regards. =2D-=20 Olivier Certner --nextPart1705252824.Ej03iQjLZH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDfMACgkQjKEwQJce JicLGQ//QKEfDNDf5GUHTNm2bVEZ8kiHsDGsp4wu0iQETXM841D83ITJUOyvr3P+ K+379spvh9lbaWi2CS6FlpyWdvT3Zv/unyi5/EkJcqH/kG1XSmbJp16AxwBEQkD0 EVH3iuKTIPviTh85UUbwnzn0v35Zh2HrEzkax80ayuMYLJqvJsfzDKo50Joi54A7 iLX4CCp2Kdm7X1IwgU/R2c49EKVS81Mm/NEyWU9jTdD+CC/5yM0sJZqeFEujiAWs yTlLY+3S/UoHfexMUqIn34RTqpPtTL4cVkemK155Cpbcp1ueJ1X6L+MW9bybhWbX VSYGJOCHIa6Vncg4rACtiEt2CT18y8Vqcempl7nL/07F/9XGLUJctFqwBCiZeQbD 4WbublsZWTxwZJyhiaO8rAUojVGURdVDCwpWoVU/9nebQ8XZ2xSVl8Fk0b/AyNgd I9ODdxHV48L3b0u3VmS1FTqQJED1sYoXLxQpqbpk0Glb79EDiPU5F/qP5MjHzMp0 EmvHy+4mzZJncKR4OE0iwITwK9BxOeElNN/5EMF0SGuO1/DFpcgUiaNSZ6HHZgv8 /TNXGy31WHU3jQgS+PDG9XZxKSEAjShOULuhgxKCgvoTwl9NBM4HcKphAS/g5DBx f+JGcMmu6HftVzWVM45hrs9ZUpg8wBFW/U9Nny1BQybp/jALXVc= =hx/x -----END PGP SIGNATURE----- --nextPart1705252824.Ej03iQjLZH-- From nobody Sun Jan 14 16:38:32 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 4TCgvG6v2Pz56cBC for ; Sun, 14 Jan 2024 16:38:34 +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 4TCgvG5vRPz4KFD; Sun, 14 Jan 2024 16:38:34 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250314; 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=xCirQMuVhknDBD/5o80ZS3bh7yqwPfVoPFDYK1CKMdA=; b=KZiYEtWu36/4buHEyAso/bJ3Uf3JFHmi/x4tPcwb55EhJMvnb3ozsD9xOAdFRghdFCoW1p 0TFqIbmCvAmJGKfGcI1SU+kXnNtA4ge0r+7NvpGE9o8r4oMmWVrtxGHFqY4t+lNWmaBK/x vyhwRXNoTpfwymnVeQXYKycwM0RvFAN//pcO3jywNGClU46K+lVwk3G8Mh2A3ValPJBQJV t6dVb/AvtwhF/H12rePEA2+V81q8zvr3T05lhzcCRNxSd5+L5o2cI9XYUihsosQ6oOB84q ifcWqcTg2AJjnLfsVITgKhd09YLrk4y1tmzDyI8y5Ma1RQUJd3l3N3OqfFmM4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250314; 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=xCirQMuVhknDBD/5o80ZS3bh7yqwPfVoPFDYK1CKMdA=; b=fAw8ugLZLXwi7Necjsv49ga43MKvT+7fGPrvYR4BawPwFhGuc0WYioYP/qMEBcBwLL9qn6 fxAcsxsmShFQPtkNTSGFFNd/vr2AGWBgSm3hRwR/z/P2jb2b0D5QP29+C17jiY9RKR0FA1 arW4qJ9Cq7e2FxAIpC2vO2L55NnlfH7VURiCuykk8YP3+qMIQ4nkCd48q8hYPYvsCOzW3P IMk1o1XcU/4arjq+9NnJ1AuAp3jfqqTWLaxI8EX0wm5P20P1SQxVEE3CvZQqPKGBKFGn8A Ke7wfhrzQNlMbCLuQqZvUdVJDsRgAAz5CN/OHC6gB633bVmb0hLKCk+QYZARxw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250314; a=rsa-sha256; cv=none; b=awoBidzrfWc+VYUPqLNf9KR3WvdUitwfwhIhdSppFgoA+V34kZvXSB5WmuT9QPskbJN9wi u6AJYlaWJq7cpiv0QAnz5o9RphGtoaBaN69qlra/3i2FGMG+Wck3XSfG269QUVVS65yKTA 8D9rRrtL08bqiCrgqftyFBg6OAvQy97HGN4Cvnl784PwDSLUHCryJVWyOGEmDe8A9uhXLT WsprvKNL/QyJ+hZZ8ixqkvkX4OPtSaG8ytCPJ4VL/vg0AK1whTr7SyIHuAphw6s9cE44mS rEm4jkUPIm9ek942gSkZRhZNxEfOnk19T2pkZM7UX2uo4ylEGCRpBS0DVYYC/g== 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 4TCgvG2pnjz156f; Sun, 14 Jan 2024 16:38:34 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Jamie Landeg-Jones Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:32 +0100 Message-ID: <3172137.KEUK7n9DnO@ravel> In-Reply-To: <202401111956.40BJuURB045685@donotpassgo.dyslexicfish.net> References: <2136329.mxFCRLsXLg@ravel> <202401111956.40BJuURB045685@donotpassgo.dyslexicfish.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="nextPart1775136.nRgdb1dTNT"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1775136.nRgdb1dTNT Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Jamie Landeg-Jones Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:32 +0100 Message-ID: <3172137.KEUK7n9DnO@ravel> MIME-Version: 1.0 Hi Jamie, > I've often wished there was the ability to set a process to "noatime" - where > all accesses to the filesytem by the process and its children don't alter > atime. It would be handy for those cases you describe above, such as backups > and locate, but these days, where it matters, and is suitable, I instead > create a filesystem snapshot, and run the process on that instead. (which is > how "live" backups should be done anyway!) I've mentioned your answer in another response to Lyndon Nerenberg when developing a more general argument that 'atime' is generally flawed for these kinds of use cases (finding the last use, finding files to backup, etc.). It's true that the ability to deactivate 'atime''s implicit updates per-process would cater to more use cases, and it's an interesting idea. Essentially, though, you can't guarantee that some applications, or simply administrators typing commands at the shell, are not going to throw away your precious access times, so can't rely (in a strong sense) on them. Sure for backups and snapshots. I agree you'd better have backup perimeters coinciding with file systems partitions and use snapshots to get the smoothest possible experience. But snapshots alone do not guarantee the "correctness" of a backup (the ability to restart smoothly from it). Cheers. -- Olivier Certner --nextPart1775136.nRgdb1dTNT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDgkACgkQjKEwQJce JieYog//aG7zszVnsI6TGxtpeCOnMMqivwU7Z9/wdMYxrm2NSSXQGe9nHOgrtkFc z6TXrBLswyePB//WxcGlniGue2O7FDcwtVpCjfa4PTGmqGx1bdk22WC1u87ZSp4f Q7BpXlQKFKpZBg+uEy0CYi71itfJ573ov9TXOEOUDrSw93awp/iVNKWi9eUPsRXD 8rblXotxz0mbM6K0cKuSkMX5+pY5NaZ8qYNiq8Pr3jh59Obs4yzT5oLZ1e64Otkr dGfCpzseK5/lBJcmqhg0aCwQxCZqTFPOXwgbug+5JTLz1nnN1ynCVZb9Z2qDsBOo cWPPpwW6xS/Xd6AU0gwjXK9SAZkWuFfDfZH+8iYW6QTuBoTs436vfizaM9mPzubV dRNiRngSugd+5iLHcm51HqBAy3g9nvfVvtJwgKU9bQBKTBwwg4GaAp1WS37DGkvk atVCdvctNpvgYACiZ67CE+LhiOXrdT/HwZc8U6u9CadTvHaT4Sx0PqnYJousdISn XT7HABuKECs5zADCrNnHmeZw2BjtyD+6nYLLKcpiCI/bP5z7Jil0IBkNfg/vnkjF DBqO/RtgYhFonmnWulnJVdkne/9Hltu22jDCkA09fHnzzfs2/w01PAo+SEJot3Yp jxsguVXhFbRh8ugT/Bci2Xxi+7s1wygX8FGDqxNh6B4ihFgGqgM= =Gldj -----END PGP SIGNATURE----- --nextPart1775136.nRgdb1dTNT-- From nobody Sun Jan 14 16:38: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 4TCgvf4JXJz56byt for ; Sun, 14 Jan 2024 16:38:54 +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 4TCgvf36YBz4Kwb; Sun, 14 Jan 2024 16:38:54 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250334; 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=9l7d1WvECBQi9EgWpQ1D/hiA9a2++22ykX26IVpksgY=; b=tP0TZHO3tuChjnQHKSytE2j2QrAOL4Dp8n6wdj8zwuntm29dNJaKLKo06gsThtAyg67zKT DmgGY30fHCghqgajwZOBtmpEh3GL81QowSodu+1wn6ODS3qJHyoe8bi8ktmQoJfR8NJg6a 0clld95Enr1xyS0y+jKmKP+hf9aNP98fJLpi63tDbMu3lu1P0zlRyvJgCRpWLjUbYOqdX8 BNVQVc+UaVzVjxzo+MmYcJd2GD+I1uhGQFMalhfHoWLZftC4PAwHIkkpcxMT3k/amW1NrO n+LiWpNNwopzPTLoG+/G7+NZayRfr2vcYx5LStQ0KRXcTpUqhtfNOK96VDwU2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250334; 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=9l7d1WvECBQi9EgWpQ1D/hiA9a2++22ykX26IVpksgY=; b=bxs325wmHKzQXIbL4uWv/M+O+5fNoN8g8MGYTk8vKFauD4yHJ2HlJz75nKYGQ3VIzzX8fN HIcIXRJqrAgIETYBWViV6ae8Wt/qC5LA7hhXkzdI9xCZ6ZOnp4odIpoeMp8zOqJc0Yj0E4 YtVhC3cIgrbLiPFYMrn7gPPn1ow8Q78xr8BB/3GtRguJczxCreiWxKEsyehSw7kAwoyEL9 rLp+SjLwcHxcYsq+UT1jBGWF3uAYkWAvaDQ/ouMvoaRz7hj3B7IhPP1xxugvekgrVYeFzO 4ffmQEw/ooI+LWSfudXWwIOQtmhzG7vEYV5jk6M/sRX6Fq0w+BoXr5kUjdto4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250334; a=rsa-sha256; cv=none; b=aanO0c4x2DdEmKs/ukEgXcksz7rD+7LkBGz/APoq4tmjmE01jpsnL0AU69QX2go4Cb690b 5vM47rhJpOmxPT99jDPOTXntijsZl0jHzMe6U7JyvxUACylE62WQ+lZIMDmhGrDA9LCsqq hWhNmChtr6QeMxhse2Kxxj86dBYFXP3f1hm3ecFdiSz8INGaqGzhskB8X0+2zvLhbn4z/Z 5mCQxYbEZK3Et5y5Lno99ZWQsTNNQqv1w3ss8Ft0+sva2qc+bNvvr/l8CMtgDCxuS636Xq yg3+kQddP0WgeiPwmcWoiJp5EPVmkF//UIY3dNtROGDmrixSBp70vZ+vVPej5Q== 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 4TCgvd6NK5z15Dr; Sun, 14 Jan 2024 16:38:53 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Rick Macklem Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:52 +0100 Message-ID: <4014880.cjyAsbXg9l@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="nextPart12634010.pzjrNcfGrq"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart12634010.pzjrNcfGrq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: Rick Macklem Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:38:52 +0100 Message-ID: <4014880.cjyAsbXg9l@ravel> MIME-Version: 1.0 Hi Rick, > I do not have a strong opinion w.r.t. atime, but I do believe that > changing the default would be a POLA violation. While I value POLA very highly, at the same time I do not consider it a sac= rosanct principle that must be followed in every possible circumstances. T= here are many different ways and levels of being amazed, and varying counte= rparties to gain in exchange, so there cannot be any absolute interpretatio= n of it. Moreover, the stricter you are in general, the more you are pushi= ng the project towards fossilization. It's true that there are lots of mec= hanisms to allow both backwards compatibility and evolution in lots of diff= erent cases, but they come at a cost which is increased complexity, amount = of code and configuration, which has to be taken into account as well. Here, I do not think activating 'noatime' by default would be a significant= violation of POLA. On the contrary, I think that almost nobody will notic= e it, so there barely will be any amazement. Why? First case: The user/ad= min doesn't care, so is using the default. Most of them will never ever us= e 'atime' for any purposes. Some will try to use if a few times, discoveri= ng on occasion that they cannot because something messed up with them (if '= atime' is the default) or because they are not maintainted (if 'noatime' is= the default). Second case: The user/admin cares, and wants/needs to avoid= the extra I/O, so decides to uses 'noatime'. These people won't even noti= ce a change, since they are using 'noatime' already. Third case: The user/= admin cares, and wants the access times to be updated. If he's using an ex= plicit 'atime', it's the same as the previous case. If, as is likely, he's= not explicit, he will notice the change as some of his scenarios will star= t to fail, with more or less bad consequences. I don't think this is really= different than lots of changes the project has gone through. The very imp= ortant thing, but the only one, we would have to do is publicizing this par= t correctly ("if you're relying on access times, be sure to change your mou= nt options, and possibly configure your auto-mounting applications and/or o= ther mount helpers so that 'atime' is explicitly enabled."). I address other POLA-related points raised by Mark Millard in a direct resp= onse to his mail. =20 > Please look at this email thread, where the opinion w.r.t. atime > seemed quite different: > freebsd-hackers@ Oct. 5, 2023 > Subject: copy_file_range() doesn't update the atime of an empty file >=20 > I'd put a url here, but gmail always puts the subject line in here when > I copy/paste the url? No problem, I found it online. I only re-subscribed to hackers@ a few months ago after discovering I had b= een seemingly unsubscribed for a while without knowing it. =20 > Basically I did not think that updating the infd's atime when copy_file_r= ange() > did not actually copy any data, but the collective disagreed, so I patched > the NFSv4 client. (I do not know if markj@'s patch did get committed). > They also collectively thought that Linux did a poor job w.r.t. atime. I completely support the view that, if a copy realized through VOP_READ() u= pdates the access time, so should a copy realized through copy_file_range()= =2E That is arguably also an application of POLA, but in fact here is much= more: A matter of correctness. However I fail to see how that thread, as a whole, has any connection with = the discussion we are having. Could you please elaborate? Thanks and regards. =2D-=20 Olivier Certner --nextPart12634010.pzjrNcfGrq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDhwACgkQjKEwQJce JiepJg//Wrlg/nwrqKY24TDuJcaTSX6UehSDPctTEXuJgHoiwIvjrWJpuj7LStsR N50GNJvnbVvrU5izGqa0xbeTlZTMqCHQVOHbuuH6xE9SiugyAfDKOta3siA3/7PF KGXoX/eIxxtDraRvsvTQ4yDOnZcTZbhAsAKo409t/K98FMY/Qun2Z3IKmFrDXeSb OTOC27YfBsimGcqFLfaDp4uhE65yr0Hrh08V55cSUgtoBBfquiP4gvpCN9AN+Psr zgo2ok6E0VNbp4slS8jB2l70oe/VYoDF5qDEV8rxaqwoyHQgmHjgXeEEICkjXbY/ JVJOj6vQk7m+gEZPX8nbBUXL1JRko458u2rzYWEdZ9tzZHv6DZTrd8VYbi3wa6+R gTYqqUaRWXBmuAI8YTqL+yOaIazzBv7hDATW7prVpk7EXrAB6R1DorMC+HDpEhSF n+EdPCikgUBT2KpAD4HypSkDk+YItVMrdt6j3yBBpfhWhtP4RRPF3YqMZwYvJi2O N/IrVT+gJNA1sPpvNBwNOR4epi5il3VyqS0BoAcVRjS48f/VA7LCTHGQPEch++z9 vfSmwOSQmJn7nIsz60cWj5vPDL4rAIYRe3jZI+Hb1z3AH8QWHF+NlDQAieuFsFvB RuCJt156r8RCCNFzXpr5KD5t4gm1um2duXE7/3fdFzo3dWuMHeo= =21UC -----END PGP SIGNATURE----- --nextPart12634010.pzjrNcfGrq-- From nobody Sun Jan 14 16:39:04 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 4TCgvv1WW0z56bwY for ; Sun, 14 Jan 2024 16:39:07 +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 4TCgvt6fvxz4LQK; Sun, 14 Jan 2024 16:39:06 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250346; 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=9eGNO0DjwgmOvt2XRGVkAs7bDrVX2vUQqCJwk50za+c=; b=VV1AMFenC6QAaqScq0mZqmu2ghRMJ3aMteHckVimmDU10e47JJ36ueuHW06IVyeWVALRbs aNLzn6O8b89TPy+xrl+ijD5Mvyow1M7qdNI4NPJb/vT2sW5JLPIDdv+K68zdfYCt2qZlSR BqlegtXK0PNixumNaZI0PVhv/HHz1TRHKVTL46iY5TTBpxFBIZi2ezgPkAUWv8tolVy0zH dpUetBGl49xBNspCRn/FiIWqkYXO9mm+CrTgV9dZMdrPj/UVBWknfvNE0ISJO7QoBRwpRv Mi/m6w5QAWt4uK+PSI39IovJwv9RhAHO0SwZ74bhoSuYrNFg/n4gYbhpPrq1PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250346; 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=9eGNO0DjwgmOvt2XRGVkAs7bDrVX2vUQqCJwk50za+c=; b=qPN+T2fovjOA9FYm9pv8Pk2uONG/pvEgNRXKGkhlD6mI2d5w4aEIQsq49Tnv6W+eKzHYKi XwlYoUjVbAU3DCfvGXpXioVAONZWIapqL6gLfiW1Kn/Vyq+1s2c/FVwOQg9S/zV6K5l/3q MBlKkoh9WlckqsSLAzk+tJkHf+SVpWRGuU1xIt8r+o1cq87Msc9eT+E96Pu495erGm8AXo q6xOwqJffpT5qp0HUMeT48P0b92EE6b6yJLoh1y1KdMOhjPlx67iwhWDtIvbqg9ZxDZGnT Ro6dV4oocjQBVmlX0x04zSddT5tfn+fFaZaGX2WV2W/sSoVnIYtszHZBSgBbyA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250346; a=rsa-sha256; cv=none; b=ZX8y7NveovzuJPkLn22YcBVTAFmRpXxXSjrrDxNsgIhVqy7EAzu2XYd3oHDZYt3L/5SAuf ejWTP/ibG4/+qgmrKoEoiZF3AWZ/9JbZjHQEjI0Nl7x5PXQCiP89mamqlaMg/CQRLbhlks pgBQXJcXx2acNwjsKvIuZ1S+nIZZYvyr5KMbrXIZ9vgSkrGgLsBKoV4pEsutMCu2Q5gCNy nKG2Ncy5iXbvel9q7vOTuDGxW1qtbRTHcLO6+PSpXqZY3RLtaxARDM3MIS0rwcn1Ne9Cyf 3CjSZeH60meOqCfb1blObPf38OGeXzZmmPilY5s4GZJvxl1rK7lil5BVODc6Ew== 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 4TCgvt3Srhz159Z; Sun, 14 Jan 2024 16:39:06 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mark Millard Cc: Current FreeBSD Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:39:04 +0100 Message-ID: <3183964.fD0qBhBWp0@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="nextPart3339611.JsiWIYn8xc"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart3339611.JsiWIYn8xc 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: Sun, 14 Jan 2024 17:39:04 +0100 Message-ID: <3183964.fD0qBhBWp0@ravel> In-Reply-To: MIME-Version: 1.0 Hi Mark, > I never use atime, always noatime, for UFS. That said, I'd never propose > changing the long standing defaults for commands and calls. With this mail, you're giving more detailed objections on the social/political aspects of the proposed changed, or as we usually say more simply, POLA. All your points are already largely weakened by the fact that, to wrap-up in a single sentence at the risk of being slightly caricatural (but then see my other mails), nobody really seems to care seriously about access times. Please read my response to Rick Macklem on POLA, it is already a general answer to all of them. Additionally, I have some specific answers or remarks. > I'd avoid: > A) Having natives & required file systems with mismatching defaults. > ("required" is for spanning efi/msdosfs partitions if the atime/noatime > makes a distinction there. So not just UFS/FFS and ZFS.) The proposed change is general to the system, irrespective of partition types or mount points, so it doesn't have this problem. > B) Having files systems that are not OS specific have unusual defaults > compared to those other OS's when there is documented uniformity. > (openzfs being such an example file system.) The only example I think you can have of this is ZFS, and contrary to what you think is in fact not a problem because of its peculiarities. ZFS stores 'atime' as a filesystem attribute ("property"). It automatically uses its (boolean) value at mount, unless overridden by explicit mount options, so no default value is relevant here. Properties of a dataset are inherited from parents if not set explicitly (well, this is not true for statistics native properties, but 'atime' is not one of them, it is a control one). So, if the value of 'atime' is reported by ZFS for some dataset as coming from a "default" source, necessarily the root dataset is using the same value. Consequently, the only place where the default value (as seen by ZFS) matters is the root dataset. Thus, the only sensible meaning of "having 'noatime' as the default behavior" for ZFS amounts to setting the 'atime' property to off on the root dataset on zpool creation. By doing so, all datasets will inherit the value, unless explicitly overriden. After the zpool creation, each dataset's value of 'atime' cannot be influenced by the system default at all, as is the case for all other similar properties (this is the way ZFS works). In this scheme, it is necessary that OpenZFS keeps its own default value, in case ZFS pools created on other systems are imported on FreeBSD. The only change with respect to current pools is that 'zfs get atime' on the root dataset will return a 'local' source instead of 'default'. And that's all. No change is necessary in ZFS. > C) Having defaults unlike most other closely related operating systems > that support the file system when there is generally documented > uniformity. (No claim to have checked on the uniformity generally.) > (Other BSDs, Unix, Linux, . . .) I didn't check these, but I would bet they all activate 'atime' by default, for "historical reasons". I understand the fear here would be cognitive burden, but again in most cases it won't happen in practice. If you take again the 3 cases developed in the response to Rick, you'll see that only people who really care about having 'atime' are concerned and should change their habits, and so far it seems it's by far the smallest group, and with no significant/compelling use case. People who want 'noatime' and are used to using it can continue to do so without any change. People who don't care, well... don't care. > D) Having defaults for non-native files systems that are different than > the native contexts for the file system have when they have uniformity. > (So, for example, linux ext4 use would get linux etx4 default behavior > for atime vs. noatime if such is basically uniform across most > linux's.) This point is an additional reason why the default should be per system and not by filesystem. As I was writing the word "system", with its ambiguity (does it mean an operating system, or a particular machine?), I've just had another, simple idea: Create a system-wide sysctl knob controlling the default. This would already allow administrators that care to set the value they want in a single place, and not have to tweak the mount point options, the configuration of auto-mounters and other applications mounting filesystems. This doesn't say anything on the problem of FreeBSD's default value, which then becomes that of the default value for the knob. However, the availability of the knob, besides its own usefulness, may convince reluctant people, which logically should be those that care about 'atime', to accept 'noatime' as the default, since it would become easier for them to override it back. > Unless openzfs manges to decide to change that default across OSs, > in my view FreeBSD should have it be left as documented for its use > of openzfs. Given that, having FreeBSD UFS/FFS be the other way > would be problematical in my view, even ignoring defaults for > non-FreeBSD that support UFS/FFS use. Showed above to be a non-problem, see point B). Thanks and regards. -- Olivier Certner --nextPart3339611.JsiWIYn8xc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDikACgkQjKEwQJce JicCEA//T1G2U1WR+zzz5Kkk0ExWW8S9zHfv5ojwSjJFhmpm3OQzRtKMU3K/WtcC UhHimxkV6rxdfGLCQazODWvzxLnCKO8FoFWlNv9V2N+dD0oQrbNXJgPFqbYu3eHR ZCHzjaPzuC4JWrhcI5SkZh808OxuUd17F+b/8Hl6KkSTzD10aTqJ8Rcz1OsEtPwZ 34x8ZzyWMAshJhGnBe+YZKGqFJ8SeuClIFAzccfyGOVGdpIhR4WZ+ljALMG2l/Pg 03igKeHNNCPvV0D8zBQS8fXINLBc7oK3oVWru24u1MEySXhOTA4Ml6Wy3Pvb/DED sPUualoN3WZ3Sq5rZHDESi4ktWjufGz2vh5FH5SlESWgWVpxFcKLfSR3ZNVX5dqr P9gj+uMcuoc5g/YtC8+9jQj7mN6NlnJA4DwqV6q2E8chZRnV6UrU2zoxRZUHJ6eQ fw7o6MbqFm/Dix8W3IqvfQJu0Z1u9dnHOfEYM2sddS2c2UUpABs72na1CeioXnJL hD5Go/1Q10ypULI5ZaUxb0B8OgaqFEpOxrZxPXqjuHUk9/QqH+k7WkD44O9zannU sbQWPotpUasIZWYllk/uutqEMP7l8tNMMQOxDJNJB2npx8k60hW4CXOuzmIJBTc1 9+mtLYR9pscu77T9+YUlC9yJ7YI9teeQdvZSurk1py/sbOemOgs= =Sv/1 -----END PGP SIGNATURE----- --nextPart3339611.JsiWIYn8xc-- From nobody Sun Jan 14 16:39:21 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 4TCgwC5sVbz56c6n for ; Sun, 14 Jan 2024 16:39:23 +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 4TCgwC4G35z4M1b; Sun, 14 Jan 2024 16:39:23 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250363; 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=QKGOCQ3V0qTpVhWN9ZxJXjNnPxvESEPO7ITA00Dq8sw=; b=U3K3n3+frCGGNACzXLJKlLN3qKL1bIe92yYS0/M7aLhfCzIhCcIrv4EhD2JJ/BHUFG618P 5Mj4FbX4l75Sx7pDB+O8hWuvpFvmoxs0d+jq/sWOXHp3xoI4+PfqALYZvHo40sKDaEFesv V4Sm+GfJXtpyD0VbIUtIAl2BzUcBb5Tl6eKBk9jYB748PRzMcqSqJx4VB33Bs50OCKFfDj hbQCqA5o6GVp0pSr0VOAByz29h9SCIBH80eaVNWM947TFCPe071AIBbu4E0vDDyz+frcs4 fgI/RN7fcdBuN4N/kwouUY8hoW8LHzhy0iBmu66bc8qkBX02k74OWIATHNh+9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250363; 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=QKGOCQ3V0qTpVhWN9ZxJXjNnPxvESEPO7ITA00Dq8sw=; b=yayeccq09lC3MoZe/DRB9sPGQOKyhbnvPMXUG+g/NAYIz4L1F7JVUWXMkMo/eMA6naGOqi 13VIuHiokhWlIa4TxsJgVmSrZOrmrUP1TdSDB8Aa4WYimaQ6LwboKmX1GvsHJsTPf7Fa9h mzkFmFAFSEEm4mDK2z/T46bFCcmmrGc+4wYrR9z9hWGC8Jaa6MLYAzXZY6ldZ9ZVuxXjEF dTdDRZEjA2zI26YtWcc0CFzzzpW/ccoibxShyCQHe7AnwZkE0e5baOUwP3aT3hB7esSn3A n0rr4z6+HGaXhSgIaqShC2UDv591r+lzvACtGYAtEbmiBFQhv577w28LzhpRLg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250363; a=rsa-sha256; cv=none; b=pOW4WCJifd2+Fev4WJ26ICcIzmUMPSci9JDTAb6tbRTV6usxKkt6yisPVs+vetQa3a1/5v ERpvPomhO0itxwkJoOc0Js4/3+dJ7A5It4cHjkAXyG2XhnY8iDj0BjGGs4p5+G8HRRKw0Z oX+NUsrsMb7w1ZL8lbvqUBCX4xlyoWacuAkAQC35eNIB9tFzQdiv8c1sH/lKMmNPrVkAqy 8cHHgxeNzedSalJdcW5zvyuZSTrXmiRE1tn1R9/AKuc8MKCAVYSueVtIoPMBteIV1lKo7Z nxAyTBqMXAaAMM78cqqUMm/8wgBNoSGWwEZtLAtHrzfNWJvLucsPvNxEkgzZ/g== 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 4TCgwC0DQvz15BY; Sun, 14 Jan 2024 16:39:22 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: "Rodney W. Grimes" Cc: Mark Millard , Current FreeBSD Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:39:21 +0100 Message-ID: <5611903.lHTDiQ2jlM@ravel> In-Reply-To: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net> References: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.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="nextPart2205692.EItD6Caizc"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2205692.EItD6Caizc Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: "Rodney W. Grimes" Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:39:21 +0100 Message-ID: <5611903.lHTDiQ2jlM@ravel> In-Reply-To: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net> References: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net> MIME-Version: 1.0 Hi Rodney, > ... Very well said Mark ... I don't share that enthusiasm. Please see my direct response to Mark. > Please folks stop tweaking defaults, especially long standing ones, > if you feel the need for noatime, set it, by all means, I have been > for 30 years.... If you're implying that I have been proposing to make 'noatime' the default thoughtlessly, because I jumped in following a question by robert@rrbrussell.com, then you couldn't be further from the truth (please see my other mails). If, despite that, this discussion bothers you, and for reasons that seem to be unrelated with the topic, what can I say? Nothing forces you to participate. Thanks at least for admitting that you're using 'noatime', as well as most of the other backers of the status quo in this discussion. Perhaps that should tell you something. Regards. -- Olivier Certner --nextPart2205692.EItD6Caizc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDjkACgkQjKEwQJce JifYbg/9GF/eU/3sWw0CdJbKqHYanoUSAe82dnBsuzbLpqSGiiJ6J20lBKBZSa9M zhp6ejYDbdwq2v/gZk480RoEvgKc6gJs2LKFxcq8MTzoJddq/hrE9fm2yrXHdbBB 8ajIwwyR/77pbbzaQqTbW/rNjqkDw8m2VxVvidLww7sheLa1N4GrWQnViMEzbPSl twZyOEws+ZHoawGaApxprwEsm6ldDPC9F0/AkqjPQwFoJ+wLQd5wgQaVx3uvQB40 EP4Oybj/TaM+nZEemfsEk4jW2JWaTa4QUKU0wu/b4KQaDDKjkZJ6lK1kyahIjMX7 aa0VHGyWr0p6MwgdLx7TYNCcBS5FXpEybegZ0a2yIe7TEpNkBk09uEbRuaZcxROg //ScD8rhpEED3KjHww0V2wtRv/WUq4A8IAEUPboxfTOqQMylWUeEGgfzAKV7fWBt 8Sz353VUaRHgWd9fOp7TiSdi253cqbBfjzWLkehg4qQbAtFDHZlWnoQGTHgrJQNz yqyrZf584pWQ2RLp1ZY9xrMRlJiN46P78nA9Mhy6dSFWbOUy8lcDhUTpvbcpwROY WXS2De/FDoB28CHbhaJZK08hXhmDr/TAyxhHVREhTJc1ilmlZfmnFULYmAWC8Cl9 3aQ124RT9pltZI9MROHOck8FQd6vjNPj447LQg9zYnPlLOdWA7E= =c7Wn -----END PGP SIGNATURE----- --nextPart2205692.EItD6Caizc-- From nobody Sun Jan 14 16:40:23 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 4TCgxP6s4gz56cJ2 for ; Sun, 14 Jan 2024 16:40:25 +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 4TCgxP4lQFz4PN1; Sun, 14 Jan 2024 16:40:25 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250425; 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=emuOwi1LxLDdX/lwGGBK6PqtrHix39yHhbnwIc7Eez4=; b=e6MHnYAfy026aIaVahGorvuQPDqggzzLE7pxnI5SjqxglGR0cvLLdEsjecmBtjA6DSSS61 Bw78dDl6jR16CyrRme/J8KJRR/rY9I7kjylUe6cqNAUtWjFAwxpdsoqlShc4YgXePMuzTF 6NhdaUZLlWBGRg8hpikfZIhQfGxTvMuWchljRxqDRO5PZYUVbegmFIok1jMummufGEA9i4 eAlE5mpQ0YD0FsUfCim7/4HQDxuqSb+NBBBDbX6pSM3blSxKNvZtZZ7iSLHhpdVwJCECN5 BCynG3avg2M2/DErqPZtq1UTdwxWBC0iy2VMpuXGcQEtGQEgHcKpppAM7I1hlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705250425; 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=emuOwi1LxLDdX/lwGGBK6PqtrHix39yHhbnwIc7Eez4=; b=kIHtzQkUfupK8LeKHFin0nj7wMTG+Mu4gi5DImkzkyYYUgTHy+ayqXJ+9Z7ayaWUuK5zw6 dK0c8lHvWb7NAoUSFuSBdXWgzCMElJwShIqn4eW5P8NOG8J3ocSs76I2MjVZpNmUtSYHca i+oJP4GgRC74rsekA1OI3rNP8nhI6sS/06rlP3w8fLRRjGQferiUMnn6poT2woFmNQU6Mq hvsBLEYk35lZgPPNIL4ijcqrszr8AOsaEWeVbtg3T+6hL0+kV9mXXKzkNfIhM5KGvUF5NX dMCM75Fcgc8GaMj2DpGIHVGF9Q+gbKp5Tsf+r9TYPUsvsg+UmlwcyuPfOaAhaw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705250425; a=rsa-sha256; cv=none; b=evczKc/J+qWMcX6p0gwvAsXzFy/WAZKcezIX+WS1cARge/CZDdbDoh9pFpDKu1HwOKMGft VwCxq89XqkHnmNixzN7a+tIWT4aCv1FkxO8TSdfcWE2k9QmklFQiQqoIT69KuTIe51qP40 SiR46q5xh0flKY95qJ6Di5ZSrN76797Q89xnHRF5LO1PRH5goey9y4DbmyxV7ZgWXoKVJr AtqxB4rDJypEx6qnpPtVJoPwzbnkRxJJMrk1fvxRsqn/RiiZsn5y6QWwahUy/pEFoPd2y5 1zQdkEPRTi9a3ud1HBX+4dkG6io2Ohndj/Kh+iqsX1FEZhCKWFh6V1HPmFryNQ== 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 4TCgxP1bJHz159b; Sun, 14 Jan 2024 16:40:25 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mike Karels Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 Date: Sun, 14 Jan 2024 17:40:23 +0100 Message-ID: <7547882.metmWpjG0I@ravel> In-Reply-To: <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> References: <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> <5A74E928-2F4A-4BD6-8B77-837B793055C3@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="nextPart1969367.yjaICcKom0"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1969367.yjaICcKom0 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: Sun, 14 Jan 2024 17:40:23 +0100 Message-ID: <7547882.metmWpjG0I@ravel> In-Reply-To: <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> MIME-Version: 1.0 Hi Mike, > I like the idea of an option in bsdinstall, but I don't think it is necessary > to check the storage type. It could simply default to noatime. > > I think we should automatically use noatime on SD card images (where bsdinstall > doesn't get used). One of the perhaps unappreciated point and advantage of having 'noatime' as the default is to avoid the complexity of both special casing based on media type and having to configure the different applications that can mount partitions (depending on your uses, there isn't only '/etc/fstab'). Thanks and regards. -- Olivier Certner --nextPart1969367.yjaICcKom0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkDncACgkQjKEwQJce JicRNhAAgB1DSV9TYHDdyZRVjLaoaYa+9b1guhHUEm6bjfec96IHOM3MMEOINNjh sdtnDGPYZKCpBIFmQaBmTs47d4FlIDQmVz/DiNTJ1CijkCFKbndY91yovx/i+xe1 90B2rG+JGoSxzH+kMWyKtH5hiYQCB/xSGDZBkeCzNqoSwmCLNQ1L2tLp9CyxbaU1 /BcjKV49P1J/pvzkC9/Gs3B3DotipTF70iBOhGNPqyS49uHCT20zYjnn/+93rVFU rRyU0IcBzCmfMVxpcuXCprY2Z4JrMPqMj0v0KVEB8AlfAb3m4F4MNKMNA/n5l+fP g+/O37K+jqJZRt5AlPGMGBbYUt76wDn3wZRwJuU27kdZOg1esGEPkCLvHeM210Ql 4i1NE30zuJnA9Skecrg03nlrPHjI/jG4deEoukolUQ2XrNWMtCWjzWcQPXNGy1i8 N3zp4Xxn7i20+O1QEBuvfkKWpRxspPf98rN9XOgC0+clYM6vlG6aJf6Ab6R+Zcxh yM3p4pHCPK/wFm4pjW8+/YMwz0nbB3cw+X09xiFuwGzty6lQkwVEMjlxmBvmOc5b 9Uio9azNLOiONElSbhKIWb9/JJp+sluVycQ6IFDyFk92DA/RVEQDOWerT4nd6anj pfevhMR5Bi8cHjD5xuP0k3fz44RdSgDVerM9Vk/c+zuavzjbHys= =5jbL -----END PGP SIGNATURE----- --nextPart1969367.yjaICcKom0-- From nobody Sun Jan 14 17:23:51 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 4TChvh5ptwz56jSs for ; Sun, 14 Jan 2024 17:24:00 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [208.79.93.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TChvh1nnlz4VhW; Sun, 14 Jan 2024 17:24:00 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Authentication-Results: mx1.freebsd.org; none Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id 013b4107; Sun, 14 Jan 2024 09:23:51 -0800 (PST) From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" To: Olivier Certner cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: noatime on ufs2 In-reply-to: <4014880.cjyAsbXg9l@ravel> References: <4014880.cjyAsbXg9l@ravel> Comments: In-reply-to Olivier Certner message dated "Sun, 14 Jan 2024 17:38:52 +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 Content-Type: text/plain; charset="us-ascii" Content-ID: <21092.1705253031.1@orthanc.ca> Date: Sun, 14 Jan 2024 09:23:51 -0800 Message-ID: X-Rspamd-Queue-Id: 4TChvh1nnlz4VhW 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:25795, ipnet:208.79.88.0/21, country:US] > > I do not have a strong opinion w.r.t. atime, but I do believe that > > changing the default would be a POLA violation. I'm not prepared to just accept that at face value. I can't think of a single instance in at least the last three decades where I have actually used or needed atime for *anything*. And over that time period I have been responsible for running hundreds of UNIX servers. I'm really interested in hearing from people who actively use atime on a regular basis for non-trivial purposes. What are the modern use cases for atime? --lyndon From nobody Sun Jan 14 17:58: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 4TCjgQ6gjyz56mbZ for ; Sun, 14 Jan 2024 17:58:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 4TCjgQ61LVz4Yhr for ; Sun, 14 Jan 2024 17:58:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2cd0c17e42bso91011121fa.0 for ; Sun, 14 Jan 2024 09:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1705255105; x=1705859905; 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=Df+M0vSGv+DqtUQvZzMCiBBwf8K32S2PE2gIKd6IYQU=; b=U5dxMeovUvMglnfgn46z/gSCDTivKkPmU1vkZWRmZ6FL97mKN7FnFrjkvmixg661BP Gr3R1JhvPptbCz6Dx93Hc3JUwa3Iws+BAcpBlmufySczh6PlUEDTpNOknTpzaJ1iOJsE ZrlXy7jpOYetmcedUMByfLa1XeX6idu+opc2AUlppeSZCjtVm/zqgYdV33hhDjwPS9NP zvyIQsJ5JEqMsT5AhwlorbMDCB8+tf5Lh4qrWrbkg69fPeQPkGxtggM9+Xb5oJgiJjIw +JvFJQbCm9xMN2O4+UDf7rhOhdcd5sLS59QOHhzRJ08gDWPO/RMPzv/C5PpzASn1RTSZ 9SJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705255105; x=1705859905; 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=Df+M0vSGv+DqtUQvZzMCiBBwf8K32S2PE2gIKd6IYQU=; b=YM3Rbo/gbga6IBo6l1zXg1SMFWlAau9G4EPq6zd52KQqMgws0y9pjgNOH1tnyX95o7 rd34eAfmKi7R+DDtxPMpQQOXZrr1d72772p0zBkhi1xE+NfQh7IaFCQ7uYxzF9Y8QsGj l9tXFCbm8i2XmarqaxMMo+hNJq1ugWZlAwyjvMsbDeIlCQkM72vip5St3rX0eYPqMhFz uYZSUdiDfYcfPTuR7j2YalTuU4MQPGmffKGwszovsyiOL/SHSjIRwo09qJnDcAMOp61u QlrFlD5PQ8oJl63UYs2+AkA8NMKGCidg0ymY2HMD4qsiRyWLU9fcs/Dy2xlyYQOmNY4M GcjQ== X-Gm-Message-State: AOJu0YyadeK3prtEOmhm5QBDnEzvL7EYHeOcyQItH9gy0cj41leT0g8D yf2wAvUC5rJtp7Cnxxxe8u/psDO/5JL5NiDPrJHapXIGkZ455Mb9+wWB9stZOBU= X-Google-Smtp-Source: AGHT+IF8E8BUiAY0ygoZfuQ8ebJ52y3y5M2pAH+KdMIAzP/V1AHLesRNn8Dx5PJZ4nPIZniQRBT726keoi035eiSutE= X-Received: by 2002:a19:6756:0:b0:50e:7b10:71ab with SMTP id e22-20020a196756000000b0050e7b1071abmr1744493lfj.95.1705255105206; Sun, 14 Jan 2024 09:58: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: <4014880.cjyAsbXg9l@ravel> In-Reply-To: From: Warner Losh Date: Sun, 14 Jan 2024 10:58:13 -0700 Message-ID: Subject: Re: noatime on ufs2 To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" Cc: Olivier Certner , Rick Macklem , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000cc2fc6060eeba4fb" X-Rspamd-Queue-Id: 4TCjgQ61LVz4Yhr 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:15169, ipnet:2a00:1450::/32, country:US] --000000000000cc2fc6060eeba4fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 14, 2024, 10:24=E2=80=AFAM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyndon@orthanc.ca> wrote: > > > I do not have a strong opinion w.r.t. atime, but I do believe that > > > changing the default would be a POLA violation. > > I'm not prepared to just accept that at face value. > > I can't think of a single instance in at least the last three decades > where I have actually used or needed atime for *anything*. And > over that time period I have been responsible for running hundreds > of UNIX servers. > > I'm really interested in hearing from people who actively use > atime on a regular basis for non-trivial purposes. What are > the modern use cases for atime? > The consensus was we'd fix it in the installer. 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. 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. 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. Warner --lyndon > > --000000000000cc2fc6060eeba4fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 14, 2024, 10:24=E2=80=AFAM Lyndon Nerenber= g (VE7TFX/VE6BBM) <lyndon@orthanc.c= a> wrote:
> > I do not= have a strong opinion w.r.t. atime, but I do believe that
> > changing the default would be a POLA violation.

I'm not prepared to just accept that at face value.

I can't think of a single instance in at least the last three decades where I have actually used or needed atime for *anything*.=C2=A0 And
over that time period I have been responsible for running hundreds
of UNIX servers.

I'm really interested in hearing from people who actively use
atime on a regular basis for non-trivial purposes.=C2=A0 What are
the modern use cases for atime?

The consensus was we'd fix it in the ins= taller.

We can't cha= nge ZFS easily, and discovery of the problem, should your assertion be wron= g, for UFS means metadata loss that can't be recovered.

By pushing to the installer, most ins= tallations get most of benefits. And people with special needs see the issu= e and can make an informed choice.

Though in all honesty, I've never been able to measure a spe= ed 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 sett= ings and full read/write and lots of logging. So the harm is minimal typica= lly. 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 typic= ally has only a marginal effect.

Warner

--lyndon

--000000000000cc2fc6060eeba4fb-- From nobody Sun Jan 14 18:04: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 4TCjp55CMkz56nGF for ; Sun, 14 Jan 2024 18:04:13 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [208.79.93.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCjp50Hylz4bQd; Sun, 14 Jan 2024 18:04:12 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Authentication-Results: mx1.freebsd.org; none Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id 3f217a68; Sun, 14 Jan 2024 10:04:10 -0800 (PST) From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" To: Warner Losh cc: Olivier Certner , Rick Macklem , FreeBSD Current Subject: Re: noatime on ufs2 In-reply-to: References: <4014880.cjyAsbXg9l@ravel> Comments: In-reply-to Warner Losh message dated "Sun, 14 Jan 2024 10:58:13 -0700." 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-ID: <54822.1705255450.1@orthanc.ca> Date: Sun, 14 Jan 2024 10:04:10 -0800 Message-ID: X-Rspamd-Queue-Id: 4TCjp50Hylz4bQd 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:25795, ipnet:208.79.88.0/21, country:US] Warner Losh writes: > > I'm really interested in hearing from people who actively use > > atime on a regular basis for non-trivial purposes. What are > > the modern use cases for atime? > The consensus was we'd fix it in the installer. Sure, but my question still stands. I'm genuinely curious to know how (or if) people still use atime. --lyndon From nobody Sun Jan 14 18:14:16 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 4TCk2531mRz56pJV for ; Sun, 14 Jan 2024 18:14:37 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCk2505Mbz4dkQ for ; Sun, 14 Jan 2024 18:14:36 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 14A499; Sun, 14 Jan 2024 19:14:27 +0100 From: "Patrick M. Hausen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Date: Sun, 14 Jan 2024 19:14:16 +0100 References: <4014880.cjyAsbXg9l@ravel> To: Warner Losh , FreeBSD Current In-Reply-To: Message-Id: <14AED5F5-CC24-4A04-89A6-F43628CE563F@hausen.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TCk2505Mbz4dkQ 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:16188, ipnet:217.29.32.0/20, country:DE] Hi folks, that's a really interesting polite and constructive discussion going on here, and a trip down history lane to boot :-) I just want to add one thing to Warner's last argument: > Am 14.01.2024 um 18:58 schrieb Warner Losh : > 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. Recently on the OPNsense forum somehow an increasing number of users started to post worried questions regarding a constant write load on the system disk/SSD in the order of 100 kB/s or some small multitude thereof. Definitely smaller than 1MB/s. That number at first looks like a serious load on the write endurance of your SSD. Then, doing the math it turns out it's absolutely ridiculous. 100 kB/s sums up to 8,640 GB/day (in decimal units). Even the small SSDs typically used for embedded devices like firewalls (32 or 64 G capacity) have a write endurance in the order of 100 or 200 TBW. That's more than 10.000 days or roughly 30 years ... That's why I like following this discussion and every improvement is in then end an improvement, but I consider it mostly a micro optimisation. Kind regards, Patrick P.S. I don't use atime anywhere I knew. From nobody Sun Jan 14 18:53: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 4TCkvK0W1bz56sRw for ; Sun, 14 Jan 2024 18:53:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4TCkvJ5HRmz4lZB for ; Sun, 14 Jan 2024 18:53:48 +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=1705258426; bh=21aoxMc7yPDO6y8hreS43b8GlchdeyYgL8qs/v571kw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=c+OGSf+KM8NawmIHSQ83E1rTpSMlzImZqag7UH2wvnTwfkNsOfu5pTupvGXH4WtJG7S4dyzeCNkMFI4HotDQ9/Yf/I1M/GlrzRUOVo4FLwmMKddTHnfv6fbniWEkYVv3BkCT3UiA45eLoq3y01LYc4S9YeUNcpPf3UJSxk04iFb5KphF3YcijJNYG4mCBe9nfK8qJZdkahGfLBV3yolofP4FSxkxq9V/UC1CPJhPz2bp2f14ZFHZPET502cUo55cf6zc0igYCw3ZCcOsO6WwVmHzt3MGCSHCWvh9eZxeLJsj+AzoDyTSzgmsaajhIQMugTYJU4HfFTT9cBhNKjHzww== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705258426; bh=C+BNfO2ZElPt6hsvMsWH8qx5UEboe7HWYvN1eyVhMy7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DOEYmVYFRUROM2ApTiKRVqmNJRQe2eBsC6495gDY3o4eYTkbSjs/EK9rvlKBjsT3t4NfmVauXnqGfZEeHavlKWnrkXsHfnjl8Jpqf63JFacm3vT5oPD76fgUQAdQg9lkqOYO9xMRVYZcmIq26F29semf0pu2JwPpAlm4YzXcWJhe2sELKgqU1ez4zGsKpg9BNz/MeFHlkHjy9oTq5v3gEjXpGSLyeaOTEoQKtoXz6vYZXD7VdNUK1GxpIuVkijdIWjMO3NsOzpHz7Dz62doTJvjwkbnwoMWbfROByI4RHFyy0IOgNUcoP3jEpBjGGbhF1WL70OUimMKE9tvN6Z7osA== X-YMail-OSG: BqVmXoMVM1lod01ABqckATmJYdfwmwh..cHIVw9AYWQMIqE7VaWL68jqObesNiQ Jv6ybc308M_XGi_QlEw5IrVNZ99G2qsYdZJNTQ7Z5Wq96evXfpwdIWTLNNRonmr5arho9Ia.gSma 6hdXLUFvGhbg1ZLTv_iPDmpW9oOQRYOdoXVvJJR.dIe4tM7f_9h0ymZs7fPcnlrym5kd7tbF0F.t sDFpFzHaTCp4LZM7.l4N4Rm386C6_jlGRFgH0hc03iuzE9BOOnpXzseMGo_1fLCb8edbfmZp0igR NbNPPg7g30uLMQC._LIWVjAjybr5b9O.dF34rhYkWbz.3LuROWxE21OmbAkjavseawKMAiVMU9a1 KiM46OW9ZK9.OOzJPn8SPJG47S7O8CxHkfWr5hA31JVeFSyhIWWsekl5wBxcmz56JF25q5CnICet kTyc10FmHqtCyYTr14KHz5gedk.g4JeId2NUxk4AunfP0Rdi0gkp9sptjj7RZ0pecndupuQ.Tu2y 02usjo4BZBFET3oQCiBNlYjuLXz1Ckzc2BiCmg4pwETw.xnHXtiu4EI8kUBnMobZwkKmYRYg76.p BPyuZ_l8C8VxE8b.gd9_aS1PGsn0zr_knueNPjTWpIVl1x5Pt3dhCe0kQiJhEr2qrAs0rgxyi.YF e16i0yoPb2a1hMqcrxDsvsdHWJSfdbSIH.zQkwWbtStyMbOFT6bEBgg8gVPdfw4wLkHx1vdmRDLw 30KFAo40Odc9919xcuJa.Tb8PfMn88SojUs6Kh8j9YXBcW.agzvQvw8RzqNIWCIs3B1IR_0x8.Ob 7pQGAP6xXuXI2C7fFPa0ru8hMgnIbHkCS52MQSPgojNQnKMFeS3xgjVLIwgb3WRJwN8l_CpoIHmO 6XRRRW8nlVpzrI3prJ4VQAsW8tn4WOpH4TbFhaMRlsWunrIkO.4qg4oiG6Tp3RVVzhCoGNdgOC_g _oDEReegwVugWv0dEuTC4TTbP_WiIeKOOI19fVgSwThSUdehPzV_HtAcA9N7zLhh7PU0I5M.WjVB L_FnMJU9aDKiZMRMcF7GdG_ea.CTBEvXuw5BbLpyWG0DQoX3_CeymfL8_WY1M7w.qyjyrxSIMNLu w13XJTzOqTZy0BUKVaD5H5V2sfZJ7QXznAPdm_9CujKoJuq2mek1vg_J5NrmU9OSClLBE793Q5dV BIC9nwCJp8guyM12IgofX7xW8Cg93NnEsPc2PoaiRD2Jx4krHjlFrHZL2wZMIFl9BoXcafN1sBfE 44Jeptv.MeJHCNMKwWdvwULGnVcooj7sfRw.PTHEG4qWzcQRad9IRSF1U3d3zHFbfM_kHqgtspF7 fH.9fq8mn1Z.c6ghZj68N0AvsyckhVbM24rOgUhzJSYJuBJG9XduOZamoSU0c5jj0ZR9aOg2krsP nb_oXWyZsNTgpjnMAwV0owT2LfPMcBXP.xeiv.l1MFv4yQhGWUB0S9j4ZHTRRrZ3ALL4DAgXNco9 khL5J3.yHp4O2dXyZS9XHRw.t2Pg3GlYs.Kw.7kMzv8AB3auB7xSPTTBDXuyOGI1M2TSCnVl.z4i KcTfMX6oQgYU94N_BxRUu6y5Q4KzPqW8wHOp3OkxmrkSYU5mCHTmBGS4OIE4rGKTxEEaNhg.24yZ Nhny9flIof0LzdQCCpZU6NBfdkHHCNmiFSW_0ZYMTYYeG_2XO3lL9BUq7V8kUW1oUrcql499i83Z .IVOjKGyK.5fOEPg_TuqzQTW.utc8dU555J1FxY.28OJ_6nXBlNtbm6VkvBSiuPmpQLWCnaH19NV 8cSFSwlQl5A4LERU4jZtYR.otAjoui_UP4_v41odukDTRKaIOuYprTOYAK4e5PQOsnb99jcWMOuM 8pNX00JAMRo4K3T1y1umsFAazkYMRtJ8aqkJrkLiXFpDC_hi_hdLaYM1wptG2MW92np8bUd.usss yl0q2ct.dSHkCjjjAFE_x2lMge0XFrirlVH8398REQg7b3q8hgmXPjhpaE2kaSC9mRo9gUA80faN YhzTQqnLREix9FF7aXQ0HMBHWzz0HggbPDrqEeU.8ejzKl6oDFcLatrg6BAiUyi7SwLT6TKQwrvw bK0YGmYffJMpgQeYCchErD9S1f9O83lSUENj_WbjqSDXM2jaqYurQlf_bPI8aPwv4n4aETvQhKn6 7FlqFhLBLsRup_xDRfrXnZGac5aurvNdMck31LoBsuDaJlKeKde9IcHtZ7JdXfsP_tjoTPDytHp. q.8ENgP168_uIgZiosh3H_NRaZUPsowC_R4uYYXHRTSd4SCBLNM_DeEW0DqKlj9CPi43zg6d6kb7 i X-Sonic-MF: X-Sonic-ID: 18dfb917-8bfe-40d6-940c-031e3108f061 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Jan 2024 18:53:46 +0000 Received: by hermes--production-gq1-78d49cd6df-szbbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c3a765c005fc3c7c0bae404bbd72dcfd; Sun, 14 Jan 2024 18:53:45 +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: <3183964.fD0qBhBWp0@ravel> Date: Sun, 14 Jan 2024 10:53:34 -0800 Cc: Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com> References: <3183964.fD0qBhBWp0@ravel> To: Olivier Certner X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TCkvJ5HRmz4lZB 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 14, 2024, at 08:39, Olivier Certner wrote: > Hi Mark, >=20 >> I never use atime, always noatime, for UFS. That said, I'd never = propose >> changing the long standing defaults for commands and calls. >=20 > With this mail, you're giving more detailed objections on the = social/political aspects of the proposed changed, or as we usually say = more simply, POLA. >=20 > All your points are already largely weakened by the fact that, to = wrap-up in a single sentence at the risk of being slightly caricatural = (but then see my other mails), nobody really seems to care seriously = about access times. I seriously care about having a lack of access times. Yet, I've no objection to needing to be explicit about it in commands and subroutine interfaces, given the long standing interfaces (defaults). It would be different if I could not achieve the lack of access times. That defaults do not block having the desired settings makes the change optional, not technically required. The defaults are, thus, primarily social/political aspects of interfaces, not technical requirements to make things work. Given that, I explicitly claim that avoiding POLA at this late stage is my preference for the priority of competing considerations. I make no claim of knowing the majority view of the tradeoffs. I would claim that, if the majority is not by just some marginal amount, contradicting that majority view for this would not be appropriate. (Again: the social/political aspects.) And, hopefully, this is my last contribution to this particular bike shed. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 14 22:27:32 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 4TCqf013F2z57JP6 for ; Sun, 14 Jan 2024 22:27:36 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 4TCqdz5Dbgz4NX8; Sun, 14 Jan 2024 22:27:35 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 40EMRWJg063356; Mon, 15 Jan 2024 07:27:32 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 15 Jan 2024 07:27:32 +0900 From: Tomoaki AOKI To: Mark Millard Cc: Olivier Certner , Current FreeBSD Subject: Re: noatime on ufs2 Message-Id: <20240115072732.85c2213714a658d3b98ab830@dec.sakura.ne.jp> In-Reply-To: <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com> References: <3183964.fD0qBhBWp0@ravel> <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (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: 7bit X-Rspamd-Queue-Id: 4TCqdz5Dbgz4NX8 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:7684, ipnet:153.125.128.0/18, country:JP] On Sun, 14 Jan 2024 10:53:34 -0800 Mark Millard wrote: > On Jan 14, 2024, at 08:39, Olivier Certner wrote: > > > Hi Mark, > > > >> I never use atime, always noatime, for UFS. That said, I'd never propose > >> changing the long standing defaults for commands and calls. > > > > With this mail, you're giving more detailed objections on the social/political aspects of the proposed changed, or as we usually say more simply, POLA. > > > > All your points are already largely weakened by the fact that, to wrap-up in a single sentence at the risk of being slightly caricatural (but then see my other mails), nobody really seems to care seriously about access times. > > I seriously care about having a lack of access times. Yet, I've no > objection to needing to be explicit about it in commands and > subroutine interfaces, given the long standing interfaces (defaults). > It would be different if I could not achieve the lack of access > times. That defaults do not block having the desired settings makes > the change optional, not technically required. The defaults are, > thus, primarily social/political aspects of interfaces, not > technical requirements to make things work. > > Given that, I explicitly claim that avoiding POLA at this late stage > is my preference for the priority of competing considerations. I > make no claim of knowing the majority view of the tradeoffs. I would > claim that, if the majority is not by just some marginal amount, > contradicting that majority view for this would not be appropriate. > (Again: the social/political aspects.) > > And, hopefully, this is my last contribution to this particular > bike shed. > > === > Mark Millard > marklmi at yahoo.com I would prefer violating POLA here, with, for example, forcing admins to choose explicitly with installer menu Choose whether you need to retain last file access time or not: 1: Don't keep (current default) 2: Keep last one (default before 15.0) by hand, or via installer configuration or additional scripts. Of course, existing installations should not be affected. -- Tomoaki AOKI From nobody Sun Jan 14 22:29:48 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 4TCqhh6YcTz57K0B for ; Sun, 14 Jan 2024 22:29:56 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4TCqhh3t08z4PrH; Sun, 14 Jan 2024 22:29:56 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 40EMTmuo003131; Sun, 14 Jan 2024 22:29:48 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 40EMTmhw003130; Sun, 14 Jan 2024 22:29:48 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202401142229.40EMTmhw003130@donotpassgo.dyslexicfish.net> Date: Sun, 14 Jan 2024 22:29:48 +0000 Organization: Dyslexic Fish To: olce@freebsd.org, jamie@catflap.org Cc: freebsd-current@freebsd.org Subject: Re: noatime on ufs2 References: <2136329.mxFCRLsXLg@ravel> <202401111956.40BJuURB045685@donotpassgo.dyslexicfish.net> <3172137.KEUK7n9DnO@ravel> In-Reply-To: <3172137.KEUK7n9DnO@ravel> User-Agent: Heirloom mailx 12.4 7/29/08 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: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Sun, 14 Jan 2024 22:29:48 +0000 (GMT) X-Rspamd-Queue-Id: 4TCqhh3t08z4PrH 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:20473, ipnet:2001:19f0:7400::/38, country:US] Olivier Certner wrote: > I've mentioned your answer in another response to Lyndon Nerenberg when developing a more general argument that 'atime' is generally flawed for these kinds of use cases (finding the last use, finding files to backup, etc.). It's true that the ability to deactivate 'atime''s implicit updates per-process would cater to more use cases, and it's an interesting idea. Essentially, though, you can't guarantee that some applications, or simply administrators typing commands at the shell, are not going to throw away your precious access times, so can't rely (in a strong sense) on them. Thanks for the heads-up - I've only now had a chance to catch up with the thread. You are of course right - atime can be affected by so many different things that it can't be relied upon. I just thought a per-process method would be a good compromise to avoid blanket atime changes across the system - both for atime usefulness, and I/O, but as you say, as it's unreliable to rely on anyway, this solution may be making things worse by giving a false sense of reliability. And to further bolster your point, whilst I have wished for more granuality with respect to controlling atime updates, for years I've run everything with noatime.. Even when I thought it was nice to keep atime relatively accurate, I soon realised that I simply never used it anyway! > Sure for backups and snapshots. I agree you'd better have backup perimeters coinciding with file systems partitions and use snapshots to get the smoothest possible experience. But snapshots alone do not guarantee the "correctness" of a backup (the ability to restart smoothly from it). Yeah, it's more like a snapshot at the time of a power failure, but of course, it's better than running on a live filesystem because a file may be missed completely if moved whilst the backup is running. But short of shutting everything down prior to taking the snapshot (I remember at last job some very old machines without snapshotting or decent db journalling capabilities being taken down for hours every night, so that the whole backup ran in a minimal boot environment!), I don't know of a cleaner solution... (though I'm sure some exist.. after all, live migrations between hosts are a thing these days.. I guess I need to do some homework on the matter! :-) ) Thanks again, Jamie 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-- From nobody Sun Jan 14 23:15:37 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 4TCrjR36D3z56x8F for ; Sun, 14 Jan 2024 23:15:39 +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 4TCrjR2Y5gz4X1d; Sun, 14 Jan 2024 23:15:39 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705274139; 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=ng804tC5a00G33q3VQar1lZoI31SDh9lgFKBXNo0l8E=; b=thg+qCNY2N9woCwsQOexZ0VqOxwJ+LQH1Nxk9fHp6rcZ4KMbQF5USvTyt7bEiuFPM4PB/i IUZ+8Ho53dmAnaz22w8i6mPL8CEv3ITi4hj3/44ImR5p1ekxqA2dsgTkL9vq2TWDVQzRDT kZMxR+HsAsil9EOmQPhCYctvZ3dP7n0ntMdKIBwQZuGyyDjygaQA68b/rN2QWR5pvvqvkA 9+4q3IggEXTbQClhV8mjzz1iBI6Yx0nzO7EwpG9st7fNVgq8yrCBGwN3jo9/cXGgYUn0oV 0HqpKNajv8vQoNBH6JdHTB+c0fPzchGYBSytSym57gGdgHGVy7fVDXlivP/znw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705274139; 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=ng804tC5a00G33q3VQar1lZoI31SDh9lgFKBXNo0l8E=; b=wJDWWp0khPi1t4Aq9ziYLFL+A4/TOSLm7nXlIiPTno80snIDws0j8k/YJw8ERRdSvcs3BU GqGUHr7CHLrPQS9zmuisNgFDnm8mpwadKiNuAJLn6uCSwcYIeetVQvRWOzI4VDwGiXPmUO CbAAxz5gBKnm0+XyKmi9JTHyX78s9TFDE9QPgRTLqGiMa4ZQWC+lhDqzTOpW811EQOnuVS BnJ+E6xYi4RuyivQYAGdhqYMUQOVTlDNF0cuScTii4nFfeKUdNNK5e9YEh2GOie5i7ushK Br19Q779mRFsDtAwYOlaM9t5jOn3o2ZTr/9xrUra9HiQiM1ZgZpVKHsDqRzQlg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705274139; a=rsa-sha256; cv=none; b=WJZKtA46AD56J3o4Ex/yuwTsbWyJXnGRFViEe2xo8t2/eL+BgT9/bEBGFko0Rf43fUnXSn VhXtyC4bR0r9y0qnjqPHo6yGIc5olHFj5SSjRyO76kuOORNKICIfpevAqTbXaDDzE52ch/ inBbVnoT4Kk6O+nmMQ0GOKurClG6j2E3h0SxPeWrRDBpFoKwsS8YKdrzO//Vlz8DoND7Xu OWSfb8ZSt3FatAPU09bJNxk/vL9MqMR4gSbvDbGW7JM056cNtt+GwIPAIn2Op1mA+cksNt YYiW5OdHZ8jLAOZADKWisfkMiRZDdVWYeQiSicQQCPeQWd4e756shYX20B0ucw== 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 4TCrjQ6QZCz1CPv; Sun, 14 Jan 2024 23:15:38 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Mark Millard Cc: Current FreeBSD Subject: Re: noatime on ufs2 Date: Mon, 15 Jan 2024 00:15:37 +0100 Message-ID: <12921270.kl7XSLc1hW@ravel> In-Reply-To: <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com> References: <3183964.fD0qBhBWp0@ravel> <6A477CBE-692E-49F9-B21E-2C0D29F09766@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="nextPart3817457.GDe4BPZbBA"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart3817457.GDe4BPZbBA 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, 15 Jan 2024 00:15:37 +0100 Message-ID: <12921270.kl7XSLc1hW@ravel> In-Reply-To: <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com> MIME-Version: 1.0 Hi Mark, > I seriously care about having a lack of access times. Then, I think elaborating on your use cases would be valuable to the discussion, if by chance you want to and can share about them. Thanks and regards. -- Olivier Certner --nextPart3817457.GDe4BPZbBA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmWkaxkACgkQjKEwQJce Jif56RAAi8GwX3WPjXvkwGj5wJl2UEa0onUoav2yCTmsDXKpgBk84eJLF5NhcAT9 MIJG/JW46qB1Fa5gE+Xu0m9CTFv0Jn1PHEG5d5YP5EZc9kDxafRgMrs0eYd+gA8A /TBG+MXBGASM2z/X71H2OmuvBOO2wwuln1ofp1mtNZSPA5ct9xfDbBqh9M3k9dUe yhxo5ATQRGfejhF/xROXPIRtCSaEth+49tmcLLiBntO9J2y1ic7fbgOKpKVuvZ6H svSRNE6/gensgb6GKhhoSyeEp8HAUi5sqU8rptSFw/eJ0cxL//V5FzDuFHAD0F4F 39OYFQN9ipZCXy2h1Qz0WscV5UtFNtfmC5S2uPnj3toTa0nVKk8Xk3jhm+IEDkKU 61MtFRBeDgTDKJydIcj+OyPrgBoItzEQzyAY9B4XSfV93RD6YrzqntoURFiTqe6Z kNRCQfGp7nywoJtu2tqgIv38DpDT5wJS5d5BPp2kJWETjfa839VOnx78Qib4KUHo 57YO87yYX++VU5L9TnXg72Ln0AEiCno5U1D7m0iFjNjIuGtUUn1E+WDwOlt4LRhG k3z69FfKR6qDZANEiidQdy5gjxg16T5+GdBZCeJayD+0FP2wmSGoJ+1Hr1O8R1fN qcJDR+yQGOZ6Urhr8lM+5FkXFZee/LA+WUivKUUEreGIKcI/WW0= =SJiM -----END PGP SIGNATURE----- --nextPart3817457.GDe4BPZbBA--