From nobody Wed Nov 2 14:11:39 2022 X-Original-To: freebsd-stable@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 4N2TN954d1z4hFsw for ; Wed, 2 Nov 2022 14:11:53 +0000 (UTC) (envelope-from jon@xyinn.org) Received: from mail-4022.proton.ch (mail-4022.proton.ch [185.70.40.22]) (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 "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N2TN71cSqz3KLj for ; Wed, 2 Nov 2022 14:11:51 +0000 (UTC) (envelope-from jon@xyinn.org) Date: Wed, 02 Nov 2022 14:11:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xyinn.org; s=protonmail3; t=1667398307; x=1667657507; bh=Kr78M4OmMo7xbeZV/OqzC048r8uoCZlIkf+zCHee5dE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=WGR/jY1YuHmUENLTrwuW4Bp7NP2yMD618rVu4X1GZOAm1eWbtJBvqZdKGle5/+1Ea H7NmpHGZfG/CsozazEFpMXhTvoIaSjjMx8cvd/i2jkJWfjjbsC9/QxdCvwf4tdHtXA AA7/gG2ZzQyVBGqlw32Dc+NoeHmOxrNvBOUWT4xIUQBlibAGjur7p9Z4abT/xsXwGY TCFysIRcdCThUVGsFDKPPIgsvrCO5C8afe7kdRm2838J6egIFd0ot1Dd4tJfjQ+3CC eOLRht0FbWJrB7SmnR+kQLYj5HWhd6ZJuFvcM3FPuXRExiSQ0rivOg0qq6fLM7vp7J kZSMTy0JrHMuw== To: Thomas Zander From: Jonathan Vasquez Cc: freebsd-stable@freebsd.org, FreeBSD Errata Notices Subject: Re: FreeBSD Errata Notice FreeBSD-EN-22:21.zfs Message-ID: In-Reply-To: References: <20221101222046.AB5483910@freefall.freebsd.org> Feedback-ID: 12351801:user:proton List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4N2TN71cSqz3KLj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=xyinn.org header.s=protonmail3 header.b="WGR/jY1Y"; dmarc=pass (policy=none) header.from=xyinn.org; spf=pass (mx1.freebsd.org: domain of jon@xyinn.org designates 185.70.40.22 as permitted sender) smtp.mailfrom=jon@xyinn.org 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)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[xyinn.org,none]; R_DKIM_ALLOW(-0.20)[xyinn.org:s=protonmail3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[xyinn.org:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; FREEFALL_USER(0.00)[jon]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I spoke to Richard today, and asked him your question on your behalf. He sa= id the following: "Most of the time, the issue does not go to disk. When it does they are not= well understood yet. He would probably know if it did since things could g= o horribly wrong, but if he wants to try to be sure, he could try using zdb= -bcc ... to try to verify certain things about his pool, but again, the re= sults of undefined behavior in the btree code is not well understood. It is= a very complex thing to analyze and I have not had time to do that. There = are a couple of bug reports in GitHub that I suspect are related, but canno= t prove currently." Jonathan Vasquez PGP: 34DA 858C 1447 509E C77A D49F FB85 90B7 C4CA 5279 Sent with ProtonMail Secure Email ------- Original Message ------- On Tuesday, November 1st, 2022 at 19:45, Thomas Zander = wrote: > On Tue, 1 Nov 2022 at 23:21, FreeBSD Errata Notices > errata-notices@freebsd.org wrote: >=20 > > Systems with debug kernels may sometimes detect this issue after a kern= el > > memory corruption has happened. When they do, they will trigger a kerne= l > > panic to protect the system from further damage. The following is print= ed > > to dmesg at the time of the panic: >=20 >=20 > On production systems, is there any way to check for corruptions? Will > a "zpool scrub" find problems?