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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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: <jamie@donotpassgo.dyslexicfish.net>
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 <jamie@catflap.org>
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>
<ZZWz-14AXfcSY2AD@spindle.one-eyed-alien.net>
<46C8698A-A004-4B5F-9107-6D9FD3685074@iitbombay.org>
<ZZXui1gm0IIVoWca@spindle.one-eyed-alien.net>
<20240104183539.cef54811b98fe53c5841edca@dec.sakura.ne.jp>
<202401041914.404JEJCm083648@donotpassgo.dyslexicfish.net>
<CANCZdfrUHDbWd7_SzsF67be6xjpXPVQUD5y33DPpD-tO_0UMTw@mail.gmail.com>
In-Reply-To: <CANCZdfrUHDbWd7_SzsF67be6xjpXPVQUD5y33DPpD-tO_0UMTw@mail.gmail.com>
User-Agent: Heirloom mailx 12.4 7/29/08
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <imp@bsdimp.com> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <zlei@FreeBSD.org>
In-Reply-To: <20240107185057.73c66433@thor.intern.walstatt.dynvpn.de>
Date: Mon, 8 Jan 2024 11:12:13 +0800
Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>
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 <freebsd@walstatt-de.de>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
> On Jan 8, 2024, at 1:50 AM, FreeBSD User <freebsd@walstatt-de.de> =
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <jakob@alvermark.net>)
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 <jakob@alvermark.net>)
id 1rMm7o-000CjC-Ry
for freebsd-current@freebsd.org; Mon, 08 Jan 2024 10:40:52 +0100
Message-ID: <ae34b3e9-1d26-48e0-8f18-7ba188d771d9@alvermark.net>
Date: Mon, 8 Jan 2024 10:40:52 +0100
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <jakob@alvermark.net>
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 <tuexen@FreeBSD.org>
>> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <naddy@mips.inka.de>
To: freebsd-current@freebsd.org
Subject: Move u2f-devd into base?
Message-ID: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
In-Reply-To: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 8 Jan 2024 08:18:38 -0700
Message-ID: <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
Subject: Re: Move u2f-devd into base?
To: Christian Weisgerber <naddy@mips.inka.de>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
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 <naddy@mips.inka.=
de>
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
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisger=
ber <<a href=3D"mailto:naddy@mips.inka.de">naddy@mips.inka.de</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">We have FIDO/U2F support for S=
SH in base.<br>
<br>
We also have a group "u2f", 116, in the default /etc/group file.<=
br>
<br>
Why do we keep the devd configuration (to chgrp the device nodes)<br>
in a port, security/u2f-devd?=C2=A0 Can't we just add this to base, too=
?<br>
It's just another devd configuration file.<br></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">This properly belongs to devf=
s.conf no? Otherwise it's a race...=C2=A0</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- <br>
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 <a href=3D"mailto:n=
addy@mips.inka.de" target=3D"_blank" rel=3D"noreferrer">naddy@mips.inka.de<=
/a><br>
<br>
</blockquote></div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <junchoon@dec.sakura.ne.jp>
To: Warner Losh <imp@bsdimp.com>
Cc: Christian Weisgerber <naddy@mips.inka.de>,
FreeBSD Current
<freebsd-current@freebsd.org>
Subject: Re: Move u2f-devd into base?
Message-Id: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp>
In-Reply-To: <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
<CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <imp@bsdimp.com> wrote:
> On Mon, Jan 8, 2024, 7:55$B".(BAM Christian Weisgerber <naddy@mips.inka.de>
> 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 <junchoon@dec.sakura.ne.jp>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Mon, 8 Jan 2024 16:35:04 +0000 (UTC)
(envelope-from kevans@FreeBSD.org)
Message-ID: <b38c7956-17d8-4c6a-a56a-42befdf35c17@FreeBSD.org>
Date: Mon, 8 Jan 2024 10:35:03 -0600
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
<CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
<20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp>
From: Kyle Evans <kevans@FreeBSD.org>
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 <imp@bsdimp.com> wrote:
>
>> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber <naddy@mips.inka.de>
>> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <theraven@FreeBSD.org>
In-Reply-To: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp>
Date: Mon, 8 Jan 2024 17:12:06 +0000
Cc: Warner Losh <imp@bsdimp.com>,
Christian Weisgerber <naddy@mips.inka.de>,
FreeBSD Current <freebsd-current@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7E2DE69-6617-450B-BCEE-BCE2C9894E7F@FreeBSD.org>
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
<CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
<20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp>
To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
On 8 Jan 2024, at 16:30, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de> <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
In-Reply-To: <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
From: Xin LI <delphij@gmail.com>
Date: Mon, 8 Jan 2024 09:30:05 -0800
Message-ID: <CAGMYy3vsiy=TjDkB2ebCD6sDsUvruwXJOjOYf=3f4BhqzFySKA@mail.gmail.com>
Subject: Re: Move u2f-devd into base?
To: Warner Losh <imp@bsdimp.com>
Cc: Christian Weisgerber <naddy@mips.inka.de>, FreeBSD Current <freebsd-current@freebsd.org>
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 <imp@bsdimp.com> wrote:
>
>
> On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber <naddy@mips.ink=
a.de>
> 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
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 7:19=E2=80=
=AFAM Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber &=
lt;<a href=3D"mailto:naddy@mips.inka.de" target=3D"_blank">naddy@mips.inka.=
de</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">We have FIDO/U2F support for SSH in base.<br>
<br>
We also have a group "u2f", 116, in the default /etc/group file.<=
br>
<br>
Why do we keep the devd configuration (to chgrp the device nodes)<br>
in a port, security/u2f-devd?=C2=A0 Can't we just add this to base, too=
?<br>
It's just another devd configuration file.<br></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">This properly belongs to devf=
s.conf no? Otherwise it's a race...</div></div></blockquote><div><br></=
div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
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=
.</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e"><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace">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><=
div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"=
>Cheers,</div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <junchoon@dec.sakura.ne.jp>
To: Kyle Evans <kevans@FreeBSD.org>
Cc: freebsd-current@freebsd.org
Subject: Re: Move u2f-devd into base?
Message-Id: <20240109030015.bb01527d642a31554647cfa0@dec.sakura.ne.jp>
In-Reply-To: <b38c7956-17d8-4c6a-a56a-42befdf35c17@FreeBSD.org>
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de>
<CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
<20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp>
<b38c7956-17d8-4c6a-a56a-42befdf35c17@FreeBSD.org>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <kevans@FreeBSD.org> wrote:
> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh <imp@bsdimp.com> wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber <naddy@mips.inka.de>
> >> 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 <junchoon@dec.sakura.ne.jp>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de> <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
<20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> <b38c7956-17d8-4c6a-a56a-42befdf35c17@FreeBSD.org>
In-Reply-To: <b38c7956-17d8-4c6a-a56a-42befdf35c17@FreeBSD.org>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 8 Jan 2024 11:36:37 -0700
Message-ID: <CANCZdfou_gt9J6gt1fUkzGS1ZbfT1Z64Oz8S52J5z+c+CfBcVQ@mail.gmail.com>
Subject: Re: Move u2f-devd into base?
To: Kyle Evans <kevans@freebsd.org>
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 <kevans@freebsd.org> wrot=
e:
> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh <imp@bsdimp.com> wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <naddy@mips.=
inka.de>
> >> 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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 9:35=E2=80=AFA=
M Kyle Evans <<a href=3D"mailto:kevans@freebsd.org">kevans@freebsd.org</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On=
1/8/24 10:30, Tomoaki AOKI wrote:<br>
> On Mon, 8 Jan 2024 08:18:38 -0700<br>
> Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">im=
p@bsdimp.com</a>> wrote:<br>
> <br>
>> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <<a h=
ref=3D"mailto:naddy@mips.inka.de" target=3D"_blank">naddy@mips.inka.de</a>&=
gt;<br>
>> wrote:<br>
>><br>
>>> We have FIDO/U2F support for SSH in base.<br>
>>><br>
>>> We also have a group "u2f", 116, in the default /etc=
/group file.<br>
>>><br>
>>> Why do we keep the devd configuration (to chgrp the device nod=
es)<br>
>>> in a port, security/u2f-devd?=C2=A0 Can't we just add this=
to base, too?<br>
>>> It's just another devd configuration file.<br>
>>><br>
>><br>
>> This properly belongs to devfs.conf no? Otherwise it's a race.=
..<br>
>><br>
>> Warner<br>
>><br>
>> -- <br>
>>> 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 <a href=
=3D"mailto:naddy@mips.inka.de" target=3D"_blank">naddy@mips.inka.de</a><br>
> <br>
> It's devd.conf materials. It actually is security/usf-devd/files<b=
r>
> u2f.conf and its contents is sets of notify 100 { match "vendor&q=
uot; ...<br>
> match "product" ... action "chgrpy u2f ..." };.<br=
>
> Some hase more items in it, though.<br>
> <br>
> So it should be in ports to adapt for latest products more quickly tha=
n<br>
> in base, I think.<br>
> <br>
<br>
I don't see any obvious reason that we can't compromise and have a =
<br>
baseline of products in base and just use the port for new products not <br=
>
yet known to base.=C2=A0 These vendors presumably aren't going to quick=
ly <br>
repurpose some PID for a non-u2f thing, much less in a way that we care <br=
>
about.<br></blockquote><div><br></div><div>Yea, I just wonder why it has to=
be devd.conf, and not devfs.conf. What are</div><div>we missing from that =
to make this doable generically? If we want it safe, we</div><div>may need =
some additional work around the whole ugen thing it uses.</div><div><br></d=
iv><div>Warner=C2=A0</div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de> <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
<CAGMYy3vsiy=TjDkB2ebCD6sDsUvruwXJOjOYf=3f4BhqzFySKA@mail.gmail.com>
In-Reply-To: <CAGMYy3vsiy=TjDkB2ebCD6sDsUvruwXJOjOYf=3f4BhqzFySKA@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 8 Jan 2024 11:39:32 -0700
Message-ID: <CANCZdfp=GXN+sYYSKGp6NUhHokCQC7-1NKPeV1ecJMae-ghySw@mail.gmail.com>
Subject: Re: Move u2f-devd into base?
To: Xin LI <delphij@gmail.com>
Cc: Christian Weisgerber <naddy@mips.inka.de>, FreeBSD Current <freebsd-current@freebsd.org>
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 <delphij@gmail.com> wrote:
> On Mon, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote=
:
>
>> On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber <naddy@mips.in=
ka.de>
>> 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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 10:30=E2=80=AF=
AM Xin LI <<a href=3D"mailto:delphij@gmail.com">delphij@gmail.com</a>>=
; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On M=
on, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh <<a href=3D"mailto:imp@bs=
dimp.com" target=3D"_blank">imp@bsdimp.com</a>> wrote:</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024, 7:5=
5=E2=80=AFAM Christian Weisgerber <<a href=3D"mailto:naddy@mips.inka.de"=
target=3D"_blank">naddy@mips.inka.de</a>> wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">We have FIDO/U2F support for SSH in ba=
se.<br>
<br>
We also have a group "u2f", 116, in the default /etc/group file.<=
br>
<br>
Why do we keep the devd configuration (to chgrp the device nodes)<br>
in a port, security/u2f-devd?=C2=A0 Can't we just add this to base, too=
?<br>
It's just another devd configuration file.<br></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">This properly belongs to devf=
s.conf no? Otherwise it's a race...</div></div></blockquote><div><br></=
div><div style=3D"font-family:monospace,monospace">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.</div></div></div></blo=
ckquote><div><br></div><div>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><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div style=3D"font-family:monospace,mon=
ospace">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.</div></=
div></div></blockquote><div><br></div><div>Totally agree here.=C2=A0</div><=
div><br></div><div>Warner</div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZwLx1RxlY6xuvFV@lorvorc.mips.inka.de> <CANCZdfqpbL=QNgTwBveUpBooucX2MbfZnR9dw4w25_TXYOyuDg@mail.gmail.com>
<20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp>
<b38c7956-17d8-4c6a-a56a-42befdf35c17@FreeBSD.org> <CANCZdfou_gt9J6gt1fUkzGS1ZbfT1Z64Oz8S52J5z+c+CfBcVQ@mail.gmail.com>
In-Reply-To: <CANCZdfou_gt9J6gt1fUkzGS1ZbfT1Z64Oz8S52J5z+c+CfBcVQ@mail.gmail.com>
From: Xin LI <delphij@gmail.com>
Date: Mon, 8 Jan 2024 10:43:56 -0800
Message-ID: <CAGMYy3tTG31ThX0sWH=kiDv=gdKniZ0FNRf-pZDgdt5uM58wWQ@mail.gmail.com>
Subject: Re: Move u2f-devd into base?
To: Warner Losh <imp@bsdimp.com>
Cc: Kyle Evans <kevans@freebsd.org>, 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 <imp@bsdimp.com> wrote:
>
>
> On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyle Evans <kevans@freebsd.org> wr=
ote:
>
>> On 1/8/24 10:30, Tomoaki AOKI wrote:
>> > On Mon, 8 Jan 2024 08:18:38 -0700
>> > Warner Losh <imp@bsdimp.com> wrote:
>> >
>> >> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <naddy@mips=
.inka.de>
>> >> 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
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 10:37=E2=80=
=AFAM Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyl=
e Evans <<a href=3D"mailto:kevans@freebsd.org" target=3D"_blank">kevans@=
freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On 1/8/24 10:30, Tomoaki AOKI wrote:<br>
> On Mon, 8 Jan 2024 08:18:38 -0700<br>
> Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">im=
p@bsdimp.com</a>> wrote:<br>
> <br>
>> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <<a h=
ref=3D"mailto:naddy@mips.inka.de" target=3D"_blank">naddy@mips.inka.de</a>&=
gt;<br>
>> wrote:<br>
>><br>
>>> We have FIDO/U2F support for SSH in base.<br>
>>><br>
>>> We also have a group "u2f", 116, in the default /etc=
/group file.<br>
>>><br>
>>> Why do we keep the devd configuration (to chgrp the device nod=
es)<br>
>>> in a port, security/u2f-devd?=C2=A0 Can't we just add this=
to base, too?<br>
>>> It's just another devd configuration file.<br>
>>><br>
>><br>
>> This properly belongs to devfs.conf no? Otherwise it's a race.=
.<br>
>><br>
>> Warner<br>
>><br>
>> -- <br>
>>> 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 <a href=
=3D"mailto:naddy@mips.inka.de" target=3D"_blank">naddy@mips.inka.de</a><br>
> <br>
> It's devd.conf materials. It actually is security/usf-devd/files<b=
r>
> u2f.conf and its contents is sets of notify 100 { match "vendor&q=
uot; ...<br>
> match "product" ... action "chgrpy u2f ..." };.<br=
>
> Some hase more items in it, though.<br>
> <br>
> So it should be in ports to adapt for latest products more quickly tha=
n<br>
> in base, I think.<br>
> <br>
<br>
I don't see any obvious reason that we can't compromise and have a =
<br>
baseline of products in base and just use the port for new products not <br=
>
yet known to base.=C2=A0 These vendors presumably aren't going to quick=
ly <br>
repurpose some PID for a non-u2f thing, much less in a way that we care <br=
>
about.<br></blockquote><div><br></div><div>Yea, I just wonder why it has to=
be devd.conf, and not devfs.conf. What are</div><div>we missing from that =
to make this doable generically? If we want it safe, we</div><div>may need =
some additional work around the whole ugen thing it uses.</div></div></div>=
</blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">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").</div><br></div><div><div class=3D"gmail_default" style=3D"fo=
nt-family:monospace,monospace">Cheers,</div><br></div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <marklmi@yahoo.com>
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 <marklmi@yahoo.com>
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <FD723948-DFB6-4F97-A9FC-D1D1C2F91D65@yahoo.com>
Date: Mon, 8 Jan 2024 12:29:50 -0800
To: David Chisnall <theraven@FreeBSD.org>,
Current FreeBSD <freebsd-current@freebsd.org>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
References: <FD723948-DFB6-4F97-A9FC-D1D1C2F91D65.ref@yahoo.com>
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 <theraven_at_FreeBSD.org> wrote on
Date: Mon, 08 Jan 2024 17:12:06 UTC :
> On 8 Jan 2024, at 16:30, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> =
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h>
In-Reply-To: <ZZqmmM-6f606bLJx@int21h>
From: Xin LI <delphij@gmail.com>
Date: Mon, 8 Jan 2024 12:41:02 -0800
Message-ID: <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
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 <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'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
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 7, 2024 at 5:27=E2=80=
=AFAM void <<a href=3D"mailto:void@f-m.fm" target=3D"_blank">void@f-m.fm=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Hi,<br>
<br>
Does /var/mail still need atime?<br>
<br>
I've installed a ufs2-based -current main-n267425-aa1223ac3afc on<br>
rpi4/8BG which installs into one / . If it's mounted with noatime,<br>
will it have consequences for /var/mail ?</blockquote><div><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:monospace,monospace">It doesn&#=
39;t matter if you don't normally receive emails locally (nowadays, it&=
#39;s rare).</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace">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.</div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">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.</div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">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.</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace">Cheers,</div=
></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <yaneurabeya@gmail.com>
In-Reply-To: <ZZq1TUMhpVx3HPK0@int21h>
Date: Mon, 8 Jan 2024 13:07:30 -0800
Cc: freebsd-current@freebsd.org
Message-Id: <5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com>
References: <ZZq1TUMhpVx3HPK0@int21h>
To: void <void@f-m.fm>
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 <void@f-m.fm> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
In-Reply-To: <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 8 Jan 2024 14:12:06 -0700
Message-ID: <CANCZdfpf0k4od+1_cNDiKR=HPwMZ0GsWhH9O6yRi=F72BwJRDg@mail.gmail.com>
Subject: Re: noatime on ufs2
To: Xin LI <delphij@gmail.com>
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 <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'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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 8, 2024 at 1:41=E2=80=AFP=
M Xin LI <<a href=3D"mailto:delphij@gmail.com">delphij@gmail.com</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><div style=3D"font-family:monospace,monospace"><b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void <<a href=3D"mailto:v=
oid@f-m.fm" target=3D"_blank">void@f-m.fm</a>> wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Does /var/mail still need atime?<br>
<br>
I've installed a ufs2-based -current main-n267425-aa1223ac3afc on<br>
rpi4/8BG which installs into one / . If it's mounted with noatime,<br>
will it have consequences for /var/mail ?</blockquote><div><br></div><div s=
tyle=3D"font-family:monospace,monospace">It doesn't matter if you don&#=
39;t normally receive emails locally (nowadays, it's rare).</div><div s=
tyle=3D"font-family:monospace,monospace"><br></div><div style=3D"font-famil=
y:monospace,monospace">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.</div><div style=3D"font-family:monospace,monospace=
"><br></div><div style=3D"font-family:monospace,monospace">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.</div><div style=3D"font-family:monospace,monospace"><br></=
div><div style=3D"font-family:monospace,monospace">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.</div></div></div></blockquote><div><br=
></div><div>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</div><div><br></div><div>Warner</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div style=3D"font-family:monospace,monospac=
e">Cheers,</div></div></div>
</blockquote></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <junchoon@dec.sakura.ne.jp>
To: Warner Losh <imp@bsdimp.com>
Cc: Xin LI <delphij@gmail.com>, freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
Message-Id: <20240109072129.3e6411b51a2f32945f41decd@dec.sakura.ne.jp>
In-Reply-To: <CANCZdfpf0k4od+1_cNDiKR=HPwMZ0GsWhH9O6yRi=F72BwJRDg@mail.gmail.com>
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<CANCZdfpf0k4od+1_cNDiKR=HPwMZ0GsWhH9O6yRi=F72BwJRDg@mail.gmail.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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <imp@bsdimp.com> wrote:
> On Mon, Jan 8, 2024 at 1:41 PM Xin LI <delphij@gmail.com> wrote:
>
> >
> >
> > On Sun, Jan 7, 2024 at 5:27 AM 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'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 <junchoon@dec.sakura.ne.jp>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:gLKcZVJatlmwWQimGLt2KuaZRb872C56RHhJenVYdaOEZUTRfE43OA>
<xme:gLKcZRI9WK8On5eJRhc3JqBig2fvv70dWWeOITV6CYiz9oP34wqD0uDprmB_yeli5
Hqw_rt8DAWBDI86wgk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehkedggeelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd
erreerreejnecuhfhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhmnecu
ggftrfgrthhtvghrnheptddvhedvkeejieefveffgedukedtleehffevgfekvdehkeetie
dtgeelkeeftdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
rhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomh
X-ME-Proxy: <xmx:gLKcZduEaM_pxjPfpP9meLgIcM8z859kW9AjFtSi3Q8fMzbxzTSWdQ>
<xmx:gLKcZWa_pN93cpPkDl8Mn-Vsnwqbtew6pHqaL8_pGme-Se91hSS5EA>
<xmx:gLKcZcbmZl92Xz7SPIEbSXnLQ-K11COf2rDOKdYjxzPNVPH7DS3k4A>
<xmx:gLKcZVn9xFpDNILDsKHpIk8HpeUXSkpHpuTVrAsJI_paUBE5pqcYQQ>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Message-Id: <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com>
In-Reply-To:
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
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 <void@f-m.fm> 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
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Mon, Jan 8, =
2024, at 14:41, Xin LI wrote:<br></div><blockquote type=3D"cite" id=3D"q=
t" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"qt-gmail_d=
efault" style=3D"font-family:monospace, monospace;"><br></div></div><div=
><br></div><div class=3D"qt-gmail_quote"><div dir=3D"ltr" class=3D"qt-gm=
ail_attr">On Sun, Jan 7, 2024 at 5:27=E2=80=AFAM void <<a href=3D"mai=
lto:void@f-m.fm" target=3D"_blank">void@f-m.fm</a>> wrote:<br></div><=
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,<br></div><div> <br></div><div> Does /var/mail still need atime?<=
br></div><div> <br></div><div> I've installed a ufs2-based -current main=
-n267425-aa1223ac3afc on<br></div><div> rpi4/8BG which installs into one=
/ . If it's mounted with noatime,<br></div><div> will it have consequen=
ces for /var/mail ?<br></div></blockquote><div><br></div><div class=3D"q=
t-gmail_default" style=3D"font-family:monospace, monospace;">It doesn't =
matter if you don't normally receive emails locally (nowadays, it's rare=
).<br></div><div class=3D"qt-gmail_default" style=3D"font-family:monospa=
ce, monospace;"><br></div><div class=3D"qt-gmail_default" style=3D"font-=
family:monospace, monospace;">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.<br></div><div class=3D"qt=
-gmail_default" style=3D"font-family:monospace, monospace;"><br></div><d=
iv class=3D"qt-gmail_default" style=3D"font-family:monospace, monospace;=
">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.<br></div><div class=3D"qt-gmail_default" sty=
le=3D"font-family:monospace, monospace;"><br></div><div class=3D"qt-gmai=
l_default" style=3D"font-family:monospace, monospace;">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.<br></div><div class=3D"qt-g=
mail_default" style=3D"font-family:monospace, monospace;"><br></div><div=
class=3D"qt-gmail_default" style=3D"font-family:monospace, monospace;">=
Cheers,<br></div></div></div></blockquote><div dir=3D"ltr"><div class=3D=
"qt-gmail_quote"><div class=3D"qt-gmail_default" style=3D"font-family:mo=
nospace, monospace;"><br></div><div class=3D"qt-gmail_default" style=3D"=
font-family:monospace, monospace;">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.<br></div></div><div><br></div><div>Why not make noatime the defau=
lt across the whole system? Outside of mbox why is recording access time=
actually useful?<br></div></div><div><br></div></body></html>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Tue, 9 Jan 2024 08:48:08 +0000 (UTC)
(envelope-from olce@freebsd.org)
From: Olivier Certner <olce@freebsd.org>
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:
<ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
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 <current@mlmmj.nyi.freebsd.org>; 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 <current@FreeBSD.org>; 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 <current@FreeBSD.org>; 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 <current@FreeBSD.org>; 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: <bug-197921-2597-fPjwO6fMa5@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-197921-2597@https.bugs.freebsd.org/bugzilla/>
References: <bug-197921-2597@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197921
Zhenlei Huang <zlei@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zlei@FreeBSD.org
--- Comment #3 from Zhenlei Huang <zlei@FreeBSD.org> ---
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:9x6dZQaSDfk1weofaJmt6yLSkVDLxvMgM-vU_0kODy46HSG0RHA7ng>
<xme:9x6dZbasdlVfCNOXaMQrdKsSN1Muxs5kEiNZI2VsK98YUPeY1F3bpuz9uRkg-a3B-
kR88KJTChnoAAgUkA>
X-ME-Received: <xmr:9x6dZa9l2wWJulA9ePYGMJ-hall6A5RBXFfyPk1M2CezMAemfUwv775CXqI1bGRGGpg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgudegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke
ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr
rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute
eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
pehvohhiugesfhdqmhdrfhhm
X-ME-Proxy: <xmx:9x6dZarx_F9ya8ykCD3Ilk46OoK-tCVI4ffXmu2LS0Wxrf0tAT_gSA>
<xmx:9x6dZbplzZDMKGm6gQ7g4Cxxno6vEoa2apeNClZvCwrvRW35ZDGWxQ>
<xmx:9x6dZYQIOMUZcrcbWng50s8Km0vTpoVAHETJZluct02yoklzLljxDg>
<xmx:9x6dZVGAoym-jaLPeNtJr7d8bfAamH127IEWseRT5iq6_SNGY5Sb0Q>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Tue, 9 Jan 2024 05:24:55 -0500 (EST)
Date: Tue, 9 Jan 2024 10:24:53 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: Re: route ipv6 errors on bootup in -current
main-n267425-aa1223ac3afc on arm64
Message-ID: <ZZ0e9ZJxVParDgpS@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
References: <ZZq1TUMhpVx3HPK0@int21h>
<5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:KySdZRWzbbOaKpg7zZPEep3QIGs2M4POMTFbtuFfcW95mWGEW1jkrg>
<xme:KySdZRk67ImPdfzPGi5KO8k863Ejnnv0WJyPqCGEeOcAT-EADB5EerPbSYBC34Sol
4N-zcXG3A5LfQRnqg>
X-ME-Received: <xmr:KySdZdaKMyqIZ5GT_aymDtfI7_MQwr9YrByrsZgCjo62FmR2uEtFUi51tZWCMoXw5vk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgudelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke
ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr
rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute
eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
pehvohhiugesfhdqmhdrfhhm
X-ME-Proxy: <xmx:KySdZUXN2RzaNDqxJJN5uLgDkAgFVnSM421KdSlXuUUCXmODpLKJSQ>
<xmx:KySdZbkoCEWPZzvbI7cyT8pJlYqQL4kWSCEbBduv_yaZy8XpQ1N9pw>
<xmx:KySdZRcpgjKdwy8AgsRwyghlyVHW9jWrt3Gnghy9YEk1PrmnXfP8kw>
<xmx:KySdZRQ36tvs1fA21VJuYsavsBVd4NAB0pVbMTYSkBGGHbrTd04Idw>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Tue, 9 Jan 2024 05:47:07 -0500 (EST)
Date: Tue, 9 Jan 2024 10:47:05 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
Message-ID: <ZZ0kKaeE4OiCOXXx@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.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.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 <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'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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:aiqdZU7z2Ws-WTrIV52m8jyDDFccn5EOWAnVcjQsi7fXpe-1X9wfhw>
<xme:aiqdZV7IQvQljxzBzJQfVa6oTfUWPS3XzzskzwdrkCRwpc0a2k4vMXscNm9dAqyCT
BFM8li70CAsUSs3iw>
X-ME-Received: <xmr:aiqdZTccfDJcxeDErt5C8vgwxmleDqkxg9F3oiqOtTRiq2_48yP06ZLO84tOwzhBZkM>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgvdegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe
ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: <xmx:aiqdZZLZyPm90y1QXbvoCC7pSoW3j13xm-YlpaOHFNF8ubtorKO7Jg>
<xmx:aiqdZYKT2Th7GC8SP5OxNeqha8gQlCA12-_bhUL1vITzRVHkGlUqNg>
<xmx:aiqdZaw26ec4_JCJPCPT4hsr7_AZB7xkSipLA8bRcoWLQDT-0jljMA>
<xmx:aiqdZfloaL7OAv7K-N4Bl8-XnYQ2iYqQBfVbVUV4_tGjSa7prtaVWQ>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Tue, 9 Jan 2024 06:13:45 -0500 (EST)
Date: Tue, 9 Jan 2024 11:13:44 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
Message-ID: <ZZ0qaGK0UErpdyw3@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com>
<6714298.qJWK8QVVMX@ravel>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:ITmdZdRqAehibTqB_zEB7edHOeTqQ9bxaWuV3NC33B7251Z_I4SUzA>
<xme:ITmdZWwQ-6nLm80DmaKpuWE3K5u9Ocd_8xHQuMSUcKnemChTzf-BsNY7GDtnhHShd
RsCkfT9sjBYZhE7GyE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgfeeiucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd
ertderredtnecuhfhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhmnecu
ggftrfgrthhtvghrnhepkefhffevveeugfetteegueegledviedvffevvddtieehvdekke
elvefhhfevgedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
rhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomh
X-ME-Proxy: <xmx:ITmdZS1el7PfT4n_HKZQ0oANGYi1CA4srSu8CzbLqGewCy2CpXz2GQ>
<xmx:ITmdZVDzbpLc2fp3mwOYD9kBQpRti1Y_dFhjC_tRiRlZGKGjEVl98Q>
<xmx:ITmdZWg92_GHPnYYYGZeOaco_YR5LQHSHws1waFwn2m2QNjMyG4fug>
<xmx:ITmdZRvcfHI9T20ykduskw2e40LSbAN4Q7cWXAJmg6rbDBQE5C665Q>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Message-Id: <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>
In-Reply-To: <ZZ0qaGK0UErpdyw3@int21h>
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com>
<6714298.qJWK8QVVMX@ravel> <ZZ0qaGK0UErpdyw3@int21h>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:7DqdZURg5bstTFHODqMzPPbuIXk9A9MRHgW0YmqZwgXC3w0kSM4q_w>
<xme:7DqdZRwxzROfGjqKMieJOZIDhpcprYRJvd0dpRWkJ_GyisRx9Ze4AwTvgL-7H5xhw
jiaMIt8E0jVCXJhYgE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgfeelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth
hqredtreerjeenucfhrhhomheprhhosggvrhhtsehrrhgsrhhushhsvghllhdrtghomhen
ucggtffrrghtthgvrhhnpedtvdefieduffeiheeiieegieejleetveevhfevtdfhkeeike
efffeigfffteetteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl
fhhrohhmpehrohgsvghrthesrhhrsghruhhsshgvlhhlrdgtohhm
X-ME-Proxy: <xmx:7DqdZR1prU02HFdmQW54DckUDLG9x7ALiYqHfBV2O3C7MlW4d2LVjA>
<xmx:7DqdZYA75TB86DSRIuK6jfOZpmottQMLktJZOr0euBIigDVykHrsWQ>
<xmx:7DqdZdgZU9vnnch4YKIxhqze8LDFrmSXvX_F4elwoHAxt9pZCdx64g>
<xmx:7DqdZYsPgGGn14vbVObjf661URx8bqxt7W3exRRap-kQuf0ljmeGWA>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Message-Id: <1173b407-cb6f-4e21-af87-4f1755bfb292@app.fastmail.com>
In-Reply-To: <ZZ0kKaeE4OiCOXXx@int21h>
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<ZZ0kKaeE4OiCOXXx@int21h>
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 <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'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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:CjudZdIkkuWG8k304z8BRzT3Ljr8IX3X_mTVAbygjPZYGIEDaOHeSA>
<xme:CjudZZJ13GFcyzJ6yKjfwhpPWLb2EjeXdO8zKiLHJq-hG1QkliOpn-UHwJpSqHDhr
9qA4nQjwvmK49zBkg>
X-ME-Received: <xmr:CjudZVuTd7JNRRm9rsCZNsKqiJmUHZadrwWTntopkpojQIL8J7GyxwE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgfeelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke
ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr
rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute
eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
pehvohhiugesfhdqmhdrfhhm
X-ME-Proxy: <xmx:CjudZebrFHLa2sQB-IEoD0WBcyC8YfOVR_CfVrNHBVd2TWQMUFCP4g>
<xmx:CjudZUbZJIecf1AE0PK0p7mCX1hibbHBhqSt8jErKe-KB954cvUPdQ>
<xmx:CjudZSADVCfmXUbttnqAefQl53baNWIP66HNtTRRpYDEetskvJyPbw>
<xmx:CjudZa0IT6a4igcFpNuDq1rXkHFqk3v0y4dXS-TTX9RiiyUIDfYaKQ>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Tue, 9 Jan 2024 07:24:41 -0500 (EST)
Date: Tue, 9 Jan 2024 12:24:40 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: Re: route ipv6 errors on bootup in -current
main-n267425-aa1223ac3afc on arm64
Message-ID: <ZZ07CC6uwSRF5PuQ@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
References: <ZZq1TUMhpVx3HPK0@int21h>
<5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com>
<ZZ0e9ZJxVParDgpS@int21h>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZZ0e9ZJxVParDgpS@int21h>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:l2OdZf8HgcL7aRtCGKVDsHimyxH0e8SAt5sV__lqhRnRekktMPQc1A>
<xme:l2OdZbudKYdca8-XIwq9b83iWvKkTkDgt-E26Q4ia0gXbekSEuuFa8KE2TIwqwsu2
YpDeKnQcv9_Q_eCiA>
X-ME-Received: <xmr:l2OdZdCCMnqpGa6VopDcG61vEvuo701puK_AC1pjpzVLEUEogUO2OyE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledgjedvucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke
ertddttdejnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr
rghtthgvrhhnpeduteevgeeggeevieetvdduudetfffffffhteejgffggeevjeffiedute
eftedvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
pehvohhiugesfhdqmhdrfhhm
X-ME-Proxy: <xmx:l2OdZbf-q6WCPzUtr1qRk1a6PpD5SbWJJoTFC3BteLIWUDrsaFEg4w>
<xmx:l2OdZUOiC9BSIDsyBYWjyk9F9CdKmwUV0bgiSuUxCDAv4dBbE-Cu8A>
<xmx:l2OdZdnkZjno4xvZxfeIxsZQ65vpcn03HIqCVo4rRlSx4gaLeW3J6g>
<xmx:mGOdZfasH6bu1-1k0p0bXqjuBQPzU1YYMk7z3NWnTEGJmcuJUHpgTg>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Tue, 9 Jan 2024 10:17:43 -0500 (EST)
Date: Tue, 9 Jan 2024 15:17:41 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: Re: route ipv6 errors on bootup in -current
main-n267425-aa1223ac3afc on arm64
Message-ID: <ZZ1jlSY6XEQcRUPv@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
References: <ZZq1TUMhpVx3HPK0@int21h>
<5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com>
<ZZ0e9ZJxVParDgpS@int21h>
<ZZ07CC6uwSRF5PuQ@int21h>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZZ07CC6uwSRF5PuQ@int21h>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<ZZ0kKaeE4OiCOXXx@int21h>
In-Reply-To: <ZZ0kKaeE4OiCOXXx@int21h>
From: Xin LI <delphij@gmail.com>
Date: Tue, 9 Jan 2024 09:02:50 -0800
Message-ID: <CAGMYy3v858oXGtPSNA4WHgei=m6U5phT-3p1UuyPea46jfw=0Q@mail.gmail.com>
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 <void@f-m.fm> 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
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 9, 2024 at 2:47=E2=80=
=AFAM void <<a href=3D"mailto:void@f-m.fm">void@f-m.fm</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">I was concerned th=
at email might not work right without atime.<br>
So far, it seems to be working OK.<br>
</blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:monospace,monospace">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).</div><div class=3D"gmail_default" style=3D"font-family:monospace,m=
onospace"><br></div><div class=3D"gmail_default" style=3D"font-family:monos=
pace,monospace">Cheers,</div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
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: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com>
<6714298.qJWK8QVVMX@ravel> <ZZ0qaGK0UErpdyw3@int21h>
<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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <wnj@ucbvax.Berkeley.EDU>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <rhurlin@gwdg.de>)
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Rainer Hurling <rhurlin@gwdg.de>
Subject: kernel: fatal trap 12 on CURRENT, when using WireGuard
Reply-To: Rainer Hurling <rhurlin@FreeBSD.org>
To: <freebsd-current@freebsd.org>
Content-Language: en-US
CC: Gleb Smirnoff <glebius@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <glebius@freebsd.org>
To: Rainer Hurling <rhurlin@freebsd.org>
Cc: freebsd-current@freebsd.org
Subject: Re: kernel: fatal trap 12 on CURRENT, when using WireGuard
Message-ID: <ZZ2vW8_HsUt8Ybhm@FreeBSD.org>
References: <423b62fc-6687-4e56-b8e7-ecaebcadfd7f@gwdg.de>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel>
<ZZ0qaGK0UErpdyw3@int21h> <5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>
<20240109174318.MCIB6yhn@steffen%sdaoden.eu>
In-Reply-To: <20240109174318.MCIB6yhn@steffen%sdaoden.eu>
From: Warner Losh <imp@bsdimp.com>
Date: Tue, 9 Jan 2024 14:08:03 -0700
Message-ID: <CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com>
Subject: Re: noatime on ufs2
To: robert@rrbrussell.com, FreeBSD Current <freebsd-current@freebsd.org>
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 <steffen@sdaoden.eu>=
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 <wnj@ucbvax.Berkeley.EDU>
> 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
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue, Jan 9, 2024, 11:11=E2=80=AFAM Steffen Nurpmeso=
<<a href=3D"mailto:steffen@sdaoden.eu">steffen@sdaoden.eu</a>> wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:robert@rrbrusse=
ll.com" target=3D"_blank" rel=3D"noreferrer">robert@rrbrussell.com</a> wrot=
e in<br>
=C2=A0<<a href=3D"mailto:5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastma=
il.com" target=3D"_blank" rel=3D"noreferrer">5f370bce-bcdb-47ea-aaa7-551ee0=
92a7d3@app.fastmail.com</a>>:<br>
=C2=A0|On Tue, Jan 9, 2024, at 05:13, void wrote:<br>
=C2=A0|> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote=
:i<br>
=C2=A0|>> So, to me, at this point, it still sounds more than a gimmi=
ck <br>
=C2=A0|>> than something really useful.=C2=A0 If someone has a precis=
e use case <br>
<br>
Email existence checks are in UNIX for many decades.<br>
In fact since 1974-11-26 when Ken Thompson added that to login(1).<br>
"You have new mail" is in BSD since<br>
<br>
=C2=A0 Commit:=C2=A0 =C2=A0 =C2=A0Bill Joy <<a href=3D"mailto:wnj@ucbvax=
.Berkeley.EDU" target=3D"_blank" rel=3D"noreferrer">wnj@ucbvax.Berkeley.EDU=
</a>><br>
=C2=A0 CommitDate: 1978-11-05 19:59:54 -0800<br></blockquote></div></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">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...</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 Start development on BSD 3<br>
=C2=A0 =C2=A0 Create reference copy of all prior development files<br>
<br>
in BSD Mail and csh(1).<br>
And today in bash(1), for example, there can be read<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* If the user has just run a program which man=
ipulates the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mail file, then don't bother e=
xplaining that the mail<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0file has been manipulated.=C2=A0 S=
ince some systems don't change<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the access time to be equal to the=
modification time when<br>
=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<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the file has not grown, continue. =
*/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((atime >=3D mtime) && !file_is_b=
igger)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* If the mod time is later than the access tim=
e and the file<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has grown, note the fact that this=
is *new* mail. */<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (use_user_notification =3D=3D 0 && (=
atime < mtime) && file_is_bigger)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message =3D _("You have new mail in=
$_");<br>
<br>
I would not exactly call this a gimmick.<br>
On Linux mount(8) from <a href=3D"https://github.com/karelzak/util-linux" r=
el=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/karelzak/=
util-linux</a> says<br>
<br>
=C2=A0 =C2=A0relatime<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Update inode access times relative to modify or =
change time. Access<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0time is only updated if the previous access time=
was earlier than<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0or equal to the current modify or change time. (=
Similar to noatime,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0but it doesn=E2=80=99t break mutt(1) or other ap=
plications that need to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0know if a file has been read since the last time=
it was modified.)<br>
<br>
and this is what i use, except for some noatime mount points<br>
(/x/doc, /x/music, /x/pub, to be exact).<br>
<br>
--steffen<br>
|<br>
|Der Kragenbaer,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The=
moon bear,<br>
|der holt sich munter=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0he cheerfully=
and one by one<br>
|einen nach dem anderen runter=C2=A0 wa.ks himself off<br>
|(By Robert Gernhardt)<br>
<br>
</blockquote></div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <glebius@freebsd.org>
To: Jakob Alvermark <jakob@alvermark.net>
Cc: freebsd-current@freebsd.org
Subject: Re: e179d973 insta-panics in nl_send_one()
Message-ID: <ZZ22I8GiEFHOU7rC@FreeBSD.org>
References: <202401062231.406MVrxT002354@critter.freebsd.dk>
<202401062234.406MYJ6E004159@critter.freebsd.dk>
<ae34b3e9-1d26-48e0-8f18-7ba188d771d9@alvermark.net>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ae34b3e9-1d26-48e0-8f18-7ba188d771d9@alvermark.net>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <rhurlin@gwdg.de>)
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: <c10036d7-2307-47f6-b51b-ebde7b5dad62@gwdg.de>
Date: Tue, 9 Jan 2024 22:25:16 +0100
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <glebius@freebsd.org>
CC: <freebsd-current@freebsd.org>
References: <423b62fc-6687-4e56-b8e7-ecaebcadfd7f@gwdg.de>
<ZZ2vW8_HsUt8Ybhm@FreeBSD.org>
Content-Language: en-US
Reply-To: Rainer Hurling <rhurlin@freebsd.org>
From: Rainer Hurling <rhurlin@gwdg.de>
In-Reply-To: <ZZ2vW8_HsUt8Ybhm@FreeBSD.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Steffen Nurpmeso <steffen@sdaoden.eu>
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:
<ZZqmmM-6f606bLJx@int21h>
<5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>
<20240109174318.MCIB6yhn@steffen%sdaoden.eu>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Steffen Nurpmeso <steffen@sdaoden.eu>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
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:
<CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com>
References:
<ZZqmmM-6f606bLJx@int21h> <20240109174318.MCIB6yhn@steffen%sdaoden.eu>
<CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <jakob@alvermark.net>)
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 <jakob@alvermark.net>)
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <glebius@freebsd.org>
Cc: freebsd-current@freebsd.org
References: <202401062231.406MVrxT002354@critter.freebsd.dk>
<202401062234.406MYJ6E004159@critter.freebsd.dk>
<ae34b3e9-1d26-48e0-8f18-7ba188d771d9@alvermark.net>
<ZZ22I8GiEFHOU7rC@FreeBSD.org>
Content-Language: en-US
From: Jakob Alvermark <jakob@alvermark.net>
In-Reply-To: <ZZ22I8GiEFHOU7rC@FreeBSD.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <ronald-lists@klop.ws>
To: Olivier Certner <olce@freebsd.org>
Cc: freebsd-current@freebsd.org, Warner Losh <imp@bsdimp.com>
Message-ID: <1115024984.4580.1704889653735@localhost>
In-Reply-To: <1749331.ETpRK2a2Mi@ravel>
References: <ZZqmmM-6f606bLJx@int21h>
<20240109174318.MCIB6yhn@steffen%sdaoden.eu>
<CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com>
<1749331.ETpRK2a2Mi@ravel>
Subject: Re: noatime on ufs2
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <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
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html><head></head><body><br>
<p><strong>Van:</strong> Olivier Certner <olce@freebsd.org><br>
<strong>Datum:</strong> woensdag, 10 januari 2024 11:01<br>
<strong>Aan:</strong> Warner Losh <imp@bsdimp.com><br>
<strong>CC:</strong> freebsd-current@freebsd.org<br>
<strong>Onderwerp:</strong> Re: noatime on ufs2</p>
<blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px">
<div class="MessageRFC822Viewer" id="P">
<div class="MultipartMixedViewer">
<div class="TextPlainViewer" id="P.P.P1">Hi Warner,<br>
<br>
> It has also been used for almost as long to see if log files have changed<br>
> if you set your MAIL variable to that. So not just for email...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards.<br>
<br>
-- <br>
Olivier Certner</div>
<hr>
<div class="DefaultViewer"> </div>
</div>
</div>
</blockquote>
<br>
<br>
"And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same."<br>
<br>
This is an interesting type of argument.<br>
<br>
Ronald.<br>
</body></html>
------=_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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Ronald Klop <ronald-lists@klop.ws>
Cc: freebsd-current@freebsd.org, Warner Losh <imp@bsdimp.com>
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:
<ZZqmmM-6f606bLJx@int21h> <1749331.ETpRK2a2Mi@ravel>
<1115024984.4580.1704889653735@localhost>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Ronald Klop <ronald-lists@klop.ws>
Cc: freebsd-current@freebsd.org, Warner Losh <imp@bsdimp.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <naddy@mips.inka.de>
To: freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
Message-ID: <ZZ6si32-0mMWo7iD@lorvorc.mips.inka.de>
References: <ZZqmmM-6f606bLJx@int21h>
<CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com>
<6714298.qJWK8QVVMX@ravel>
<ZZ0qaGK0UErpdyw3@int21h>
<5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>
<20240109174318.MCIB6yhn@steffen%sdaoden.eu>
<CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <20240109174318.MCIB6yhn@steffen%sdaoden.eu>
<CANCZdfoB-XqvwRrkqUiNEmqLpFbAUSZiuJzM+G1fdeiU2KQFiQ@mail.gmail.com> <1749331.ETpRK2a2Mi@ravel>
In-Reply-To: <1749331.ETpRK2a2Mi@ravel>
From: Warner Losh <imp@bsdimp.com>
Date: Wed, 10 Jan 2024 09:55:40 -0700
Message-ID: <CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com>
Subject: Re: noatime on ufs2
To: Olivier Certner <olce@freebsd.org>
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 <olce@freebsd.org> =
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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 10, 2024 at 3:01=E2=80=AF=
AM Olivier Certner <<a href=3D"mailto:olce@freebsd.org">olce@freebsd.org=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Hi Warner,<br>
<br>
> It has also been used for almost as long to see if log files have chan=
ged<br>
> if you set your MAIL variable to that. So not just for email...<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>I=
'm not sure this is a great notion to have everywhere. I think your ana=
lysis needs more inputs.</div><div><br></div><div>Warner</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards.<br>
<br>
-- <br>
Olivier Certner</blockquote></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
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:
<CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com>
References:
<ZZqmmM-6f606bLJx@int21h> <1749331.ETpRK2a2Mi@ravel>
<CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Olivier Certner <olce@freebsd.org>
Cc: freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
Message-ID: <20240110191215.fTrYqOW3@steffen%sdaoden.eu>
In-Reply-To: <2367131.USjQqFH40Q@ravel>
References: <ZZqmmM-6f606bLJx@int21h>
<5f370bce-bcdb-47ea-aaa7-551ee092a7d3@app.fastmail.com>
<20240109174318.MCIB6yhn@steffen%sdaoden.eu> <2367131.USjQqFH40Q@ravel>
Mail-Followup-To: Olivier Certner <olce@freebsd.org>,
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <1749331.ETpRK2a2Mi@ravel>
<CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com> <2136329.mxFCRLsXLg@ravel>
In-Reply-To: <2136329.mxFCRLsXLg@ravel>
From: Tomek CEDRO <tomek@cedro.info>
Date: Wed, 10 Jan 2024 21:34:57 +0100
X-Gmail-Original-Message-ID: <CAFYkXj=xdDW38ehGqu6J=pwfmR0XTr=rOpPChEWNuFbidfDVUg@mail.gmail.com>
Message-ID: <CAFYkXj=xdDW38ehGqu6J=pwfmR0XTr=rOpPChEWNuFbidfDVUg@mail.gmail.com>
Subject: Re: noatime on ufs2
To: freebsd-current@freebsd.org
Cc: Warner Losh <imp@bsdimp.com>, Olivier Certner <olce@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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)" <lyndon@orthanc.ca>
To: Olivier Certner <olce@freebsd.org>
cc: freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
In-reply-to: <6714298.qJWK8QVVMX@ravel>
References: <ZZqmmM-6f606bLJx@int21h> <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com> <2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel>
Comments: In-reply-to Olivier Certner <olce@freebsd.org>
message dated "Tue, 09 Jan 2024 09:47:59 +0100."
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <a5e38bfbabd37084@orthanc.ca>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <yaneurabeya@gmail.com>
Message-Id: <ACDAB630-9CD8-408F-BA56-98431CF8AE39@gmail.com>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZZ1jlSY6XEQcRUPv@int21h>
Cc: freebsd-current@freebsd.org
To: void <void@f-m.fm>
References: <ZZq1TUMhpVx3HPK0@int21h>
<5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com> <ZZ0e9ZJxVParDgpS@int21h>
<ZZ07CC6uwSRF5PuQ@int21h> <ZZ1jlSY6XEQcRUPv@int21h>
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 <void@f-m.fm> 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
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Jan 9, 2024, at 7:17 AM, void <<a href=3D"mailto:void@f-m.fm" =
class=3D"">void@f-m.fm</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
charset=3D"UTF-8" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">On Tue, Jan 09, 2024 at 12:24:40PM +0000, void =
wrote:</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: 400; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: 400; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">On =
Tue, Jan 09, 2024 at 10:24:53AM +0000, void wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">On Mon, Jan 08, 2024 at =
01:07:30PM -0800, Enji Cooper wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D""><br class=3D"">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<br class=3D"">Cheers!<br class=3D"">-Enji<br =
class=3D""></blockquote><br class=3D"">world/kernel was built with =
WITHOUT_INET6=3D in /etc/src.conf<br class=3D""><br class=3D"">I made =
the problem go away with removing WITHOUT_INET6=3D and rebuilding.<br =
class=3D""></blockquote><br class=3D"">I'll re-add this to try and =
replicate the problem with the same sources<br =
class=3D"">(main-n267425-aa1223ac3afc) and if it happens again I'll make =
a PR for it<br class=3D""></blockquote><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">I forgot about this line:</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: 400; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">options INET6 =
&n=
bsp; # IPv6 communications =
protocols</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: 400; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: 400; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: 400; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">which, on =
current/arm64 lives in std.arm64 which gets included by</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">GENERIC which is included by =
GENERIC-MMCCAM which is included by</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: 400; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">GENERIC-MMCCAM-NODEBUG</span><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">commenting it out and having WITHOUT_INET6=3D in =
/etc/src.conf and rebuilding</span><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">fixes the problem. Sorry for the noise.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""></div></blockquote><br class=3D""></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>It=E2=80=99=
s not noise; what you found is a valid issue.</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>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).</div><div>Thank you!</div><div>-Enji</div></body></html>=
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <CAGMYy3vsSD7HHtGxYXJn+usr8GCOd-0Xe1crs-Nx=qw-bYJ6HA@mail.gmail.com>
<2eabfb91-afc3-47f7-98b9-1a1791ae6e7d@app.fastmail.com> <6714298.qJWK8QVVMX@ravel>
<a5e38bfbabd37084@orthanc.ca>
In-Reply-To: <a5e38bfbabd37084@orthanc.ca>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Wed, 10 Jan 2024 13:28:16 -0800
Message-ID: <CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com>
Subject: Re: noatime on ufs2
To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
Cc: Olivier Certner <olce@freebsd.org>, 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)
<lyndon@orthanc.ca> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <marklmi@yahoo.com>
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 <marklmi@yahoo.com>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
Date: Wed, 10 Jan 2024 13:49:36 -0800
To: olce@freebsd.org,
Current FreeBSD <freebsd-current@freebsd.org>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
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 <olce_at_freebsd.org> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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" <freebsd-rwg@gndrsh.dnsmgr.net>
Message-Id: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net>
Subject: Re: noatime on ufs2
In-Reply-To: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
To: Mark Millard <marklmi@yahoo.com>
Date: Wed, 10 Jan 2024 16:49:55 -0800 (PST)
CC: olce@FreeBSD.org, Current FreeBSD <freebsd-current@FreeBSD.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce_at_freebsd.org> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <warlock@phouka.net>
To: Alexander Motin <mav@freebsd.org>
Cc: Kurt Jaeger <pi@freebsd.org>, freebsd-current@freebsd.org,
Alexander Leidinger <Alexander@leidinger.net>
Subject: Re: ZFS problems since recently ?
Message-ID: <ZZ87m4Qosa_77Tjx@phouka1.phouka.net>
References: <ZZG0RdFTqfbfPwf7@fc.opsec.eu>
<ZZH2YIXm75emBbpp@phouka1.phouka.net>
<ZZIPYzWKZ1R_pMHQ@phouka1.phouka.net>
<ZZJRHnA6Kgs3TdCF@fc.opsec.eu>
<ZZLFQa1qZ0as01AU@phouka1.phouka.net>
<ea6cb256-3000-3822-1734-258f84635c46@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ea6cb256-3000-3822-1734-258f84635c46@FreeBSD.org>
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 <mm@FreeBSD.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com> <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net>
In-Reply-To: <202401110049.40B0ntj0046904@gndrsh.dnsmgr.net>
From: Tomek CEDRO <tomek@cedro.info>
Date: Thu, 11 Jan 2024 02:41:55 +0100
X-Gmail-Original-Message-ID: <CAFYkXjmAZF-UXS+8Acgb91JLo+5wtAp_NxtcxaHGMfPymn_+pg@mail.gmail.com>
Message-ID: <CAFYkXjmAZF-UXS+8Acgb91JLo+5wtAp_NxtcxaHGMfPymn_+pg@mail.gmail.com>
Subject: Re: noatime on ufs2
To: Current FreeBSD <freebsd-current@freebsd.org>
Cc: Mark Millard <marklmi@yahoo.com>, olce@freebsd.org,
"Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Thu, 11 Jan 2024 02:21:19 +0000 (GMT)
Date: Thu, 11 Jan 2024 02:21:19 +0000
From: Lexi Winter <lexi@le-fay.org>
To: freebsd-current@freebsd.org
Subject: poudriere: swap_pager: out of swap space
Message-ID: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <zlei@FreeBSD.org>
In-Reply-To: <ZZ0e9ZJxVParDgpS@int21h>
Date: Wed, 10 Jan 2024 15:34:49 +0800
Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <32B3A657-8658-4694-90B9-F3FE56EF5225@FreeBSD.org>
References: <ZZq1TUMhpVx3HPK0@int21h>
<5EAEA6CD-8C5A-47BD-B332-73C069928F1C@gmail.com> <ZZ0e9ZJxVParDgpS@int21h>
To: void <void@f-m.fm>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
> On Jan 9, 2024, at 6:24 PM, void <void@f-m.fm> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <Alexander@Leidinger.net>
To: Mark Millard <marklmi@yahoo.com>
Cc: olce@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
In-Reply-To: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
Message-ID: <ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <junchoon@dec.sakura.ne.jp>
To: Alexander Leidinger <Alexander@Leidinger.net>
Cc: Mark Millard <marklmi@yahoo.com>, olce@freebsd.org,
Current FreeBSD
<freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
Message-Id: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp>
In-Reply-To: <ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
<ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <Alexander@Leidinger.net> 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 <junchoon@dec.sakura.ne.jp>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <junchoon@dec.sakura.ne.jp>
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: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
References: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <lexi@le-fay.org> 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 <junchoon@dec.sakura.ne.jp>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <lexi@le-fay.org>, freebsd-current@freebsd.org
References: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
Content-Language: en-US
From: Ronald Klop <ronald@FreeBSD.org>
In-Reply-To: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:aN6fZVZCzKTcKvuXkyBvYIqg7DNntFv6b6xumdi0qOaByrUm_yUhPw>
<xme:aN6fZcaez7GGOhAW-qMd-SBRudQneuvZfRiHOKgvHR3Bw48xo1ASH6dhVsBRAabRp
5Hr-nnOIBPUu4m-PQ>
X-ME-Received: <xmr:aN6fZX_W9Ef0QYkqy1RPg44XXhlL6S1i8zMgxDg6oM4OH7E847iBofeif8vXLJE0aUw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeifedgfeelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe
ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: <xmx:aN6fZTra7L9lsSKC8EYkiYGVsZvhg1eDjb5z6iW9ns-fZhx89TwwPw>
<xmx:aN6fZQrLpDkNhux9RDw1hsaARmO4OvErHyMP0KUVFkIrb5p_MsFQ5w>
<xmx:aN6fZZQLtPMZvY3ZbOW8q-4Nuhk3d5v-hDcjB-cQMdAXdHCkyzq-Fg>
<xmx:aN6fZWGkwjuFe5R5elIdcExvGLMqnHSvGMuOSBYpAjLfCo8ngw7oVw>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Thu, 11 Jan 2024 07:26:16 -0500 (EST)
Date: Thu, 11 Jan 2024 12:26:12 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: Re: poudriere: swap_pager: out of swap space
Message-ID: <ZZ_eZLdlrthSgm-y@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
References: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: noatime on ufs2
To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>,
Alexander Leidinger <Alexander@Leidinger.net>
Cc: Mark Millard <marklmi@yahoo.com>, olce@freebsd.org,
Current FreeBSD <freebsd-current@freebsd.org>
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
<ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
<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 <Alexander@Leidinger.net> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <mike@karels.net>); Thu, 11 Jan 2024 07:58:57 -0600
From: Mike Karels <mike@karels.net>
To: Miroslav Lachman <000.fbsd@quip.cz>
Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>,
Current FreeBSD <freebsd-current@freebsd.org>
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: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
<ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
<20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp>
<233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <Alexander@Leidinger.net> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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" <freebsd-rwg@gndrsh.dnsmgr.net>
Message-Id: <202401111715.40BHFJ3Q049600@gndrsh.dnsmgr.net>
Subject: Re: noatime on ufs2
In-Reply-To: <ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
To: Alexander Leidinger <Alexander@Leidinger.net>
Date: Thu, 11 Jan 2024 09:15:19 -0800 (PST)
CC: Mark Millard <marklmi@yahoo.com>, olce@FreeBSD.org,
Current FreeBSD <freebsd-current@FreeBSD.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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: <jamie@donotpassgo.dyslexicfish.net>
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 <jamie@catflap.org>
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: <ZZqmmM-6f606bLJx@int21h> <1749331.ETpRK2a2Mi@ravel>
<CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com>
<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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@FreeBSD.org> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com> <ffcb932b3835dc9e3ccdd480abbab6fe@Leidinger.net>
<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 <imp@bsdimp.com>
Date: Thu, 11 Jan 2024 15:01:21 -0700
Message-ID: <CANCZdfoyy6S-pxfbhnoyf=Pcv93qiNbk983CYwKxgZ9F+Y143A@mail.gmail.com>
Subject: Re: noatime on ufs2
To: Mike Karels <mike@karels.net>
Cc: Miroslav Lachman <000.fbsd@quip.cz>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp>,
Current FreeBSD <freebsd-current@freebsd.org>
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 <mike@karels.net> 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... 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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 11, 2024 at 6:59=E2=80=AF=
AM Mike Karels <<a href=3D"mailto:mike@karels.net">mike@karels.net</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11 =
Jan 2024, at 7:30, Miroslav Lachman wrote:<br>
<br>
> On 11/01/2024 09:54, Tomoaki AOKI wrote:<br>
>> On Thu, 11 Jan 2024 08:36:24 +0100<br>
>> Alexander Leidinger <Alexander@Leidinger.net> wrote:<br>
><br>
> [..]<br>
><br>
>>> There's one possibility which nobody talked about yet... c=
hanging the<br>
>>> default to noatime at install time in fstab / zfs set.<br>
>>><br>
>>> I fully agree to not violate POLA by changing the default to n=
oatime in<br>
>>> any FS. I always set noatime everywhere on systems I take care=
about, no<br>
>>> exceptions (any user visible mail is handled via maildir/IMAP,=
not<br>
>>> mbox). I haven't made up my mind if it would be a good ide=
a to change<br>
>>> bsdinstall to set noatime (after asking the user about it, and=
later<br>
>>> maybe offer=C2=A0 the possibility to use relatime in case it g=
ets<br>
>>> implemented). I think it is at least worthwile to discuss this=
<br>
>>> possibility (including what the default setting of bsdinstall =
should be<br>
>>> for this option).<br>
><br>
> [..]<br>
><br>
>> A different aspect of view.<br>
>> Nowadays, storages are quickly moving from HDD, aka spinning rust,=
to<br>
>> SSD.<br>
>> And SSD has a risk of sudden-death of wearing out. In ancient days=
, HDD<br>
>> dies not suddenly and at least some cases admins could have time t=
o<br>
>> replace suspicious drives. But SSD dies basically suddenly.<br>
>><br>
>> IMHO, this could be a valid reason to violate POLA. In limited use=
<br>
>> cases, atime is useful, at the cost of amplified write accesses.<b=
r>
>> But in most cases, it doesn't have positive functionality nowa=
days.<br>
>><br>
>> Anyway, we should have time to discuss whether it should be done o=
r not<br>
>> 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<br>
>> to introduce this, unlike discussion about vi and ee on forums.<br=
>
><br>
> The default values change over time as the needs of people, programs a=
nd hardware change. Many values for sysctls changed over time.<br>
> 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.<br>
> 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.=
<br>
><br>
> Kind regards<br>
> Miroslav Lachman<br>
<br>
I like the idea of an option in bsdinstall, but I don't think it is nec=
essary<br>
to check the storage type.=C2=A0 It could simply default to noatime.<br>
<br>
I think we should automatically use noatime on SD card images (where bsdins=
tall<br>
doesn't get used).<br>
<br>
Separately, I think a relatime option would be a good compromise, and I wou=
ld<br>
probably use it.<br></blockquote><div><br></div><div>I think these are sens=
ible steps. We already do something similar for ZFS.</div><div><br></div><d=
iv>Warner=C2=A0</div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <marklmi@yahoo.com>
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 <marklmi@yahoo.com>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <D413660B-FE31-4B24-A501-20F7A4B65E61@yahoo.com>
Date: Thu, 11 Jan 2024 23:28:43 -0800
To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>,
Current FreeBSD <freebsd-current@freebsd.org>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
References: <D413660B-FE31-4B24-A501-20F7A4B65E61.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];
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 <freebsd-rwg_at_gndrsh.dnsmgr.net> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <Alexander@Leidinger.net>
To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc: Mark Millard <marklmi@yahoo.com>, olce@freebsd.org, Current FreeBSD
<freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
In-Reply-To: <202401111715.40BHFJ3Q049600@gndrsh.dnsmgr.net>
References: <202401111715.40BHFJ3Q049600@gndrsh.dnsmgr.net>
Message-ID: <fdd4749effb219115d4ae5d9c63f59c8@Leidinger.net>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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?= <des@FreeBSD.org>
To: Tomek CEDRO <tomek@cedro.info>
Cc: freebsd-current@freebsd.org, Warner Losh <imp@bsdimp.com>, Olivier
Certner <olce@freebsd.org>
Subject: Re: noatime on ufs2
In-Reply-To: <CAFYkXj=xdDW38ehGqu6J=pwfmR0XTr=rOpPChEWNuFbidfDVUg@mail.gmail.com>
(Tomek CEDRO's message of "Wed, 10 Jan 2024 21:34:57 +0100")
References: <ZZqmmM-6f606bLJx@int21h> <1749331.ETpRK2a2Mi@ravel>
<CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com>
<2136329.mxFCRLsXLg@ravel>
<CAFYkXj=xdDW38ehGqu6J=pwfmR0XTr=rOpPChEWNuFbidfDVUg@mail.gmail.com>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Tomek CEDRO <tomek@cedro.info> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <dfr@rabson.org>
Date: Fri, 12 Jan 2024 17:57:30 +0000
Message-ID: <CACA0VUjwCcXTq5m=S8_Mj6pTpiyZ7=v7um=NxsR3Uj1c-_vuYQ@mail.gmail.com>
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 <marklmi@yahoo.com>
Cc: Current FreeBSD <freebsd-current@freebsd.org>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
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 <marklmi@yahoo.com> 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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, 30 Sept 2023 at 08:47, Mark M=
illard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex">ram_attach is based on regions_to_avail but=
that is a problem for<br>
its later bus_alloc_resource use --and that can lead to:<br>
<br>
panic("ram_attach: resource %d failed to attach", rid);<br>
<br>
Unfortunately, the known example is use of EDK2 on RPi4B<br>
class systems, not what is considered the supported way.<br>
The panic happens for main [so: 15] and will happen once<br>
the cortex-a72 handling in 14.0-* is in a build fixed by:<br>
<br>
=C2=A0 =C2=A0 =E2=80=A2 git: 906bcc44641d - releng/14.0 - arm64: Fix errata=
workarounds that depend on smccc Andrew Turner<br>
<br>
The lack of the fix leads to an earlier panic as stands.<br>
<br>
<br>
sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring<br>
phys_avail and using only hwregions and exregions. In other words,<br>
in part:<br>
<br>
=C2=A0* Initially dump_avail and phys_avail are identical.=C2=A0 Boot time =
memory<br>
=C2=A0* allocations remove extents from phys_avail that may still be includ=
ed<br>
=C2=A0* in dumps.<br>
<br>
This means that early, dedicated memory allocations are treated<br>
as available for general use by regions_to_avail . The distinction<br>
is visible in the=C2=A0 boot -v output in that:<br>
<br>
real memory=C2=A0 =3D 3138154496 (2992 MB)<br>
Physical memory chunk(s):<br>
0x00000000200000 - 0x0000002b7fffff, 727711744 bytes (177664 pages)<br>
0x0000002ce3a000 - 0x0000003385ffff, 111304704 bytes (27174 pages)<br>
0x000000338c0000 - 0x000000338c6fff, 28672 bytes (7 pages)<br>
0x00000033a30000 - 0x00000036efffff, 55377920 bytes (13520 pages)<br>
0x000000372e0000 - 0x0000003b2fffff, 67239936 bytes (16416 pages)<br>
0x00000040000000 - 0x000000bb3dcfff, 2067648512 bytes (504797 pages)<br>
avail memory =3D 3027378176 (2887 MB)<br>
<br>
does not list the wider:<br>
<br>
0x00000040000000 - 0x000000bfffffff<br>
<br>
because of phys_avail . But the earlier dump based on hwregions and<br>
exregions shows:<br>
<br>
Physical memory chunk(s):<br>
=C2=A0 0x001d0000 - 0x001effff,=C2=A0 =C2=A0 =C2=A00 MB (=C2=A0 =C2=A0 =C2=
=A032 pages)<br>
=C2=A0 0x00200000 - 0x338c6fff,=C2=A0 =C2=A0822 MB ( 210631 pages)<br>
=C2=A0 0x33920000 - 0x3b2fffff,=C2=A0 =C2=A0121 MB (=C2=A0 31200 pages)<br>
=C2=A0 0x40000000 - 0xbfffffff,=C2=A0 2048 MB ( 524288 pages)<br>
Excluded memory regions:<br>
=C2=A0 0x001d0000 - 0x001effff,=C2=A0 =C2=A0 =C2=A00 MB (=C2=A0 =C2=A0 =C2=
=A032 pages) NoAlloc <br>
=C2=A0 0x2b800000 - 0x2ce39fff,=C2=A0 =C2=A0 22 MB (=C2=A0 =C2=A05690 pages=
) NoAlloc <br>
=C2=A0 0x33860000 - 0x338bffff,=C2=A0 =C2=A0 =C2=A00 MB (=C2=A0 =C2=A0 =C2=
=A096 pages) NoAlloc <br>
=C2=A0 0x33920000 - 0x33a2ffff,=C2=A0 =C2=A0 =C2=A01 MB (=C2=A0 =C2=A0 272 =
pages) NoAlloc <br>
=C2=A0 0x36f00000 - 0x372dffff,=C2=A0 =C2=A0 =C2=A03 MB (=C2=A0 =C2=A0 992 =
pages) NoAlloc <br>
<br>
which indicates:<br>
<br>
=C2=A0 0x40000000 - 0xbfffffff<br>
<br>
is available as far as it is concerned.<br>
<br>
(Note some code works/displays in terms of: 0x40000000 - 0xc0000000<br>
instead.)<br>
<br>
For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource<br>
that is used as bus_alloc_resource . It ends up rejecting the<br>
RPi4B boot via using the result of the call in ram_attach:<br>
<br>
=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,<br>
=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)<br>
=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)=
;<br>
<br>
as shown by the just-prior start/end pair sequence messages:<br>
<br>
ram0: reserving memory region:=C2=A0 =C2=A0200000-2b800000<br>
ram0: reserving memory region:=C2=A0 =C2=A02ce3a000-33860000<br>
ram0: reserving memory region:=C2=A0 =C2=A0338c0000-338c7000<br>
ram0: reserving memory region:=C2=A0 =C2=A033a30000-36f00000<br>
ram0: reserving memory region:=C2=A0 =C2=A0372e0000-3b300000<br>
ram0: reserving memory region:=C2=A0 =C2=A040000000-c0000000<br>
panic: ram_attach: resource 5 failed to attach<br>
<br>
I do not see anything about this that looks inherently RPi*<br>
specific for possibly ending up with an analogous panic. So<br>
I expect the example is sufficient context to identify a<br>
problem is present, despite EDK2 use not being normal for<br>
RPi4B's and the like as far as FreeBSD is concerned.<br></blockquote><d=
iv><br></div><div>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?</div><div><br></div><div>Doug.</div><div>=C2=A0</div></div></di=
v>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <1749331.ETpRK2a2Mi@ravel>
<CANCZdfo8VyhSJEUQpnvXuoPq0dzUHDN1sj-_y=1FTqXR3FrSuA@mail.gmail.com>
<2136329.mxFCRLsXLg@ravel> <CAFYkXj=xdDW38ehGqu6J=pwfmR0XTr=rOpPChEWNuFbidfDVUg@mail.gmail.com>
<86v87y4gn6.fsf@ltc.des.no>
In-Reply-To: <86v87y4gn6.fsf@ltc.des.no>
From: Tomek CEDRO <tomek@cedro.info>
Date: Fri, 12 Jan 2024 21:12:07 +0100
X-Gmail-Original-Message-ID: <CAFYkXjnVk_VPtEehZNa5ShTRJWv+E7eCWAJ193RduuR-YmWCPA@mail.gmail.com>
Message-ID: <CAFYkXjnVk_VPtEehZNa5ShTRJWv+E7eCWAJ193RduuR-YmWCPA@mail.gmail.com>
Subject: Re: noatime on ufs2
To: freebsd-current@freebsd.org
Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@freebsd.org>,
Warner Losh <imp@bsdimp.com>, Olivier Certner <olce@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <marklmi@yahoo.com>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <marklmi@yahoo.com>
In-Reply-To: <CACA0VUjwCcXTq5m=S8_Mj6pTpiyZ7=v7um=NxsR3Uj1c-_vuYQ@mail.gmail.com>
Date: Fri, 12 Jan 2024 13:53:15 -0800
Cc: Current FreeBSD <freebsd-current@freebsd.org>,
FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5D3DDFC-8183-4F0B-98BB-FEB3E8392B09@yahoo.com>
References: <3CB904C2-D983-4EF7-84D3-6BDED0700B08.ref@yahoo.com>
<3CB904C2-D983-4EF7-84D3-6BDED0700B08@yahoo.com>
<CACA0VUjwCcXTq5m=S8_Mj6pTpiyZ7=v7um=NxsR3Uj1c-_vuYQ@mail.gmail.com>
To: Doug Rabson <dfr@rabson.org>
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 <dfr@rabson.org> wrote:
> On Sat, 30 Sept 2023 at 08:47, Mark Millard <marklmi@yahoo.com> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <lexi@le-fay.org>
To: Ronald Klop <ronald@freebsd.org>
Cc: freebsd-current@freebsd.org
Subject: Re: poudriere: swap_pager: out of swap space
Message-ID: <ZaIDIbu0WAIerktB@ilythia.eden.le-fay.org>
References: <ZZ9Qn1W4k8UKnT6W@ilythia.eden.le-fay.org>
<94c6cf1b-10e4-49c4-aa1d-e87f8e8c3d09@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <xms:nauiZdCWOUPfyIBvF3VGd7EHD8x73MndTja3qUN_phAU05gOskEtpA>
<xme:nauiZbgyugzGEQFLgiuXgQ_imHhD1idTBcyABCqTP1Aky96ZjdErqCpeVzlyWSLaY
2AprpTTXAReg3NxSw>
X-ME-Received: <xmr:nauiZYlA2f2_WUP9Si9wbVmqJ1LK0R82R0ZBNs6VO3Q-Eulhid8hCF7ewwAnm0QYD5g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeijedgjeejucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd
dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht
vghrnhepjeejvdejhfejjeelhfffheduhfduleeiuddvfeegtefhudeigffgheetvdehke
fhnecuffhomhgrihhnpehushgvrhdrfhhmnecuvehluhhsthgvrhfuihiivgeptdenucfr
rghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh
X-ME-Proxy: <xmx:nauiZXz8qtYN5mM1lfq0dP1VdRBgbpcKVEgeVqSUTCKO6pU_L-OBJw>
<xmx:nauiZSStOIyPQoYUAupUFa1PdI2YH9ASCffLWtNlvmLfx_m_N9KLMw>
<xmx:nauiZaasxvWhFIeH15fFqMBjWo0gtdmaLaXAYWO2Km_HRevDUYqfBA>
<xmx:nauiZZME3VVyH47swyagEVEPMWVPCD0gUUAx9mey0JhFrBHUIpUktA>
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<freebsd-current@freebsd.org>; Sat, 13 Jan 2024 10:26:21 -0500 (EST)
Date: Sat, 13 Jan 2024 15:26:19 +0000
From: void <void@f-m.fm>
To: freebsd-current@freebsd.org
Subject: bsdinstall use on rpi4
Message-ID: <ZaKrm-LGkGhS2HDb@int21h>
Mail-Followup-To: freebsd-current@freebsd.org
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <fbsd@www.zefox.net>
To: freebsd-current@freebsd.org
Cc: freebsd-arm@freebsd.org
Subject: Re: bsdinstall use on rpi4
Message-ID: <ZaK5LZi25OrZxAMa@www.zefox.net>
References: <ZaKrm-LGkGhS2HDb@int21h>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZaKrm-LGkGhS2HDb@int21h>
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: <xms:b8KiZUuAq4UVbYmI2MehIjKXfMLCqGcvKTH__F3XI_mYxncpPusPhA>
<xme:b8KiZRceY5ZWd96bkALa06dVCSpt6p0E0nQHIQbq3qC91elTXdxOriELuPH8aS7sJ
6Rd0J7Xu2rBG5umHw>
X-ME-Received: <xmr:b8KiZfzR0LvYRV64QnguQ9FTYZe1meYvQ3r6KVGvqy8YJsIPy7ed6Lc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeijedgleejucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
thhtvghrnhepleevvefhheeffeffheefffekvedvfffgtdffjefhfedvgeelveevudejje
ejleehnecuffhomhgrihhnpehushgvrhdrfhhmnecuvehluhhsthgvrhfuihiivgeptden
ucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh
X-ME-Proxy: <xmx:b8KiZXM8xfVwxG86msJ4BZitkRZja5kBydFwdc2_PckyBg_vNhHrlw>
<xmx:b8KiZU_TkYkTQbtA3bDvdiqSD_8Se7iC_mSoYvAdbFs9A9n0ZgwYsA>
<xmx:b8KiZfWOqmZtMHoLz5bV7lp1b7qHC73VndrXoIuDRcsdnT1vrWmoEg>
<xmx:b8KiZZGyD-4AtX6DzVL8RaAdppo43DDYCg4q92cFfRCtkRFwcRqmkw>
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 <void@f-m.fm>
To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Subject: Re: bsdinstall use on rpi4
Message-ID: <ZaLCbXIvgjc2nsMV@int21h>
Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
References: <ZaKrm-LGkGhS2HDb@int21h>
<ZaK5LZi25OrZxAMa@www.zefox.net>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZaK5LZi25OrZxAMa@www.zefox.net>
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 <fbsd@www.zefox.net>
To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Subject: Re: bsdinstall use on rpi4
Message-ID: <ZaLPv1/ZrcNLe3M9@www.zefox.net>
References: <ZaKrm-LGkGhS2HDb@int21h>
<ZaK5LZi25OrZxAMa@www.zefox.net>
<ZaLCbXIvgjc2nsMV@int21h>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZaLCbXIvgjc2nsMV@int21h>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Sat, 13 Jan 2024 19:33:25 +0100 (CET)
Date: Sat, 13 Jan 2024 19:32:57 +0100
From: FreeBSD User <freebsd@walstatt-de.de>
To: FreeBSD CURRENT <freebsd-current@freebsd.org>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <ronald-lists@klop.ws>
To: FreeBSD User <freebsd@walstatt-de.de>
Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <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
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html><head></head><body><br><p><small><strong>Van:</strong> FreeBSD User <freebsd@walstatt-de.de><br><strong>Datum:</strong> 13 januari 2024 19:34<br><strong>Aan:</strong> FreeBSD CURRENT <freebsd-current@freebsd.org><br><strong>Onderwerp:</strong> NFSv4 crash of CURRENT<br></small></p><blockquote style="margin-left: 5px; border-left: 3px solid #ccc; margin-right: 0px; padding-left: 5px;"><div class="MessageRFC822Viewer do_not_remove" id="P"><!-- P -->
<!-- processMimeMessage --><div class="TextPlainViewer do_not_remove" id="P.P"><!-- P.P -->Hello,<br>
<br>
running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat Jan 13 18:08:32<br>
CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client, other is FreeBSD<br>
13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.<br>
<br>
I can crash the client reproducable by accessing the one or other NFSv4 FS (a simple ls -la).<br>
The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla access to the client<br>
host, luckily the box recovers.<br>
<br>
I have no idea what causes this problem ...<br>
<br>
Kind regards,<br>
<br>
O. Hartmann<br>
<br>
<br>
-- <br>
O. Hartmann<br>
<br>
</div><!-- TextPlainViewer -->
<hr>
</div><!-- MessageRFC822Viewer -->
</blockquote><br><br>Do you have something like a panic message, stack trace or core dump?<div><br></div><div>Regards</div><div>Ronald</div></body></html>
------=_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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <rick.macklem@gmail.com>
Date: Sat, 13 Jan 2024 19:41:30 -0800
Message-ID: <CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.com>
Subject: Re: NFSv4 crash of CURRENT
To: Ronald Klop <ronald-lists@klop.ws>
Cc: FreeBSD User <freebsd@walstatt-de.de>, FreeBSD CURRENT <freebsd-current@freebsd.org>
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 <ronald-lists@klop.ws>=
wrote:
>
>
> 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 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <marklmi@yahoo.com>
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 <marklmi@yahoo.com>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <freebsd-current@freebsd.org>
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 <lexi_at_le-fay.org> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd@walstatt-de.de>
To: Rick Macklem <rick.macklem@gmail.com>
Cc: Ronald Klop <ronald-lists@klop.ws>, FreeBSD CURRENT
<freebsd-current@freebsd.org>
Subject: Re: NFSv4 crash of CURRENT
Message-ID: <20240114092521.65287a17@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.com>
References: <20240113193324.3fd54295@thor.intern.walstatt.dynvpn.de>
<1369645989.13766.1705178331205@localhost>
<CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.com>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <rick.macklem@gmail.com> schrieb:
> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop <ronald-lists@klop.w=
s> wrote:
> >
> >
> > 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-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 <freebsd@walstatt-de.de>
To: Felix Reichenberger <felix.reichenberger@tuta.io>
Cc: FreeBSD CURRENT <freebsd-net@freebsd.org>, FreeBSD CURRENT
<freebsd-current@freebsd.org>
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: <NnaUN0n--3-9@tuta.io>
References: <20240107185133.68824d89@thor.intern.walstatt.dynvpn.de>
<NnaUN0n--3-9@tuta.io>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <felix.reichenberger@tuta.io> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
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: <a5e38bfbabd37084@orthanc.ca>
References:
<ZZqmmM-6f606bLJx@int21h> <6714298.qJWK8QVVMX@ravel>
<a5e38bfbabd37084@orthanc.ca>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
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: <a5e38bfbabd37084@orthanc.ca>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Jamie Landeg-Jones <jamie@catflap.org>
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:
<ZZqmmM-6f606bLJx@int21h> <2136329.mxFCRLsXLg@ravel>
<202401111956.40BJuURB045685@donotpassgo.dyslexicfish.net>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Jamie Landeg-Jones <jamie@catflap.org>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Rick Macklem <rick.macklem@gmail.com>
Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>,
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:
<CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com>
References:
<ZZqmmM-6f606bLJx@int21h> <a5e38bfbabd37084@orthanc.ca>
<CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Rick Macklem <rick.macklem@gmail.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Mark Millard <marklmi@yahoo.com>
Cc: Current FreeBSD <freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
Date: Sun, 14 Jan 2024 17:39:04 +0100
Message-ID: <3183964.fD0qBhBWp0@ravel>
In-Reply-To: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
References:
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Mark Millard <marklmi@yahoo.com>
Cc: Current FreeBSD <freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
Date: Sun, 14 Jan 2024 17:39:04 +0100
Message-ID: <3183964.fD0qBhBWp0@ravel>
In-Reply-To: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc: Mark Millard <marklmi@yahoo.com>,
Current FreeBSD <freebsd-current@freebsd.org>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Mike Karels <mike@karels.net>
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:
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz>
<5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Mike Karels <mike@karels.net>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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)" <lyndon@orthanc.ca>
To: Olivier Certner <olce@freebsd.org>
cc: Rick Macklem <rick.macklem@gmail.com>, freebsd-current@freebsd.org
Subject: Re: noatime on ufs2
In-reply-to: <4014880.cjyAsbXg9l@ravel>
References: <ZZqmmM-6f606bLJx@int21h> <a5e38bfbabd37084@orthanc.ca> <CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com> <4014880.cjyAsbXg9l@ravel>
Comments: In-reply-to Olivier Certner <olce@freebsd.org>
message dated "Sun, 14 Jan 2024 17:38:52 +0100."
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <a5e3a25e0d57d1a9@orthanc.ca>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <ZZqmmM-6f606bLJx@int21h> <a5e38bfbabd37084@orthanc.ca>
<CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com>
<4014880.cjyAsbXg9l@ravel> <a5e3a25e0d57d1a9@orthanc.ca>
In-Reply-To: <a5e3a25e0d57d1a9@orthanc.ca>
From: Warner Losh <imp@bsdimp.com>
Date: Sun, 14 Jan 2024 10:58:13 -0700
Message-ID: <CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
Subject: Re: noatime on ufs2
To: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
Cc: Olivier Certner <olce@freebsd.org>, Rick Macklem <rick.macklem@gmail.com>,
FreeBSD Current <freebsd-current@freebsd.org>
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
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sun, Jan 14, 2024, 10:24=E2=80=AFAM Lyndon Nerenber=
g (VE7TFX/VE6BBM) <<a href=3D"mailto:lyndon@orthanc.ca">lyndon@orthanc.c=
a</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > I do not=
have a strong opinion w.r.t. atime, but I do believe that<br>
> > changing the default would be a POLA violation.<br>
<br>
I'm not prepared to just accept that at face value.<br>
<br>
I can't think of a single instance in at least the last three decades<b=
r>
where I have actually used or needed atime for *anything*.=C2=A0 And<br>
over that time period I have been responsible for running hundreds<br>
of UNIX servers.<br>
<br>
I'm really interested in hearing from people who actively use<br>
atime on a regular basis for non-trivial purposes.=C2=A0 What are<br>
the modern use cases for atime?<br></blockquote></div></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">The consensus was we'd fix it in the ins=
taller.</div><div dir=3D"auto"><br></div><div dir=3D"auto">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.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">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.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">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.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
--lyndon<br>
<br>
</blockquote></div></div></div>
--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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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)" <lyndon@orthanc.ca>
To: Warner Losh <imp@bsdimp.com>
cc: Olivier Certner <olce@freebsd.org>,
Rick Macklem <rick.macklem@gmail.com>,
FreeBSD Current <freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
In-reply-to: <CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
References: <ZZqmmM-6f606bLJx@int21h> <a5e38bfbabd37084@orthanc.ca> <CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com> <4014880.cjyAsbXg9l@ravel> <a5e3a25e0d57d1a9@orthanc.ca> <CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
Comments: In-reply-to Warner Losh <imp@bsdimp.com>
message dated "Sun, 14 Jan 2024 10:58:13 -0700."
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <a5e3a29d6765ce1c@orthanc.ca>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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" <pmh@hausen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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: <ZZqmmM-6f606bLJx@int21h> <a5e38bfbabd37084@orthanc.ca>
<CAM5tNy4HuHb=GpQXvE4h2NC8_azOwDS3H7wY3UK+cE07owPr3A@mail.gmail.com>
<4014880.cjyAsbXg9l@ravel> <a5e3a25e0d57d1a9@orthanc.ca>
<CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
To: Warner Losh <imp@bsdimp.com>, FreeBSD Current
<freebsd-current@freebsd.org>
In-Reply-To:
<CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
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 <imp@bsdimp.com>:
> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <marklmi@yahoo.com>
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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <marklmi@yahoo.com>
In-Reply-To: <3183964.fD0qBhBWp0@ravel>
Date: Sun, 14 Jan 2024 10:53:34 -0800
Cc: Current FreeBSD <freebsd-current@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com>
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com> <3183964.fD0qBhBWp0@ravel>
To: Olivier Certner <olce@freebsd.org>
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 <olce@freebsd.org> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <junchoon@dec.sakura.ne.jp>
To: Mark Millard <marklmi@yahoo.com>
Cc: Olivier Certner <olce@freebsd.org>,
Current FreeBSD
<freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
Message-Id: <20240115072732.85c2213714a658d3b98ab830@dec.sakura.ne.jp>
In-Reply-To: <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com>
References: <F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677@yahoo.com>
<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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <marklmi@yahoo.com> wrote:
> On Jan 14, 2024, at 08:39, Olivier Certner <olce@freebsd.org> 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 <junchoon@dec.sakura.ne.jp>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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: <jamie@donotpassgo.dyslexicfish.net>
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 <jamie@catflap.org>
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: <ZZqmmM-6f606bLJx@int21h> <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 <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org> 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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>,
Rick Macklem <rick.macklem@gmail.com>,
FreeBSD Current <freebsd-current@freebsd.org>
Subject: Re: noatime on ufs2
Date: Mon, 15 Jan 2024 00:08:15 +0100
Message-ID: <2798057.DSuhTWmZiM@ravel>
In-Reply-To:
<CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
References:
<ZZqmmM-6f606bLJx@int21h> <a5e3a25e0d57d1a9@orthanc.ca>
<CANCZdfosFb1xQdRL9rW1icbVAYbspqnKwWR4CO2guVd5LAv4HA@mail.gmail.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Warner Losh <imp@bsdimp.com>
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 <freebsd-current@mlmmj.nyi.freebsd.org>; 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 <olce@freebsd.org>
To: Mark Millard <marklmi@yahoo.com>
Cc: Current FreeBSD <freebsd-current@freebsd.org>
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:
<F5D2BD92-5AC3-4B1E-8B47-A1F13D9FC677.ref@yahoo.com>
<3183964.fD0qBhBWp0@ravel> <6A477CBE-692E-49F9-B21E-2C0D29F09766@yahoo.com>
List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: <mailto:freebsd-current+help@freebsd.org>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Subscribe: <mailto:freebsd-current+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-current+unsubscribe@freebsd.org>
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 <olce@freebsd.org>
To: Mark Millard <marklmi@yahoo.com>
Cc: Current FreeBSD <freebsd-current@freebsd.org>
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--