From nobody Sun Apr 9 02:40:37 2023 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 4PvGYs4bVHz459tn; Sun, 9 Apr 2023 02:40:49 +0000 (UTC) (envelope-from kevans@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 4PvGYs44mBz4QX0; Sun, 9 Apr 2023 02:40:49 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681008049; 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=AqA0V16yq+OjcCMN0KeBOsKnhVu7f+IR7+tSxbNk2tA=; b=imoxzr0KxJnxZ77/qF+L6QGNzNWTQJT8i67NKcVhITZ3HsFxsQYYQODwdVAQqjhz4Y7h7r SxXjb+ibQZIbApopf0+O9VciIGns4swhggAc36z5iG+a6JZfHy1aSnCKXhsVamGZsb36AJ UfGlEpwQd5CyBdHJJ0qbBsInC9ZI2sVuPN7TmLFpJhF2dXad2P+WVB6qswsnHvEo1Hm/ij 9qcgYKJBzYZhbvlxY/WAwbLPaYkhOaM71ft6M+VsI0HdBimr12G9UcabcP2Ow7eztVRuXo HIi2aD3GTf8cx22CyKtTl4NAEKQRJ0aiXYEebDSlrfh35M9XTVKQsx3oFpITag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681008049; 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=AqA0V16yq+OjcCMN0KeBOsKnhVu7f+IR7+tSxbNk2tA=; b=q1/sn321PDuaAS1u3SUw6AVyQGMvK70ccvRjidgKoEUVy6uGx2aYDczjzn9wRjlI8xYlus e9u3SiFaDGUXw2x3VigOrr1mSHH7Y0BvC/imQ/OerBAdJL6nzSihmxpRP4OIWJzQy12POh iJwAA1PycxPoq7eulWevtErUmRCALLGYZARPIWxzp0IR7+tFU5ijo9tAvkJ4NzQ/XUYn9I Um5UatY6ApKEQitNgjxyUsQXFjHKXO0259zo6lc6JSjGhBuDfwacOGHu/xcU4BSfAeNSne VcZZxCuAcHbrIakWm3nAHm+lizdzm6GM7HNSVDzYG+UgWMcWVbnYtUhyRzaRbQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681008049; a=rsa-sha256; cv=none; b=M+HN41JfLYKu75HArFp1ZJRPmX/9NxoV8U2Uj9F1LjFbnfY6XaXvYPmzh5AxQfCOQnq3Px un3YZ8wpgPBEt84LAhvGOe4l5aKqIBYHKXMyMK2Bb0WhlnFpsTk5AGCDArOshBgWAZdaS+ iVhXVsfw5at3p3ah8gezGKBceOkznk4kA92MAiTlzX0tgmmNCuf5zIPDpY2d8/7VYIoFpO fkFvxVwc/9imW3d+AOORUxiiUV2LLcjaT57xzydzxVu65XKBc6lOA7dTVttD2eM0kR4EAl +tNxN4OXwiYrMRvlI2SdcUJu6yKMl7KPcBBNTCI8NkbjIi/B8l6aooWS4XIXYQ== Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PvGYs31fJznyQ; Sun, 9 Apr 2023 02:40:49 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id bn8so1880690qtb.2; Sat, 08 Apr 2023 19:40:49 -0700 (PDT) X-Gm-Message-State: AAQBX9eYp2gkBIQhjXiNpeLf2/dX+c1fBsBNn9wfhA6+VhYI83VnloTo mJXpt0AKcOb8QRuvNup1Ep735153EANgwpdBnvw= X-Google-Smtp-Source: AKy350aifjTI7XK/IbTGk9Rucrolsyq7xpXzsohboE6/AULmqSGdMZqIqd+2L2Q1vFbBUdnREG1HuyspheUOXiNcTX4= X-Received: by 2002:a05:622a:394:b0:3d7:9d03:75b0 with SMTP id j20-20020a05622a039400b003d79d0375b0mr2572684qtx.13.1681008048647; Sat, 08 Apr 2023 19:40:48 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <3A019D10-E520-4C11-AE9F-4EA5D99B9B07@yahoo.com> In-Reply-To: From: Kyle Evans Date: Sat, 8 Apr 2023 21:40:37 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import] To: Mateusz Guzik Cc: Kyle Evans , Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD , freebsd-arm , John F Carr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 8, 2023 at 5:24=E2=80=AFAM Mateusz Guzik wr= ote: > > On 4/8/23, Kyle Evans wrote: > > On Fri, Apr 7, 2023 at 4:54=E2=80=AFPM Mateusz Guzik wrote: > >> > >> On 4/7/23, Mark Millard wrote: > >> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote: > >> > > >> >> On 4/7/23, Mateusz Guzik wrote: > >> >>> can you try with this: > >> >>> > >> >>> diff --git > >> >>> a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> index 16276b08c759..e1bca9ef140a 100644 > >> >>> --- > >> >>> a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> +++ > >> >>> b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> @@ -71,7 +71,7 @@ > >> >>> #define ID_AA64PFR0_EL1 sys_reg(3, 0, 0, 1, 0) > >> >>> #define ID_AA64ISAR0_EL1 sys_reg(3, 0, 0, 6, 0) > >> >>> > >> >>> -#define kfpu_allowed() 1 > >> >>> +#define kfpu_allowed() 0 > >> >>> #define kfpu_begin() kernel_neon_begin() > >> >>> #define kfpu_end() kernel_neon_end() > >> >>> #define kfpu_init() (0) > >> >>> > >> >>> > >> >> > >> >> ops, wrong file > >> >> > >> >> diff --git a/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_ar= m.h > >> >> b/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h > >> >> index 178fbc3b3c6e..c462220289d6 100644 > >> >> --- a/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h > >> >> +++ b/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h > >> >> @@ -46,7 +46,7 @@ > >> >> #include > >> >> #include > >> >> > >> >> -#define kfpu_allowed() 1 > >> >> +#define kfpu_allowed() 0 > >> >> #define kfpu_initialize(tsk) do {} while (0) > >> >> #define kfpu_begin() do {} while (0) > >> >> #define kfpu_end() do {} while (0) > >> > > >> > It will take me a bit to setup a separate build/install > >> > context for the source code vintage involved. Then more > >> > time to do the build, install, and test. (I'm keeping > >> > my normal environments completely before the mess.) > >> > > >> > FYI: > >> > > >> > I have used the artifact build just after your pair of zfs > >> > related updates to confirm the VFP problem is still in > >> > place as of that point: > >> > > >> > https://artifact.ci.freebsd.org/snapshot/main/5e2e3615d91f9c0c688987= 915ff5c8de23c22bde/arm64/aarch64/kernel.txz > >> > > >> > (No artifact build was exactly at either of your commits.) > >> > > >> > =3D=3D=3D > >> > Mark Millard > >> > marklmi at yahoo.com > >> > > >> > > >> > >> I have arm64 + zfs at $job and just verified the above lets it boot > >> again, so I committed already. > >> > > > > This was a known issue that we were working on fixing properly over in > > https://reviews.freebsd.org/D39448... this really could have waited > > just a little bit longer. This problem was already brought up in > > response to the commit in question days ago. > > > > Mate, that's one confusing email. > Sorry, this was misdirected anger around this series of crappery. > I had seen the upstream review, apparently there is opposition to the > patch, it is clearly not going to land within hours. > The opposition is notably from a person that does not actually work on this platform, and IMO has no bearing on our downstream review. We'll get past him eventually, because this is what needs to happen. > Whatever the Real Fix(tm) might be, I'm confident my change has no > impact on work on it, past the need to flip kfpu_allowed back to 1. > > At the same time things were broken to the point where aarch64 + zfs > literally did not boot. Once more, I fail to see how restoring basic > operation by fipping a macro to 0 throws any wrenches into the effort > to get simd working. > Thanks! > If anything the question is how come a clearly *not* implemented simd > support got kfpu_allowed set to 1. > Your guess is as good as mine -- it clearly could not have been tested at all, I have no clue why they didn't err on the side of caution and avoid fpu usage. Thanks, Kyle Evans From nobody Sun Apr 9 11:59:56 2023 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 4PvVzj0JV3z44LG3 for ; Sun, 9 Apr 2023 12:00:33 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4PvVzh0j0Mz3w5s for ; Sun, 9 Apr 2023 12:00:31 +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=ouvC0d6t; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (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 3125A101CC5A for ; Sun, 9 Apr 2023 14:00:28 +0200 (CEST) Received: from hub1.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 hub1.goneo.de (Postfix) with ESMTPS id 11D1810A1E97 for ; Sun, 9 Apr 2023 14:00:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1681041624; 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=Pr2iEtXg9UAYwZ+Qnm2dfkaPRBZQygi5XJOg3s/mPRA=; b=ouvC0d6tJ8oeCj3HpK22JgsavZ+su6B2woc7xxdfR3cGMF5TFOj9Ckas1Pf169f6DXDMCN obcJ1T24hSKRwZ6V7xB8x46hzftd2gMAzhzw9RVJO21HgWzvevRVy89eGQCoVcZvEOnYT2 o2g4Vsdd+OnEW1B2ZN8pW0GtgSqeN+5On1fx9thVgKHbCnCLQi382LdeDxYxOFdKKnH//f O3cDm7AdochsOMMqk0xikRiEPDOlDkR3DgXkGB5e/PIdXy86m2PpeUh+RMPxNYa97szra8 YsXrr7zVqEdsno7Hl3Yl8TmpuLfRMDltBtLV1glpkWnmccOxmtSAEhzKiDs+HA== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-191-007-166.77.191.pool.telefonica.de [77.191.7.166]) (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) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id DBC7B10A1E84 for ; Sun, 9 Apr 2023 14:00:23 +0200 (CEST) Date: Sun, 9 Apr 2023 13:59:56 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) Message-ID: <20230409140023.47aab826@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 8634f5 X-Rspamd-UID: 159ad7 X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from]; SUBJECT_HAS_EXCLAIM(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; DKIM_TRACE(0.00)[walstatt-de.de:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PvVzh0j0Mz3w5s X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun Apr 9 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via zpool upgrade POOLNAME some boxes keep crashing when starting compiler runs (the trigger is different on boxes). ZFS module is statically compiled into the kernel (if this is of importance) Last known good was: [...] Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 main-n262051-75379ea2e461: Sun Apr 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 <0.2> thor kernel: FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: VT(efifb): resolution 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already present! [...] The file /var/crash/info.X contains: [...] root@thor:/var/crash # more info.2 Dump header from device: /dev/gpt/swap Architecture: amd64 Architecture Version: 2 Dump Length: 1095192576 Blocksize: 512 Compression: none Dumptime: 2023-04-09 11:43:41 +0000 Hostname: thor.local Magic: FreeBSD Kernel Dump Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun Apr 9 12:01:02 CEST 2023 root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR Panic String: VERIFY(!zil_replaying(zilog, tx)) failed Dump Parity: 2961465682 Bounds: 2 Dump Status: good Until reconfigured for more debug stuff I do not have more to present. I rememeber now really scraed that there was a HEADSUP in the list regarding some serious ZFS problems - I didn't find it right now. Thanks in advance, happy Easter Oliver -- O. Hartmann From nobody Sun Apr 9 12:37:03 2023 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 4PvWnt1JwKz44NMq for ; Sun, 9 Apr 2023 12:37:06 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PvWns46kKz3jZk; Sun, 9 Apr 2023 12:37:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x22e.google.com with SMTP id m2so1329380oiw.0; Sun, 09 Apr 2023 05:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681043824; x=1683635824; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xDBYtPZtfwK5vzaLyqiiu3O6xkR/tPmeLxVAoEjaKX0=; b=aA8c1vpXiUifGUqfrKoXBa4I6/8iAGpNivqAyQLesvxspp2nVLEI8WdvuYeDlb9AEV KOSqiGr8eQo7dKR3M9py1lULa3+JAD5vn+FWdsH3Yl0nt+/wcGoJPnlpE7y0V3Ywhjaq Ajlq0DwSNCkGL3R/v12DaWTwPr2td6QqKYW4JP0okQgx4UTTGmgoYmwFZg5LSBuldSYL 8OvnTqNyacVvU5vrMebcsguZ4erYi9DBI0YcvyYh8Hc4PNF6C/VCN2igCx805/FFaFFJ KdZXxhbQmfrLyN8/IUwu0fB6ckXa20NP5ycVRwKjdl6EHqRERalB9wSzRVYVnl31tZIX v/Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681043824; x=1683635824; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xDBYtPZtfwK5vzaLyqiiu3O6xkR/tPmeLxVAoEjaKX0=; b=vZy4Pt5OYk1wqFrC/OqioScBgtucotYv+D5LpszyS6RzwrleGba0Td9A6Mw78lpa0p 4xJ5pb1MdwmAjj1GQqwtmgoHkGYONWouNJDke9UlQMe/MkUJi/8LGYXiIMLunFaC0wf4 NvcSoR7aPErhGPtcsrq+NBgOxrIm62iX6pvMBAIowxmIvezaMjtTQ/RsXPzxsC346fcA BavxRpgYOp5Mb6bIdYC5kJ7LfNkZOhfk/OTf3zR7L0HkcQpbYYpmjM5rahzEWlZ2s/Xo 4Q+4u2GnkaVp6H7HQUeakCfKlbMgcoNJSIvObUEdtPHhScFC0IfDT1ZWkT4x1YiPhNdG 8dDQ== X-Gm-Message-State: AAQBX9fM7akMvsQxl90QBUk618uRxSI/coZv2S8sANHtQUHaTmFqYo4K 6GGlgU5noRUnCg8X5q1X42mgt9pULU7TwFMhCO4rBx+F X-Google-Smtp-Source: AKy350byN/NFFbf8Ce68+Mq8FJvdtQR8F9/uNnS9DeG2rBGrPFtBZ0klCHE7yp5jNAjkHd49XGHGOIbbmCTaC8YCZlw= X-Received: by 2002:aca:ba56:0:b0:38b:2f3f:c613 with SMTP id k83-20020acaba56000000b0038b2f3fc613mr2040654oif.4.1681043824262; Sun, 09 Apr 2023 05:37:04 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:798d:0:b0:49c:b071:b1e3 with HTTP; Sun, 9 Apr 2023 05:37:03 -0700 (PDT) In-Reply-To: <20230409140023.47aab826@thor.intern.walstatt.dynvpn.de> References: <20230409140023.47aab826@thor.intern.walstatt.dynvpn.de> From: Mateusz Guzik Date: Sun, 9 Apr 2023 14:37:03 +0200 Message-ID: Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) To: FreeBSD User , Pawel Jakub Dawidek Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4PvWns46kKz3jZk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/9/23, FreeBSD User wrote: > Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: > Sun Apr 9 > 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > > zpool upgrade POOLNAME > > some boxes keep crashing when starting compiler runs (the trigger is > different on boxes). > > ZFS module is statically compiled into the kernel (if this is of > importance) > > Last known good was: > > [...] > Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > main-n262051-75379ea2e461: Sun Apr > 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 <0.2> > thor kernel: > FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git > llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: > VT(efifb): resolution > 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already > present! > [...] > > The file /var/crash/info.X > > contains: > > [...] > > root@thor:/var/crash # more info.2 > Dump header from device: /dev/gpt/swap > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1095192576 > Blocksize: 512 > Compression: none > Dumptime: 2023-04-09 11:43:41 +0000 > Hostname: thor.local > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun Apr > 9 12:01:02 CEST > 2023 > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > Dump Parity: 2961465682 > Bounds: 2 > Dump Status: good > > Until reconfigured for more debug stuff I do not have more to present. > > I rememeber now really scraed that there was a HEADSUP in the list regarding > some serious ZFS > problems - I didn't find it right now. > > Thanks in advance, > That's fallout from the new block cloning feature, adding the author -- Mateusz Guzik From nobody Sun Apr 9 14:14:09 2023 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 4PvYyW6Dkdz44WNY for ; Sun, 9 Apr 2023 14:14:43 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4PvYyW0yf9z3Kmk; Sun, 9 Apr 2023 14:14:42 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none 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 B3E221009513; Sun, 9 Apr 2023 16:14:39 +0200 (CEST) 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 D269310A32E6; Sun, 9 Apr 2023 16:14:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1681049677; 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=hv3q069X0uGLJR3idqpugN66zWHXvfEVtaN+rXap6Ic=; b=g5ptf3mYhmL3+oNOZwgisYZI6ysCJ5PpqqY4ZhUzGQf2qv+6U+qhws7A/BGmDzNLbx5Pdc cXkZBbEU1xvoGVVi9hXuGwcauU45xHz4mgzvEmmlbw8vNpDtqC8bJNsA2uQIN2PoTwmXjG VmHUOXrXcb/q+aDTOZFbfxbBPh86kyPqgBzQArOig4ebRV1/H5yUqqnKw+kkkAiOwDnSXV vmLJto1RwZN3HHBE7Lc5ThLCCNojuC+SqFo+g/SZugg6sZ0BwkU1d95SfVT+RDEv15ZRqg nNfEv27yhOLV1jnOsBYVrLluI+XmUMYimtTGDtvhWHwCEaERnzAba9uQ0U37Rw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-191-007-166.77.191.pool.telefonica.de [77.191.7.166]) (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) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 98E6210A32E3; Sun, 9 Apr 2023 16:14:37 +0200 (CEST) Date: Sun, 9 Apr 2023 16:14:09 +0200 From: FreeBSD User To: Mateusz Guzik Cc: Pawel Jakub Dawidek , FreeBSD CURRENT Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) Message-ID: <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20230409140023.47aab826@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: b839e1 X-Rspamd-UID: 1a8527 X-Rspamd-Queue-Id: 4PvYyW0yf9z3Kmk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Am Sun, 9 Apr 2023 14:37:03 +0200 Mateusz Guzik schrieb: > On 4/9/23, FreeBSD User wrote: > > Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: > > Sun Apr 9 > > 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > > > > zpool upgrade POOLNAME > > > > some boxes keep crashing when starting compiler runs (the trigger is > > different on boxes). > > > > ZFS module is statically compiled into the kernel (if this is of > > importance) > > > > Last known good was: > > > > [...] > > Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > > main-n262051-75379ea2e461: Sun Apr > > 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 <0.2> > > thor kernel: > > FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git > > llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: > > VT(efifb): resolution > > 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already > > present! > > [...] > > > > The file /var/crash/info.X > > > > contains: > > > > [...] > > > > root@thor:/var/crash # more info.2 > > Dump header from device: /dev/gpt/swap > > Architecture: amd64 > > Architecture Version: 2 > > Dump Length: 1095192576 > > Blocksize: 512 > > Compression: none > > Dumptime: 2023-04-09 11:43:41 +0000 > > Hostname: thor.local > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun Apr > > 9 12:01:02 CEST > > 2023 > > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > > > Dump Parity: 2961465682 > > Bounds: 2 > > Dump Status: good > > > > Until reconfigured for more debug stuff I do not have more to present. > > > > I rememeber now really scraed that there was a HEADSUP in the list regarding > > some serious ZFS > > problems - I didn't find it right now. > > > > Thanks in advance, > > > > That's fallout from the new block cloning feature, adding the author > Thanks. As of this moment, all systems with the newest kernel and the new ZFS option enabled, crash - the reason is mostly in different ZFS datasets. I guess there is no way back once this faulty option is enabled? Regards, oh -- O. Hartmann From nobody Mon Apr 10 23:40:05 2023 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 4PwQSZ5YYwz44xlw for ; Mon, 10 Apr 2023 23:40:14 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4PwQSY57hKz3ngx; Mon, 10 Apr 2023 23:40:13 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org; dmarc=pass (policy=none) header.from=catflap.org X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 33ANe7Z5000630; Tue, 11 Apr 2023 00:40:07 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 33ANe66j000558; Tue, 11 Apr 2023 00:40:06 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202304102340.33ANe66j000558@donotpassgo.dyslexicfish.net> Date: Tue, 11 Apr 2023 00:40:05 +0100 Organization: Dyslexic Fish To: freebsd-current@freebsd.org Cc: jamie@catflap.org, asomers@freebsd.org Subject: [FUSEFS] File close() failures relating to attempted atime update User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 11 Apr 2023 00:40:07 +0100 (BST) X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.78)[-0.780]; 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)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[jamie]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US] X-Rspamd-Queue-Id: 4PwQSY57hKz3ngx X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N There is a replicable problem with file closing on fusefs, since 0bade34633f997c22f5e4e0931df0d534f560a38, Alan Somers 2021-11-29 01:53:31 +0000 It appears to be related to attempting to update atime on a file you don't have write-access to. I've posted much more details, and a potential fix to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270749 Cheers, Jamie From nobody Mon Apr 10 23:44:35 2023 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 4PwQYr3ShKz44yBd for ; Mon, 10 Apr 2023 23:44:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 4PwQYr1ScTz3xY0 for ; Mon, 10 Apr 2023 23:44:48 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f54.google.com with SMTP id e20so5876622vsj.10 for ; Mon, 10 Apr 2023 16:44:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681170287; x=1683762287; 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=mgQXBMxtB/0pm/OJ1yxi/mHqY9ZeWiUJzFUu+it9EDc=; b=kWkowU7UR1RIncJbEOhskvrgEkGxwXCW6+YuPuFFp9/feYPDcoAKhkTrmHZ4Nd1UCU j8W7w4hs9TRANUYVdtGTN7Yy6ziJoVTKAUk+Pgci6iJvybjLrMHAZytQoicyw5HzFHki lFNV1JtvhR2sEF5xT33+kcOwQk8hof8J9MNFAA4WmZo/P7wpT4PuKgRIHPOjGmgZ6+BK 7tM4xLxbUtIZFb16hJi7rO41UCCWJKnuVwe6cVE3bog5gnGDA3cDMutMGYYyn3iiZD9D NoJasEOZ+fbEcGLgT8QCYSqaw7VlDWmdhNKQpWYJvBcanHFcHp1d6xedzqbg38CrlfJ/ 0J3g== X-Gm-Message-State: AAQBX9dhON83y4afGdmlqxZwenVJfBIYY1e8ieb/ONXjLgdCFTLAC9Ur w5nlMLo69JWYD1Eg0ENVj5jwXhTfMkuoPqzC0+AwuH/J X-Google-Smtp-Source: AKy350aXvGnsiDfZl4GWCjks1RXX+d3BPRd4R0AfPwysWSw5j9Sj3o9wgzwtwiiGIi35oy+P15ReT2ZxI0arMkut7Y8= X-Received: by 2002:a67:d496:0:b0:42c:6917:15bc with SMTP id g22-20020a67d496000000b0042c691715bcmr3184692vsj.4.1681170287035; Mon, 10 Apr 2023 16:44:47 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <202304102340.33ANe66j000558@donotpassgo.dyslexicfish.net> In-Reply-To: <202304102340.33ANe66j000558@donotpassgo.dyslexicfish.net> From: Alan Somers Date: Mon, 10 Apr 2023 16:44:35 -0700 Message-ID: Subject: Re: [FUSEFS] File close() failures relating to attempted atime update To: Jamie Landeg-Jones Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4PwQYr1ScTz3xY0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Thanks for the head's up. Hopefully I'll be able to look at it later this = week. On Mon, Apr 10, 2023 at 4:40=E2=80=AFPM Jamie Landeg-Jones wrote: > > There is a replicable problem with file closing on fusefs, since > 0bade34633f997c22f5e4e0931df0d534f560a38, Alan Somers 2021-11-29 01:53:31 +0000 > > It appears to be related to attempting to update atime on a file you > don't have write-access to. > > I've posted much more details, and a potential fix to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270749 > > Cheers, Jamie From nobody Tue Apr 11 00:14:09 2023 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 4PwRCq0bD8z450FR for ; Tue, 11 Apr 2023 00:14:15 +0000 (UTC) (envelope-from btv1==465cb2ae642==tom@invisible-island.net) Received: from smtp-1a.his.com (smtp-1a.his.com [216.194.196.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 4PwRCn4nD4z3Mw9 for ; Tue, 11 Apr 2023 00:14:13 +0000 (UTC) (envelope-from btv1==465cb2ae642==tom@invisible-island.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of "btv1==465cb2ae642==tom@invisible-island.net" designates 216.194.196.25 as permitted sender) smtp.mailfrom="btv1==465cb2ae642==tom@invisible-island.net"; dmarc=none Received: from cuda501.his.com (cuda501.his.com [18.191.10.220]) by smtp-1a.his.com (Postfix) with ESMTPS id AED549A for ; Mon, 10 Apr 2023 20:14:11 -0400 (EDT) X-ASG-Debug-ID: 1681172050-1f26af6bb92166c0001-XioQCd Received: from smtp-nf-202.his.com (smtp-nf-202.his.com [216.194.196.20]) by cuda501.his.com with ESMTP id CVNElw54dYLM8qB7; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) X-Barracuda-Envelope-From: tom@invisible-island.net X-Barracuda-RBL-Trusted-Forwarder: 216.194.196.20 Received: from zproxy101.his.com (zproxy101.his.com [18.218.2.49]) by smtp-nf-202.his.com (Postfix) with ESMTPS id 8BB5E609B6; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy101.his.com (Postfix) with ESMTP id 5063317B269; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) X-Barracuda-RBL-IP: 18.218.2.49 X-Barracuda-Effective-Source-IP: zproxy101.his.com[18.218.2.49] X-Barracuda-Apparent-Source-IP: 18.218.2.49 Received: from zproxy101.his.com ([127.0.0.1]) by localhost (zproxy101.his.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id w0y31Tj_FK91; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy101.his.com (Postfix) with ESMTP id 3801617B26C; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at zproxy101.his.com Received: from zproxy101.his.com ([127.0.0.1]) by localhost (zproxy101.his.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mHQKQlEoqOQX; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) Received: from prl-debianold-64.jexium-island.net (static-96-255-221-90.washdc.fios.verizon.net [96.255.221.90]) by zproxy101.his.com (Postfix) with ESMTPSA id 23C5117B26A; Mon, 10 Apr 2023 20:14:10 -0400 (EDT) Received: from tom by prl-debianold-64.jexium-island.net with local (Exim 4.94.2) (envelope-from ) id 1pm1eD-000ffE-D9; Mon, 10 Apr 2023 20:14:09 -0400 Date: Mon, 10 Apr 2023 20:14:09 -0400 From: Thomas Dickey To: Dan Mack Cc: current@freebsd.org Subject: Re: documentation nit / TERMINFO in ncurses man pages Message-ID: X-ASG-Orig-Subj: Re: documentation nit / TERMINFO in ncurses man pages Reply-To: dickey@his.com References: <7f3334ff-cdfa-0de-5640-8f9d519fce@macktronics.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VM4apnJeeT11lOcK" Content-Disposition: inline In-Reply-To: <7f3334ff-cdfa-0de-5640-8f9d519fce@macktronics.com> X-Barracuda-Connect: smtp-nf-202.his.com[216.194.196.20] X-Barracuda-Start-Time: 1681172050 X-Barracuda-URL: https://spam.his.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at his.com X-Barracuda-Scan-Msg-Size: 2110 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=5.0 KILL_LEVEL=7.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.107251 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Spamd-Result: default: False [-5.13 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.954]; NEURAL_HAM_MEDIUM(-0.78)[-0.778]; RCVD_IN_DNSWL_LOW(-0.30)[216.194.196.25:from,216.194.196.20:received,18.218.2.49:received]; FORGED_SENDER(0.30)[dickey@his.com,btv1==465cb2ae642==tom@invisible-island.net]; R_SPF_ALLOW(-0.20)[+ip4:216.194.196.0/22]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:11604, ipnet:216.194.196.0/24, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; HAS_REPLYTO(0.00)[dickey@his.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[his.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[dickey@his.com,btv1==465cb2ae642==tom@invisible-island.net]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_SEVEN(0.00)[10] X-Rspamd-Queue-Id: 4PwRCn4nD4z3Mw9 X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N --VM4apnJeeT11lOcK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 07, 2023 at 09:51:30AM -0500, Dan Mack wrote: >=20 > I recently logged into one of my FreeBSD systems from an alacritty termin= al. > FreeBSD didn't have a termcap entry for alacritty so I generated one with > tic and all was well. However, I noticed the following issues with the > TERM* related tools (I guess this is all from contrib/ncurses in /usr/src= ). >=20 > Specifically, the issue is for example - the tic(1M) man page says in the > FILES section: >=20 > /usr/share/misc/terminfo/?/* > Compiled terminal description database. The "misc" appears to come from lib/ncurses/config.mk, and (since the library holds the pathname) would be used in usr.bin/ncurses -- However, I don't see any of those programs installed in /usr/bin on an up-to-date FreeBSD machine. If you have tic, I'd expect it to be in the add-on package (in /usr/local/bin). > However, when you run tic(1M), the compiled terminal files are actually > placed in /usr/share/terminfo/?/* . I thought I could create a simple o= ne > line fix by re-defining the definition for *d in the manpage, however, it > looks like there there might be a need to create two separate directory > variables instead. The manpage shows only the default location for writing files. tic only has one of those (corresponding to $TERMINFO). Further in the manpage, it summarizes the places tic looks to read files (corresponding to $TERMINFO_DIRS). > On FreeBSD-Current HEAD (2d3614fb132b1cb8efd1e0accdd0c98ce6893efa) I am > seeing two directories in use: >=20 > /usr/share/terminfo/? - compiled entries created by tic(1M) > and > /usr/share/misc - contains the files termcap and termcap.db >=20 > Looks like this directory reference is set to *d here in the tic manpage: >=20 > 18259542b2f8f contrib/ncurses/man/tic.1m 2000-10-11 07:31:01 +0000 37) .= ds > d @TERMINFO@ >=20 > Since this is also set in alot of other places, we probably need someone = to > make some sort of decision :-) >=20 > Dan >=20 --=20 Thomas E. Dickey https://invisible-island.net --VM4apnJeeT11lOcK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmQ0pk0ACgkQzCr0RyFn vgPU3Av9H/oAHclL30ldBsbAqfFavcUaSMPjcxN4edzNpLzhM4XL7RBiNCLooDP1 tfEcHVKlVcbJRKMnnQ8NLt+rZOOc3UPwB7X3RN9uvpu5pgqazqCk05te29N2PsoT KVxRT7VGp9J9KfEPwsx2mLrWLZtBZLKrEfrFJ8ARFq7NUC13zPYbeTY5Ro2cZ+XM GYCWGh2rPZaiGHcsnFm/q0zH/O3fVbNunidk+RUew8cOLi/FXMjy9UhX5X19tuqX uvTS43u9FWqcBYfu7BQdRRKs5Ob7nAdN1IWhyxIZ9a6nqyX15nf4taVVXfELRcaf 46tfN3N1Ym0eLGrpSZPP6bPfg/rs56qSsdzw+ljf/hwSl8EgwW3/Ak5XDzC9fGn0 oI/tgGPW+5Io21B+fieFdANBnKSahr+dIH55WC3OK71pmeL3z+rFmYFuHCLO8Fqp 65hWx2pBcHYz/SbIW+ygRTas4Xz8b6ilX6fi/LuHHR0w9rc1rL1lqrjfqHS1dBRS 0o8tUskr =1V9E -----END PGP SIGNATURE----- --VM4apnJeeT11lOcK-- From nobody Tue Apr 11 02:19:18 2023 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 4PwVGT3zS7z457xn for ; Tue, 11 Apr 2023 02:31:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PwVGS2gCnz3qf0; Tue, 11 Apr 2023 02:31:44 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id lrzJp4h0Tjvm1m3bNp2KiG; Tue, 11 Apr 2023 02:19:21 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id m3bLpq9iqcyvum3bMpzUSz; Tue, 11 Apr 2023 02:19:21 +0000 X-Authority-Analysis: v=2.4 cv=VbHkgXl9 c=1 sm=1 tr=0 ts=6434c3a9 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=pGLkceISAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=BFMMW6rN7m6Y0xqU6JoA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 1A9B0E20; Mon, 10 Apr 2023 19:19:19 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 0718F306; Mon, 10 Apr 2023 19:19:18 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: FreeBSD User cc: Mateusz Guzik , Pawel Jakub Dawidek , FreeBSD CURRENT Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) In-reply-to: <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn.de> References: <20230409140023.47aab826@thor.intern.walstatt.dynvpn.de> <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn.de> Comments: In-reply-to FreeBSD User message dated "Sun, 09 Apr 2023 16:14:09 +0200." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Apr 2023 19:19:18 -0700 Message-Id: <20230411021919.0718F306@slippy.cwsent.com> X-CMAE-Envelope: MS4xfK+9V2L7/gwseeFLWiJNNCvEOtYVhrFqMD7AHhIXaIT0U4kQeVyiOh0OzYVGMWrmz6GWxbtBOhMuW8BPbESwE+W5TRlN+N+w1pdFEoQ3PqpDLyCf8HBe PLiXZxQ3aJySFbMa9feExDTOSifVcvOCB+3EiFgwPVY0t3iW+l3RUMCRSm9ZxqW7sX+BOBq7M6C0y1zS1BqFVvCqPukhxu0JEcecrkNz70btP3V1K9O3GMfJ n1vV7Ho7k/0y/3qnuY8aA2anKac836dB5sBA8WTiSVpH7G/gBvzrZ1varkuOnPl8 X-Spamd-Result: default: False [1.84 / 15.00]; R_BAD_CTE_7BIT(3.50)[7bit]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.97)[-0.965]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; REPLYTO_EQ_FROM(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; SUBJECT_HAS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; GREYLIST(0.00)[pass,body] X-Rspamd-Queue-Id: 4PwVGS2gCnz3qf0 X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N In message <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn.de>, FreeBSD Us er writes: > Am Sun, 9 Apr 2023 14:37:03 +0200 > Mateusz Guzik schrieb: > > > On 4/9/23, FreeBSD User wrote: > > > Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e301 > 2b: > > > Sun Apr 9 > > > 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > > > > > > zpool upgrade POOLNAME > > > > > > some boxes keep crashing when starting compiler runs (the trigger is > > > different on boxes). > > > > > > ZFS module is statically compiled into the kernel (if this is of > > > importance) > > > > > > Last known good was: > > > > > > [...] > > > Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > > > main-n262051-75379ea2e461: Sun Apr > > > 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > > > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 <0. > 2> > > > thor kernel: > > > FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git > > > llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: > > > VT(efifb): resolution > > > 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already > > > present! > > > [...] > > > > > > The file /var/crash/info.X > > > > > > contains: > > > > > > [...] > > > > > > root@thor:/var/crash # more info.2 > > > Dump header from device: /dev/gpt/swap > > > Architecture: amd64 > > > Architecture Version: 2 > > > Dump Length: 1095192576 > > > Blocksize: 512 > > > Compression: none > > > Dumptime: 2023-04-09 11:43:41 +0000 > > > Hostname: thor.local > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun > Apr > > > 9 12:01:02 CEST > > > 2023 > > > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > > > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > > > > > Dump Parity: 2961465682 > > > Bounds: 2 > > > Dump Status: good > > > > > > Until reconfigured for more debug stuff I do not have more to present. > > > > > > I rememeber now really scraed that there was a HEADSUP in the list regard > ing > > > some serious ZFS > > > problems - I didn't find it right now. > > > > > > Thanks in advance, > > > > > > > That's fallout from the new block cloning feature, adding the author > > > > Thanks. > > As of this moment, all systems with the newest kernel and the new ZFS option > enabled, crash - > the reason is mostly in different ZFS datasets. I guess there is no way back > once this faulty > option is enabled? I've run a test on a scratch pool here, first without block_cloning enabled, then with. There was no corruption when block_cloning was disabled. There was corruption when block_cloning was enabled. I don't know of any way to revert back nor is there any way to fix or recover the corrupted blocks. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Apr 11 14:28:31 2023 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 4Pwp9c5hQ9z44xY5 for ; Tue, 11 Apr 2023 14:28:36 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pwp9b0m2hz3N4C; Tue, 11 Apr 2023 14:28:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id luF4p4tRhjvm1mEz4p3Kh7; Tue, 11 Apr 2023 14:28:34 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mEz2pKvoi3fOSmEz3pZZMp; Tue, 11 Apr 2023 14:28:34 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64356e92 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=13WrDtVnAAAA:8 a=YxBL1-UpAAAA:8 a=pGLkceISAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=LXhWB4x9cL4UNslYIKQA:9 a=CjuIK1q_8ugA:10 a=qcMfyop8IQhGkljw9-nY:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 02CFF217C; Tue, 11 Apr 2023 07:28:32 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id DB8245FA; Tue, 11 Apr 2023 07:28:31 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: =?utf-8?Q?Pawe=C5=82_Jakub_Dawidek?= cc: Cy Schubert , FreeBSD User , Mateusz Guzik , Pawel Jakub Dawidek , FreeBSD CURRENT Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) In-reply-to: <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net> References: <20230411021919.0718F306@slippy.cwsent.com> <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net> Comments: In-reply-to =?utf-8?Q?Pawe=C5=82_Jakub_Dawidek?= message dated "Tue, 11 Apr 2023 18:04:10 +0900." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2023 07:28:31 -0700 Message-Id: <20230411142831.DB8245FA@slippy.cwsent.com> X-CMAE-Envelope: MS4xfH1AfEeyYGCk9zM3ol1N4eoabHaj0sIAhvf/PewxWBKwPBjisyK8a4j3lFA/58qh6dZ4PfBH4EuVrIPJkjRXzzjWm/KSv/nYdmIWwL69fhztLDpHDHAQ oLlEBfQ5bmO41E+Mz4iaSy9ScvhouXvPcE1hbWkYAtJ5+NyjRbbpF/UOvnlDmXwsk7uXWOmfbK2Q25pN1jKbrKeOWIhzCcEZflqNiyec8GPxQ+87sZHxbI+z we47d3shK+hUdFIuvoExcoOhZq/7qPM9c3ZH9BLbIn58Lu0j6bWxIM7dM6pNXaNlA3kSPFYw38tIywXVLsZH5K6viLgw6zHNkOLQoRYGoEE= X-Spamd-Result: default: False [2.36 / 15.00]; R_BAD_CTE_7BIT(3.50)[7bit]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.34)[-0.339]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[70.66.148.124:server fail]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_CC(0.00)[cschubert.com,walstatt-de.de,gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; GREYLIST(0.00)[pass,meta] X-Rspamd-Queue-Id: 4Pwp9b0m2hz3N4C X-Spamd-Bar: ++ X-ThisMailContainsUnwantedMimeParts: N In message <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net>, =?utf-8?Q?Pawe=C 5=82_Jakub_Dawidek?= writes: > > > > On Apr 11, 2023, at 11:31, Cy Schubert wrote: > >=20 > > =EF=BB=BFIn message <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn.d= > e>,=20 > > FreeBSD Us > > er writes: > >> Am Sun, 9 Apr 2023 14:37:03 +0200 > >> Mateusz Guzik schrieb: > >>=20 > >>>> On 4/9/23, FreeBSD User wrote: > >>>>> Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e= > 301 > >>> 2b: > >>>>> Sun Apr 9 > >>>>> 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > >>>>>=20 > >>>>> zpool upgrade POOLNAME > >>>>>=20 > >>>>> some boxes keep crashing when starting compiler runs (the trigger is > >>>>> different on boxes). > >>>>>=20 > >>>>> ZFS module is statically compiled into the kernel (if this is of > >>>>> importance) > >>>>>=20 > >>>>> Last known good was: > >>>>>=20 > >>>>> [...] > >>>>> Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > >>>>> main-n262051-75379ea2e461: Sun Apr > >>>>> 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 < > = > 0. > >>> 2> > >>>>> thor kernel: > >>>>> FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git= > > >>>>> llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: > >>>>> VT(efifb): resolution > >>>>> 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already > >>>>> present! > >>>>> [...] > >>>>>=20 > >>>>> The file /var/crash/info.X > >>>>>=20 > >>>>> contains: > >>>>>=20 > >>>>> [...] > >>>>>=20 > >>>>> root@thor:/var/crash # more info.2 > >>>>> Dump header from device: /dev/gpt/swap > >>>>> Architecture: amd64 > >>>>> Architecture Version: 2 > >>>>> Dump Length: 1095192576 > >>>>> Blocksize: 512 > >>>>> Compression: none > >>>>> Dumptime: 2023-04-09 11:43:41 +0000 > >>>>> Hostname: thor.local > >>>>> Magic: FreeBSD Kernel Dump > >>>>> Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Su= > n=20 > >>> Apr > >>>>> 9 12:01:02 CEST > >>>>> 2023 > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > >>>>> Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > >>>>>=20 > >>>>> Dump Parity: 2961465682 > >>>>> Bounds: 2 > >>>>> Dump Status: good > >>>>>=20 > >>>>> Until reconfigured for more debug stuff I do not have more to present.= > > >>>>>=20 > >>>>> I rememeber now really scraed that there was a HEADSUP in the list reg= > ard > >>> ing > >>>>> some serious ZFS > >>>>> problems - I didn't find it right now. > >>>>>=20 > >>>>> Thanks in advance, > >>>>>=20 > >>>=20 > >>> That's fallout from the new block cloning feature, adding the author > >>>=20 > >>=20 > >> Thanks. > >>=20 > >> As of this moment, all systems with the newest kernel and the new ZFS opt= > ion=20 > >> enabled, crash - > >> the reason is mostly in different ZFS datasets. I guess there is no way b > = > ack > >> once this faulty > >> option is enabled? > >=20 > > I've run a test on a scratch pool here, first without block_cloning=20 > > enabled, then with. There was no corruption when block_cloning was=20 > > disabled. There was corruption when block_cloning was enabled. > >=20 > > I don't know of any way to revert back nor is there any way to fix or=20 > > recover the corrupted blocks. > > Is the corruption still present after EXDEV fixes? Yes and no. Yes, there is corruption when block_cloning is enabled. There is no corruption when block_cloning is disabled. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue Apr 11 14:47:13 2023 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 4Pwpb92ggdz44yT4 for ; Tue, 11 Apr 2023 14:47:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pwpb82BpRz4DJM; Tue, 11 Apr 2023 14:47:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id mEGfp0dQruZMSmFH9pHdSv; Tue, 11 Apr 2023 14:47:15 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mFH8pL1Xm3fOSmFH8pZc38; Tue, 11 Apr 2023 14:47:15 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=643572f3 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=VxmjJ2MpAAAA:8 a=13WrDtVnAAAA:8 a=YxBL1-UpAAAA:8 a=pGLkceISAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=CK1mnscjJpQ-eMPXql0A:9 a=CjuIK1q_8ugA:10 a=u_YB59FJ7C0A:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=qcMfyop8IQhGkljw9-nY:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id BCE602221; Tue, 11 Apr 2023 07:47:13 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id A94EA5FE; Tue, 11 Apr 2023 07:47:13 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: =?utf-8?Q?Pawe=C5=82_Jakub_Dawidek?= cc: FreeBSD User , Mateusz Guzik , Pawel Jakub Dawidek , FreeBSD CURRENT Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) In-reply-to: <20230411142831.DB8245FA@slippy.cwsent.com> References: <20230411021919.0718F306@slippy.cwsent.com> <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net> <20230411142831.DB8245FA@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Tue, 11 Apr 2023 07:28:31 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2023 07:47:13 -0700 Message-Id: <20230411144713.A94EA5FE@slippy.cwsent.com> X-CMAE-Envelope: MS4xfDR6UyYzPqzCrOv6cRcUfOXbjwEX3WB3EEkpQyvyBbcBpB6TANgLkB+eXS2DGP14yQik0+vYnrTlKhAdT9gaaTkf7uIpW47105AsSDc68ilp2uNR/y2I T45Pb1L6/jbHIaDexkQxLPJOPi35C0tbePrH1uguePMc7VBG8BSYDro5bMXvWD6iQO0Gd5jlZShgBWMC7RA38pJFcnexzlB5z+unARnWEZ5UVuxPZD9PwSTM V0e00sUQsNWIK3wAqJRXjZiYUMF63BGCpjWrxP0m42FZxn99Y6WbE/dOxHCz6TM2bsHyeX1B9j7UGZWvyvG5DcIOS6qagtWWFhlz2VfE0+A= X-Spamd-Result: default: False [2.11 / 15.00]; R_BAD_CTE_7BIT(3.50)[7bit]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.69)[-0.689]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[3.97.99.32:from]; REPLYTO_EQ_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_CC(0.00)[walstatt-de.de,gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; GREYLIST(0.00)[pass,meta] X-Rspamd-Queue-Id: 4Pwpb82BpRz4DJM X-Spamd-Bar: ++ X-ThisMailContainsUnwantedMimeParts: N In message <20230411142831.DB8245FA@slippy.cwsent.com>, Cy Schubert writes: > In message <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net>, > =?utf-8?Q?Pawe=C > 5=82_Jakub_Dawidek?= writes: > > > > > > > On Apr 11, 2023, at 11:31, Cy Schubert wrote: > > >=20 > > > =EF=BB=BFIn message <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn. > d= > > e>,=20 > > > FreeBSD Us > > > er writes: > > >> Am Sun, 9 Apr 2023 14:37:03 +0200 > > >> Mateusz Guzik schrieb: > > >>=20 > > >>>> On 4/9/23, FreeBSD User wrote: > > >>>>> Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038 > e= > > 301 > > >>> 2b: > > >>>>> Sun Apr 9 > > >>>>> 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > > >>>>>=20 > > >>>>> zpool upgrade POOLNAME > > >>>>>=20 > > >>>>> some boxes keep crashing when starting compiler runs (the trigger is > > >>>>> different on boxes). > > >>>>>=20 > > >>>>> ZFS module is statically compiled into the kernel (if this is of > > >>>>> importance) > > >>>>>=20 > > >>>>> Last known good was: > > >>>>>=20 > > >>>>> [...] > > >>>>> Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > > >>>>> main-n262051-75379ea2e461: Sun Apr > > >>>>> 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 > < > > = > > 0. > > >>> 2> > > >>>>> thor kernel: > > >>>>> FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.gi > t= > > > > >>>>> llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: > > >>>>> VT(efifb): resolution > > >>>>> 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already > > >>>>> present! > > >>>>> [...] > > >>>>>=20 > > >>>>> The file /var/crash/info.X > > >>>>>=20 > > >>>>> contains: > > >>>>>=20 > > >>>>> [...] > > >>>>>=20 > > >>>>> root@thor:/var/crash # more info.2 > > >>>>> Dump header from device: /dev/gpt/swap > > >>>>> Architecture: amd64 > > >>>>> Architecture Version: 2 > > >>>>> Dump Length: 1095192576 > > >>>>> Blocksize: 512 > > >>>>> Compression: none > > >>>>> Dumptime: 2023-04-09 11:43:41 +0000 > > >>>>> Hostname: thor.local > > >>>>> Magic: FreeBSD Kernel Dump > > >>>>> Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: S > u= > > n=20 > > >>> Apr > > >>>>> 9 12:01:02 CEST > > >>>>> 2023 > > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > > >>>>> Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > >>>>>=20 > > >>>>> Dump Parity: 2961465682 > > >>>>> Bounds: 2 > > >>>>> Dump Status: good > > >>>>>=20 > > >>>>> Until reconfigured for more debug stuff I do not have more to present > .= > > > > >>>>>=20 > > >>>>> I rememeber now really scraed that there was a HEADSUP in the list re > g= > > ard > > >>> ing > > >>>>> some serious ZFS > > >>>>> problems - I didn't find it right now. > > >>>>>=20 > > >>>>> Thanks in advance, > > >>>>>=20 > > >>>=20 > > >>> That's fallout from the new block cloning feature, adding the author > > >>>=20 > > >>=20 > > >> Thanks. > > >>=20 > > >> As of this moment, all systems with the newest kernel and the new ZFS op > t= > > ion=20 > > >> enabled, crash - > > >> the reason is mostly in different ZFS datasets. I guess there is no way > b > > = > > ack > > >> once this faulty > > >> option is enabled? > > >=20 > > > I've run a test on a scratch pool here, first without block_cloning=20 > > > enabled, then with. There was no corruption when block_cloning was=20 > > > disabled. There was corruption when block_cloning was enabled. > > >=20 > > > I don't know of any way to revert back nor is there any way to fix or=20 > > > recover the corrupted blocks. > > > > Is the corruption still present after EXDEV fixes? > > Yes and no. > > Yes, there is corruption when block_cloning is enabled. > > There is no corruption when block_cloning is disabled. I should add some detail to this. The corruption experienced when block cloning is disabled was fixed by: - eb1feadc201a - e2d997d1cbb9 - d012836fb616 (specifically this commit) - 20be1b4fc4b7 When block_cloning is enabled, the pool is corrupted. This has not been fixed. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed Apr 12 12:57:02 2023 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 4PxN5l3K2vz44k5v for ; Wed, 12 Apr 2023 12:57:15 +0000 (UTC) (envelope-from eduardo@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 4PxN5k72dqz3vfd; Wed, 12 Apr 2023 12:57:14 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681304235; 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=fQRpNhVEKa5FXReYdtD1lpsBCTNLagLpqMHCrmJKMhs=; b=hbxCzT3u8seEboHvcwHsDpKMJyZ/CUbRhelstFC8OCHw+lGArYdjAiClHQF23IBuFiIVjp bTMi4PuK7yfviJekqxrktdO4qdE4pp8GQ+xmIJTfmdlcLp/rqaCTMX3bSWbxGoJaKr5fSR 9pLl1f4/mi7GAIX8vdCfPjwvEKLzlPPqmK2GFiDvTsA4psQliV2opRaPhxBldIg6EoJd1F aMC3K3JRTnV+Mcpgvw8/7QJIgiHMSyzUHtXHzsIbuJ6pPgL19HTAWpPELoAVoPPThEpS5f rCjX+ze0h/lTVGscyUn+D0+P/WEHMdBxFfHNh8U6WTMr3trOuscWv2HN0Mezuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681304235; 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=fQRpNhVEKa5FXReYdtD1lpsBCTNLagLpqMHCrmJKMhs=; b=qW//CqG4U/lCyMsChYOwJ+X7e19ldrE5orraBysWZVfY3kTUtwLclUrA+LlEHPFPOYyDta kS93kYwP3MttBN03o4Mig6+rwFEWY0hbo88C7nfh5NfYxRyTXyzMjCatzxXwA2NB9C0PT/ 0BtrFTa02e6GIq2EhF2OeGUlC5VXmKKaPfOm6hyYo0+x9G40IoC7cq3QdLPvJYjUzR+B/P lAXG9N+ohKhiNVqeg3xw+vSWhv4+AT07fw5RT7dELS8UBmvTioAu0euYY6dpDW4t2HDqF7 mmVngu0m8r6nfGuF+qvXSeE6B4AYskUtGPe0wzStZANrP38L2ntkWAE/AMjCFg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681304235; a=rsa-sha256; cv=none; b=BUD9iwXw5v2ma+hq/zU3cs+w+kijIgXF7tvQ7avQs+nBB6RcrA5r/s9z4rXrSIu0KGlzOJ cQ+n6oMrs0URZFAeTHWj+2XOm57ozrCLVr6+gzLEDgC9NpdXmHmboiDGiAE09H7lsRpDCZ +Bh6Vl/wNVK8oO68dalaOKC5zRYGVn2WPahSlvcISZXv7QBcuPKE+QemiHsrL7OF8nOA4b 6GNDI4tO3KaGUIEAZ5OEUNxkiRCM/kghqrTG9GMMUQYsgsWvgV5ehiObWPC1XwK3TtXvPV zfc1WDyNEpV7/cLDDcZl8Uswws5loM69fla56si08SSquyFGLWrgEpg3bVMWTA== Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PxN5k65BCz1R9d; Wed, 12 Apr 2023 12:57:14 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-ua1-f50.google.com with SMTP id x26so772708uav.3; Wed, 12 Apr 2023 05:57:14 -0700 (PDT) X-Gm-Message-State: AAQBX9cGT4Fxzt5nQ1VZNoinoKR1P/pNUJlPirclTG76HgiZxUjopkCr rpqcaSho9mL06GmUIyGQOYgf9PSbDOUH9TZFbgk= X-Google-Smtp-Source: AKy350YTIXNzTN+x/JVmEk7oNqKzhy8Uids/EHl3NLHTjseMsvZTISrhtEMtxkCakBfc8SpqeGxAp7yZjwY6Oc7gJLw= X-Received: by 2002:ab0:5549:0:b0:68a:7224:2034 with SMTP id u9-20020ab05549000000b0068a72242034mr10478942uaa.0.1681304234348; Wed, 12 Apr 2023 05:57:14 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20230411021919.0718F306@slippy.cwsent.com> <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net> <20230411142831.DB8245FA@slippy.cwsent.com> <20230411144713.A94EA5FE@slippy.cwsent.com> In-Reply-To: <20230411144713.A94EA5FE@slippy.cwsent.com> From: Nuno Teixeira Date: Wed, 12 Apr 2023 13:57:02 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) To: Cy Schubert Cc: =?UTF-8?Q?Pawe=C5=82_Jakub_Dawidek?= , FreeBSD User , Mateusz Guzik , Pawel Jakub Dawidek , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000a5d6f005f92325c6" X-ThisMailContainsUnwantedMimeParts: N --000000000000a5d6f005f92325c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, at current 3fdb40d1befe after `zfs upgrade XXX`: same problem when running compiler: - poudriere: crash without dump - make buildworld (/usr/src): shutdown -p (I will try to get a photo) Is there a way to disable block clone? Cy Schubert escreveu no dia ter=C3=A7a, 11/04/2= 023 =C3=A0(s) 15:47: > In message <20230411142831.DB8245FA@slippy.cwsent.com>, Cy Schubert > writes: > > In message <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net>, > > =3D?utf-8?Q?Pawe=3DC > > 5=3D82_Jakub_Dawidek?=3D writes: > > > > > > > > > > On Apr 11, 2023, at 11:31, Cy Schubert > wrote: > > > >=3D20 > > > > =3DEF=3DBB=3DBFIn message > <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn. > > d=3D > > > e>,=3D20 > > > > FreeBSD Us > > > > er writes: > > > >> Am Sun, 9 Apr 2023 14:37:03 +0200 > > > >> Mateusz Guzik schrieb: > > > >>=3D20 > > > >>>> On 4/9/23, FreeBSD User wrote: > > > >>>>> Today, after upgrading to FreeBSD 14.0-CURRENT #8 > main-n262052-0d4038 > > e=3D > > > 301 > > > >>> 2b: > > > >>>>> Sun Apr 9 > > > >>>>> 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > > > >>>>>=3D20 > > > >>>>> zpool upgrade POOLNAME > > > >>>>>=3D20 > > > >>>>> some boxes keep crashing when starting compiler runs (the > trigger is > > > >>>>> different on boxes). > > > >>>>>=3D20 > > > >>>>> ZFS module is statically compiled into the kernel (if this is o= f > > > >>>>> importance) > > > >>>>>=3D20 > > > >>>>> Last known good was: > > > >>>>>=3D20 > > > >>>>> [...] > > > >>>>> Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > > > >>>>> main-n262051-75379ea2e461: Sun Apr > > > >>>>> 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > > > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 > 07:10:04 > > < > > > =3D > > > 0. > > > >>> 2> > > > >>>>> thor kernel: > > > >>>>> FreeBSD clang version 15.0.7 ( > https://github.com/llvm/llvm-project.gi > > t=3D > > > > > > >>>>> llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor > kernel: > > > >>>>> VT(efifb): resolution > > > >>>>> 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl > already > > > >>>>> present! > > > >>>>> [...] > > > >>>>>=3D20 > > > >>>>> The file /var/crash/info.X > > > >>>>>=3D20 > > > >>>>> contains: > > > >>>>>=3D20 > > > >>>>> [...] > > > >>>>>=3D20 > > > >>>>> root@thor:/var/crash # more info.2 > > > >>>>> Dump header from device: /dev/gpt/swap > > > >>>>> Architecture: amd64 > > > >>>>> Architecture Version: 2 > > > >>>>> Dump Length: 1095192576 > > > >>>>> Blocksize: 512 > > > >>>>> Compression: none > > > >>>>> Dumptime: 2023-04-09 11:43:41 +0000 > > > >>>>> Hostname: thor.local > > > >>>>> Magic: FreeBSD Kernel Dump > > > >>>>> Version String: FreeBSD 14.0-CURRENT #8 > main-n262052-0d4038e3012b: S > > u=3D > > > n=3D20 > > > >>> Apr > > > >>>>> 9 12:01:02 CEST > > > >>>>> 2023 > > > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > > > >>>>> Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > > >>>>>=3D20 > > > >>>>> Dump Parity: 2961465682 > > > >>>>> Bounds: 2 > > > >>>>> Dump Status: good > > > >>>>>=3D20 > > > >>>>> Until reconfigured for more debug stuff I do not have more to > present > > .=3D > > > > > > >>>>>=3D20 > > > >>>>> I rememeber now really scraed that there was a HEADSUP in the > list re > > g=3D > > > ard > > > >>> ing > > > >>>>> some serious ZFS > > > >>>>> problems - I didn't find it right now. > > > >>>>>=3D20 > > > >>>>> Thanks in advance, > > > >>>>>=3D20 > > > >>>=3D20 > > > >>> That's fallout from the new block cloning feature, adding the > author > > > >>>=3D20 > > > >>=3D20 > > > >> Thanks. > > > >>=3D20 > > > >> As of this moment, all systems with the newest kernel and the new > ZFS op > > t=3D > > > ion=3D20 > > > >> enabled, crash - > > > >> the reason is mostly in different ZFS datasets. I guess there is > no way > > b > > > =3D > > > ack > > > >> once this faulty > > > >> option is enabled? > > > >=3D20 > > > > I've run a test on a scratch pool here, first without > block_cloning=3D20 > > > > enabled, then with. There was no corruption when block_cloning was= =3D20 > > > > disabled. There was corruption when block_cloning was enabled. > > > >=3D20 > > > > I don't know of any way to revert back nor is there any way to fix > or=3D20 > > > > recover the corrupted blocks. > > > > > > Is the corruption still present after EXDEV fixes? > > > > Yes and no. > > > > Yes, there is corruption when block_cloning is enabled. > > > > There is no corruption when block_cloning is disabled. > > I should add some detail to this. > > The corruption experienced when block cloning is disabled was fixed by: > > - eb1feadc201a > - e2d997d1cbb9 > - d012836fb616 (specifically this commit) > - 20be1b4fc4b7 > > When block_cloning is enabled, the pool is corrupted. This has not been > fixed. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000a5d6f005f92325c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

at current 3fdb40= d1befe after `zfs upgrade XXX`:

same problem w= hen running compiler:

- poudriere: crash without d= ump
- make buildworld (/usr/src): shutdown -p (I will try to get = a photo)

Is there a way to disable block clone?

Cy Schubert <Cy.Schu= bert@cschubert.com> escreveu no dia ter=C3=A7a, 11/04/2023 =C3=A0(s)= 15:47:
In messa= ge <20230411142831.DB8245FA@slippy.cwsent.com>, Cy Schubert = writes:
> In message <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek= .net>,
> =3D?utf-8?Q?Pawe=3DC
> 5=3D82_Jakub_Dawidek?=3D writes:
> >
> >
> > > On Apr 11, 2023, at 11:31, Cy Schubert <Cy.Schubert@cschubert.com= > wrote:
> > >=3D20
> > > =3DEF=3DBB=3DBFIn message <20230409161436.5412fa6e@thor.i= ntern.walstatt.dynvpn.
> d=3D
> > e>,=3D20
> > > FreeBSD Us
> > > er writes:
> > >> Am Sun, 9 Apr 2023 14:37:03 +0200
> > >> Mateusz Guzik <mjguzik@gmail.com> schrieb:
> > >>=3D20
> > >>>> On 4/9/23, FreeBSD User <freebsd@walstatt-de.de> wrot= e:
> > >>>>> Today, after upgrading to FreeBSD 14.0-CURRE= NT #8 main-n262052-0d4038
> e=3D
> > 301
> > >>> 2b:
> > >>>>> Sun Apr=C2=A0 9
> > >>>>> 12:01:02 CEST 2023=C2=A0 amd64, AND upgradin= g ZPOOLs via
> > >>>>>=3D20
> > >>>>> zpool upgrade POOLNAME
> > >>>>>=3D20
> > >>>>> some boxes keep crashing when starting compi= ler runs (the trigger is
> > >>>>> different on boxes).
> > >>>>>=3D20
> > >>>>> ZFS module is statically compiled into the k= ernel (if this is of
> > >>>>> importance)
> > >>>>>=3D20
> > >>>>> Last known good was:
> > >>>>>=3D20
> > >>>>> [...]
> > >>>>> Apr=C2=A0 9 07:10:04 <0.2> thor kernel= : FreeBSD 14.0-CURRENT #7
> > >>>>> main-n262051-75379ea2e461: Sun Apr
> > >>>>> 9 00:12:57 CEST 2023 Apr=C2=A0 9 07:10:04 &l= t;0.2> thor kernel:
> > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/T= HOR amd64 Apr=C2=A0 9 07:10:04
>=C2=A0 <
> > =3D
> > 0.
> > >>> 2>
> > >>>>> thor kernel:
> > >>>>> FreeBSD clang version 15.0.7 (= https://github.com/llvm/llvm-project.gi
> t=3D
> >
> > >>>>> llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr=C2=A0 9 = 07:10:04 <0.2> thor kernel:
> > >>>>> VT(efifb): resolution
> > >>>>> 2560x1440 Apr=C2=A0 9 07:10:04 <0.2> t= hor kernel: module zfsctrl already
> > >>>>> present!
> > >>>>> [...]
> > >>>>>=3D20
> > >>>>> The file /var/crash/info.X
> > >>>>>=3D20
> > >>>>> contains:
> > >>>>>=3D20
> > >>>>> [...]
> > >>>>>=3D20
> > >>>>> root@thor:/var/crash # more info.2
> > >>>>> Dump header from device: /dev/gpt/swap
> > >>>>>=C2=A0 Architecture: amd64
> > >>>>>=C2=A0 Architecture Version: 2
> > >>>>>=C2=A0 Dump Length: 1095192576
> > >>>>>=C2=A0 Blocksize: 512
> > >>>>>=C2=A0 Compression: none
> > >>>>>=C2=A0 Dumptime: 2023-04-09 11:43:41 +0000 > > >>>>>=C2=A0 Hostname: thor.local
> > >>>>>=C2=A0 Magic: FreeBSD Kernel Dump
> > >>>>>=C2=A0 Version String: FreeBSD 14.0-CURRENT #= 8 main-n262052-0d4038e3012b: S
> u=3D
> > n=3D20
> > >>> Apr
> > >>>>> 9 12:01:02 CEST
> > >>>>> 2023
> > >>>>>=C2=A0 =C2=A0 root@thor:/usr/obj/usr/src/amd6= 4.amd64/sys/THOR
> > >>>>>=C2=A0 Panic String: VERIFY(!zil_replaying(zi= log, tx)) failed
> > >>>>>=3D20
> > >>>>>=C2=A0 Dump Parity: 2961465682
> > >>>>>=C2=A0 Bounds: 2
> > >>>>>=C2=A0 Dump Status: good
> > >>>>>=3D20
> > >>>>> Until reconfigured for more debug stuff I do= not have more to present
> .=3D
> >
> > >>>>>=3D20
> > >>>>> I rememeber now really scraed that there was= a HEADSUP in the list re
> g=3D
> > ard
> > >>> ing
> > >>>>> some serious ZFS
> > >>>>> problems - I didn't find it right now. > > >>>>>=3D20
> > >>>>> Thanks in advance,
> > >>>>>=3D20
> > >>>=3D20
> > >>> That's fallout from the new block cloning featur= e, adding the author
> > >>>=3D20
> > >>=3D20
> > >> Thanks.
> > >>=3D20
> > >> As of this moment, all systems with the newest kernel an= d the new ZFS op
> t=3D
> > ion=3D20
> > >> enabled, crash -
> > >> the reason is mostly in=C2=A0 different ZFS datasets. I = guess there is no way
>=C2=A0 b
> > =3D
> > ack
> > >> once this faulty
> > >> option is enabled?
> > >=3D20
> > > I've run a test on a scratch pool here, first without bl= ock_cloning=3D20
> > > enabled, then with. There was no corruption when block_cloni= ng was=3D20
> > > disabled. There was corruption when block_cloning was enable= d.
> > >=3D20
> > > I don't know of any way to revert back nor is there any = way to fix or=3D20
> > > recover the corrupted blocks.
> >
> > Is the corruption still present after EXDEV fixes?
>
> Yes and no.
>
> Yes, there is corruption when block_cloning is enabled.
>
> There is no corruption when block_cloning is disabled.

I should add some detail to this.

The corruption experienced when block cloning is disabled was fixed by:

- eb1feadc201a
- e2d997d1cbb9
- d012836fb616 (specifically this commit)
- 20be1b4fc4b7

When block_cloning is enabled, the pool is corrupted. This has not been fixed.


--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeB= SD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2=A0 Web:=C2=A0 https://nwt= ime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0





--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000a5d6f005f92325c6-- From nobody Wed Apr 12 13:16:07 2023 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 4PxNWm5JYrz44lFq for ; Wed, 12 Apr 2023 13:16:20 +0000 (UTC) (envelope-from eduardo@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 4PxNWm1x6lz4JPN; Wed, 12 Apr 2023 13:16:20 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681305380; 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=jNWkNy575vt6sIkSkNLjkY1jU4qox3NeeGnLNQSik7g=; b=uectMiZqtT66oi6XXJCSOU8LEmEk+TRJw9qZ/owg/gX9Ov1gr5SUQdKT7Tr5wiHF6Gxza/ Y18AnIbPlsiH3OJ7sUStaJ9ksmfZ0BzF7gH1MTScR/ZHGRnpMAXNw4kZoVYZ/sGRd+QyhA fFak7BQqXrucjhlvYOwkhpvJgj2xbsR+8g0/wrL+bOfph4MZY7SnjQq1jBLHbT1f6e7Xee RnTGLDrxEb3xaBWOQXgx0jirD2i8ImqsF6HZhS1GSCOhgeDohl2c4fPZPTUzF4yEkJbp5p a/9uANsfnG+C1pOfCjR5nYkk8DP7Xa5ON4d12/Yj1YlDKsr7KLkWzKDIBW8Dvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681305380; 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=jNWkNy575vt6sIkSkNLjkY1jU4qox3NeeGnLNQSik7g=; b=MtMrQKX7evo7M5oiSYHm31ZfYcz57sLp4CsB4NZszY9O3zbamKQouCRCPKqeZhB9x/CRuq VZiQtnLxRSQkVKEikEVpHf8Ni8/tfaA9NTaRwfPAv7poBMA8EQf3iuDGg5yUlxv0bRrL9i vfCQIKSUlWvTX9fYNE/PzsAHPIJBtH+4FMnp7L28IH1727kxuY1Y6WEdTnTIg1PuaTAygI JbKtsNST5pD8k78gxZFfVoL+CnaTumEIBVEGdnXEi9PLhea9UJ7RYUjg5xwhiEPE4aOtdB QpXKKxUM0TGEJfodkv06ZBV3/wjOTWYODYFvcFgcdIA0Swk2o/kKVqKaYO9+oA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681305380; a=rsa-sha256; cv=none; b=RGfZ5ORzCvH315WW8nygJH0G4fN53kQaXErtB8K4sbtP59+QbDJJ6xQzLKt7ZjK4dTImB3 42v5+lU4RCDkKcgGf8DVCVjBNVNB7UHvW2Cc/1U4iYcaLdccs1Hu47BTUx8l5rWfwmjde1 wvBSKVJ1bC/O8Kn7oUzPrFE2WTJNIjIFftKYgdijmoww35mNJ+iGwuZHtwqV7r2N+8Z0vU a9u2LUmaZxhJqwfptucDiMnorwXJSSqkxZL3VJ+ifx0yHokcujiZ1+fxBJjH+mgSIj25cF njAwB0C80xhGC9e7JWNT1hcSGdMMji92bve7CPLqUab/snhZMQJwkeNjV3o3pQ== Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PxNWm0gbKz1S2f; Wed, 12 Apr 2023 13:16:20 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-vs1-f53.google.com with SMTP id v10so10328422vsf.6; Wed, 12 Apr 2023 06:16:20 -0700 (PDT) X-Gm-Message-State: AAQBX9cHKPr+yqSvDv3gZNcLeI4CkyQ+BBnWnzIG0wx8Mex6H1gZouv0 2G/FlN2Ogsw+phWnh47lMLvr5jdUsxzkAz0gsAY= X-Google-Smtp-Source: AKy350b/dynGJAPqI0FhXB/SzkU+SVyrYoRrJ3XpBqUTMPDs4TE7Vu2f26H09Q/zsjuVbyAKCX4hyHVnnc0tRAeoYuM= X-Received: by 2002:a67:d891:0:b0:42c:4297:81b0 with SMTP id f17-20020a67d891000000b0042c429781b0mr4114727vsj.7.1681305379537; Wed, 12 Apr 2023 06:16:19 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20230411021919.0718F306@slippy.cwsent.com> <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net> <20230411142831.DB8245FA@slippy.cwsent.com> <20230411144713.A94EA5FE@slippy.cwsent.com> In-Reply-To: From: Nuno Teixeira Date: Wed, 12 Apr 2023 14:16:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing) To: Cy Schubert Cc: =?UTF-8?Q?Pawe=C5=82_Jakub_Dawidek?= , FreeBSD User , Mateusz Guzik , Pawel Jakub Dawidek , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000e80a0f05f9236911" X-ThisMailContainsUnwantedMimeParts: N --000000000000e80a0f05f9236911 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Trying : `zpool set feature@block_cloning=3Ddisabled zroot`: cannot set property for 'zroot': property 'feature@block_cloning' can only be set to 'disabled' at creation time Nuno Teixeira escreveu no dia quarta, 12/04/2023 =C3= =A0(s) 13:57: > Hello all, > > at current 3fdb40d1befe after `zfs upgrade XXX`: > > same problem when running compiler: > > - poudriere: crash without dump > - make buildworld (/usr/src): shutdown -p (I will try to get a photo) > > Is there a way to disable block clone? > > Cy Schubert escreveu no dia ter=C3=A7a, 11/04= /2023 > =C3=A0(s) 15:47: > >> In message <20230411142831.DB8245FA@slippy.cwsent.com>, Cy Schubert >> writes: >> > In message <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek.net>, >> > =3D?utf-8?Q?Pawe=3DC >> > 5=3D82_Jakub_Dawidek?=3D writes: >> > > >> > > >> > > > On Apr 11, 2023, at 11:31, Cy Schubert >> wrote: >> > > >=3D20 >> > > > =3DEF=3DBB=3DBFIn message >> <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn. >> > d=3D >> > > e>,=3D20 >> > > > FreeBSD Us >> > > > er writes: >> > > >> Am Sun, 9 Apr 2023 14:37:03 +0200 >> > > >> Mateusz Guzik schrieb: >> > > >>=3D20 >> > > >>>> On 4/9/23, FreeBSD User wrote: >> > > >>>>> Today, after upgrading to FreeBSD 14.0-CURRENT #8 >> main-n262052-0d4038 >> > e=3D >> > > 301 >> > > >>> 2b: >> > > >>>>> Sun Apr 9 >> > > >>>>> 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via >> > > >>>>>=3D20 >> > > >>>>> zpool upgrade POOLNAME >> > > >>>>>=3D20 >> > > >>>>> some boxes keep crashing when starting compiler runs (the >> trigger is >> > > >>>>> different on boxes). >> > > >>>>>=3D20 >> > > >>>>> ZFS module is statically compiled into the kernel (if this is = of >> > > >>>>> importance) >> > > >>>>>=3D20 >> > > >>>>> Last known good was: >> > > >>>>>=3D20 >> > > >>>>> [...] >> > > >>>>> Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 >> > > >>>>> main-n262051-75379ea2e461: Sun Apr >> > > >>>>> 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: >> > > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 >> 07:10:04 >> > < >> > > =3D >> > > 0. >> > > >>> 2> >> > > >>>>> thor kernel: >> > > >>>>> FreeBSD clang version 15.0.7 ( >> https://github.com/llvm/llvm-project.gi >> > t=3D >> > > >> > > >>>>> llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor >> kernel: >> > > >>>>> VT(efifb): resolution >> > > >>>>> 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl >> already >> > > >>>>> present! >> > > >>>>> [...] >> > > >>>>>=3D20 >> > > >>>>> The file /var/crash/info.X >> > > >>>>>=3D20 >> > > >>>>> contains: >> > > >>>>>=3D20 >> > > >>>>> [...] >> > > >>>>>=3D20 >> > > >>>>> root@thor:/var/crash # more info.2 >> > > >>>>> Dump header from device: /dev/gpt/swap >> > > >>>>> Architecture: amd64 >> > > >>>>> Architecture Version: 2 >> > > >>>>> Dump Length: 1095192576 >> > > >>>>> Blocksize: 512 >> > > >>>>> Compression: none >> > > >>>>> Dumptime: 2023-04-09 11:43:41 +0000 >> > > >>>>> Hostname: thor.local >> > > >>>>> Magic: FreeBSD Kernel Dump >> > > >>>>> Version String: FreeBSD 14.0-CURRENT #8 >> main-n262052-0d4038e3012b: S >> > u=3D >> > > n=3D20 >> > > >>> Apr >> > > >>>>> 9 12:01:02 CEST >> > > >>>>> 2023 >> > > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR >> > > >>>>> Panic String: VERIFY(!zil_replaying(zilog, tx)) failed >> > > >>>>>=3D20 >> > > >>>>> Dump Parity: 2961465682 >> > > >>>>> Bounds: 2 >> > > >>>>> Dump Status: good >> > > >>>>>=3D20 >> > > >>>>> Until reconfigured for more debug stuff I do not have more to >> present >> > .=3D >> > > >> > > >>>>>=3D20 >> > > >>>>> I rememeber now really scraed that there was a HEADSUP in the >> list re >> > g=3D >> > > ard >> > > >>> ing >> > > >>>>> some serious ZFS >> > > >>>>> problems - I didn't find it right now. >> > > >>>>>=3D20 >> > > >>>>> Thanks in advance, >> > > >>>>>=3D20 >> > > >>>=3D20 >> > > >>> That's fallout from the new block cloning feature, adding the >> author >> > > >>>=3D20 >> > > >>=3D20 >> > > >> Thanks. >> > > >>=3D20 >> > > >> As of this moment, all systems with the newest kernel and the new >> ZFS op >> > t=3D >> > > ion=3D20 >> > > >> enabled, crash - >> > > >> the reason is mostly in different ZFS datasets. I guess there is >> no way >> > b >> > > =3D >> > > ack >> > > >> once this faulty >> > > >> option is enabled? >> > > >=3D20 >> > > > I've run a test on a scratch pool here, first without >> block_cloning=3D20 >> > > > enabled, then with. There was no corruption when block_cloning >> was=3D20 >> > > > disabled. There was corruption when block_cloning was enabled. >> > > >=3D20 >> > > > I don't know of any way to revert back nor is there any way to fix >> or=3D20 >> > > > recover the corrupted blocks. >> > > >> > > Is the corruption still present after EXDEV fixes? >> > >> > Yes and no. >> > >> > Yes, there is corruption when block_cloning is enabled. >> > >> > There is no corruption when block_cloning is disabled. >> >> I should add some detail to this. >> >> The corruption experienced when block cloning is disabled was fixed by: >> >> - eb1feadc201a >> - e2d997d1cbb9 >> - d012836fb616 (specifically this commit) >> - 20be1b4fc4b7 >> >> When block_cloning is enabled, the pool is corrupted. This has not been >> fixed. >> >> >> -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: https://FreeBSD.org >> NTP: Web: https://nwtime.org >> >> e^(i*pi)+1=3D0 >> >> >> >> > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000e80a0f05f9236911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

Trying :
`zpool set feature@block_cloning=3Ddisabled zroot`:
cannot s= et property for 'zroot': property 'feature@block_cloning' c= an only be set to 'disabled' at creation time

Nuno Teixeira &l= t;eduardo@freebsd.org> escrev= eu no dia quarta, 12/04/2023 =C3=A0(s) 13:57:
Hello all,
at current 3fdb40d1befe after `zfs upgrade XXX`:

same problem when running compiler:

- poudriere: crash without dump
- make buildworld (/usr/src): s= hutdown -p (I will try to get a photo)

Is there a = way to disable block clone?

<= div dir=3D"ltr" class=3D"gmail_attr">Cy Schubert <Cy.Schubert@cschubert.com> = escreveu no dia ter=C3=A7a, 11/04/2023 =C3=A0(s) 15:47:
In message <20230411142831.D= B8245FA@slippy.cwsent.com>, Cy Schubert writes:
> In message <434B83DB-F6BB-436F-8AA5-385730D20BB1@dawidek= .net>,
> =3D?utf-8?Q?Pawe=3DC
> 5=3D82_Jakub_Dawidek?=3D writes:
> >
> >
> > > On Apr 11, 2023, at 11:31, Cy Schubert <Cy.Schubert@cschubert.com= > wrote:
> > >=3D20
> > > =3DEF=3DBB=3DBFIn message <20230409161436.5412fa6e@thor.i= ntern.walstatt.dynvpn.
> d=3D
> > e>,=3D20
> > > FreeBSD Us
> > > er writes:
> > >> Am Sun, 9 Apr 2023 14:37:03 +0200
> > >> Mateusz Guzik <mjguzik@gmail.com> schrieb:
> > >>=3D20
> > >>>> On 4/9/23, FreeBSD User <freebsd@walstatt-de.de> wrot= e:
> > >>>>> Today, after upgrading to FreeBSD 14.0-CURRE= NT #8 main-n262052-0d4038
> e=3D
> > 301
> > >>> 2b:
> > >>>>> Sun Apr=C2=A0 9
> > >>>>> 12:01:02 CEST 2023=C2=A0 amd64, AND upgradin= g ZPOOLs via
> > >>>>>=3D20
> > >>>>> zpool upgrade POOLNAME
> > >>>>>=3D20
> > >>>>> some boxes keep crashing when starting compi= ler runs (the trigger is
> > >>>>> different on boxes).
> > >>>>>=3D20
> > >>>>> ZFS module is statically compiled into the k= ernel (if this is of
> > >>>>> importance)
> > >>>>>=3D20
> > >>>>> Last known good was:
> > >>>>>=3D20
> > >>>>> [...]
> > >>>>> Apr=C2=A0 9 07:10:04 <0.2> thor kernel= : FreeBSD 14.0-CURRENT #7
> > >>>>> main-n262051-75379ea2e461: Sun Apr
> > >>>>> 9 00:12:57 CEST 2023 Apr=C2=A0 9 07:10:04 &l= t;0.2> thor kernel:
> > >>>>> root@thor:/usr/obj/usr/src/amd64.amd64/sys/T= HOR amd64 Apr=C2=A0 9 07:10:04
>=C2=A0 <
> > =3D
> > 0.
> > >>> 2>
> > >>>>> thor kernel:
> > >>>>> FreeBSD clang version 15.0.7 (= https://github.com/llvm/llvm-project.gi
> t=3D
> >
> > >>>>> llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr=C2=A0 9 = 07:10:04 <0.2> thor kernel:
> > >>>>> VT(efifb): resolution
> > >>>>> 2560x1440 Apr=C2=A0 9 07:10:04 <0.2> t= hor kernel: module zfsctrl already
> > >>>>> present!
> > >>>>> [...]
> > >>>>>=3D20
> > >>>>> The file /var/crash/info.X
> > >>>>>=3D20
> > >>>>> contains:
> > >>>>>=3D20
> > >>>>> [...]
> > >>>>>=3D20
> > >>>>> root@thor:/var/crash # more info.2
> > >>>>> Dump header from device: /dev/gpt/swap
> > >>>>>=C2=A0 Architecture: amd64
> > >>>>>=C2=A0 Architecture Version: 2
> > >>>>>=C2=A0 Dump Length: 1095192576
> > >>>>>=C2=A0 Blocksize: 512
> > >>>>>=C2=A0 Compression: none
> > >>>>>=C2=A0 Dumptime: 2023-04-09 11:43:41 +0000 > > >>>>>=C2=A0 Hostname: thor.local
> > >>>>>=C2=A0 Magic: FreeBSD Kernel Dump
> > >>>>>=C2=A0 Version String: FreeBSD 14.0-CURRENT #= 8 main-n262052-0d4038e3012b: S
> u=3D
> > n=3D20
> > >>> Apr
> > >>>>> 9 12:01:02 CEST
> > >>>>> 2023
> > >>>>>=C2=A0 =C2=A0 root@thor:/usr/obj/usr/src/amd6= 4.amd64/sys/THOR
> > >>>>>=C2=A0 Panic String: VERIFY(!zil_replaying(zi= log, tx)) failed
> > >>>>>=3D20
> > >>>>>=C2=A0 Dump Parity: 2961465682
> > >>>>>=C2=A0 Bounds: 2
> > >>>>>=C2=A0 Dump Status: good
> > >>>>>=3D20
> > >>>>> Until reconfigured for more debug stuff I do= not have more to present
> .=3D
> >
> > >>>>>=3D20
> > >>>>> I rememeber now really scraed that there was= a HEADSUP in the list re
> g=3D
> > ard
> > >>> ing
> > >>>>> some serious ZFS
> > >>>>> problems - I didn't find it right now. > > >>>>>=3D20
> > >>>>> Thanks in advance,
> > >>>>>=3D20
> > >>>=3D20
> > >>> That's fallout from the new block cloning featur= e, adding the author
> > >>>=3D20
> > >>=3D20
> > >> Thanks.
> > >>=3D20
> > >> As of this moment, all systems with the newest kernel an= d the new ZFS op
> t=3D
> > ion=3D20
> > >> enabled, crash -
> > >> the reason is mostly in=C2=A0 different ZFS datasets. I = guess there is no way
>=C2=A0 b
> > =3D
> > ack
> > >> once this faulty
> > >> option is enabled?
> > >=3D20
> > > I've run a test on a scratch pool here, first without bl= ock_cloning=3D20
> > > enabled, then with. There was no corruption when block_cloni= ng was=3D20
> > > disabled. There was corruption when block_cloning was enable= d.
> > >=3D20
> > > I don't know of any way to revert back nor is there any = way to fix or=3D20
> > > recover the corrupted blocks.
> >
> > Is the corruption still present after EXDEV fixes?
>
> Yes and no.
>
> Yes, there is corruption when block_cloning is enabled.
>
> There is no corruption when block_cloning is disabled.

I should add some detail to this.

The corruption experienced when block cloning is disabled was fixed by:

- eb1feadc201a
- e2d997d1cbb9
- d012836fb616 (specifically this commit)
- 20be1b4fc4b7

When block_cloning is enabled, the pool is corrupted. This has not been fixed.


--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeB= SD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2=A0 Web:=C2=A0 https://nwt= ime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0





--
Nuno TeixeiraFreeBSD Committer (ports)


--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000e80a0f05f9236911-- From nobody Wed Apr 12 14:59:52 2023 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 4PxQqR6tFmz44vDj for ; Wed, 12 Apr 2023 15:00:03 +0000 (UTC) (envelope-from driesm@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 4PxQqR51ZMz3NxY for ; Wed, 12 Apr 2023 15:00:03 +0000 (UTC) (envelope-from driesm@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681311603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=WWJzsnQRFyevjM1ulUpHaP/AQ8CfelVy5uRurmU6xuE=; b=roqIFEK4XRpme5SvHwBZtUh+N7a/+LiAka28/DxpgnwQ/CTb8XdStDApW7j6t4rCmM8/hd xDRSf6xG8EPVd83ya+Wp4RpAukzd1+WbrjnyDOmfwAsZ8dpnRsP6JOm0lrCm4tjLKOGBTM aGPa05FnyarNUKJ41kxnrjBMa+51Tep+d47ILD9ZVAxV2FImX/34wSttnTd9am/Q+5/4aR LRBS2Z7MyLdfJ9nb1xL+Rwr3tBva0kpAdhvmko1M0Xdz9OjzGVJg1WiZpvonsDgE0xFaRd W0HDuHxSJmx25RUPCrELqnFS0B6SU98UFOBG3jYlfX5mMD2JYdXxgxwCK7e0JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681311603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=WWJzsnQRFyevjM1ulUpHaP/AQ8CfelVy5uRurmU6xuE=; b=Nlm7oIXS5a+3usEO/yfuvF85v+e7bwCShK7P6cBEU0m3BPO077dBPitdYZtCO6m1E8EU9q Ry7TNJDWsC0ZFSz7emYRKPbdKjMxcW/dBqtfPPm9c20a4g2CD7XMunpT4nmVmgwn+eUMrm bvA2D8czCScPZ/fgmcYEAfq3nWNstpd77kcsWMPtqiwpHIYrb6CvgYw2hZ1VJ8QvLZfaWV ZaBKnD3AQz6W93Y+KV/sMplrqHv+rdjZniBMEico9CDJneqVJo8c1/b6ld7glIj3cVJIPk 63jq+CibdmDpjs0mLkdNnZ7av7gC2zuvV1bNigyXDAQ3Q62icu7lZNRgN9FKhQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681311603; a=rsa-sha256; cv=none; b=toHydbs2s+ZvQVaVzQgnbYXIL4owiuuKlNLgXMDvd27XjThctorHYW9Ihi88LjELEMb5XC tExzqQicz7ygbnbcNAmUSWmRjupx2s/d9HJ+SdZzyGADYjdMLpMXtqCS5zTXIVRtKXrd87 wY1fJNmG80t8E9xuuxCHpU9GWuuGO10t+2imWgX9g74jZZG8PBgevliLmATnW39HYvuKzK 8gPwjLZPstuiKtfs3o+nzF6o2ngWQoJJVwO8l+TFikuOgyLjBL6v+/vuZRyM+RCRUadThZ L48dS3FgdLqDlge0J1lpZMX+aubdW4clUtzK6Xv9kovFQKO2/+J4P406OKX67A== Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: driesm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PxQqR3zSfzG70 for ; Wed, 12 Apr 2023 15:00:03 +0000 (UTC) (envelope-from driesm@freebsd.org) Received: by mail-ot1-f47.google.com with SMTP id u24-20020a9d7218000000b006a413c893c8so1839035otj.10 for ; Wed, 12 Apr 2023 08:00:03 -0700 (PDT) X-Gm-Message-State: AAQBX9cvrMSumfmDz75T6XoA4gEeKO7rWlXIJWGG/8UKftOoOO+9TFn9 tuIVR19fp2OWag8jGfV+x7q7WK+LUkHfd256dG4= X-Google-Smtp-Source: AKy350aOkVkJYTCVM6zXXBMqw09nZSBmzo/H/njJCvM9HYp6+tnpwbkeUraH+ANchpQJJxf2c6RLRhfd28JQztNcMNk= X-Received: by 2002:a05:6830:1205:b0:6a3:c42f:b653 with SMTP id r5-20020a056830120500b006a3c42fb653mr3954898otp.5.1681311602587; Wed, 12 Apr 2023 08:00:02 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Dries Michiels Date: Wed, 12 Apr 2023 16:59:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Status of Alder and Raptor lake on FreeBSD Current To: freebsd-current Content-Type: multipart/alternative; boundary="000000000000d4435c05f924dcd5" X-ThisMailContainsUnwantedMimeParts: N --000000000000d4435c05f924dcd5 Content-Type: text/plain; charset="UTF-8" Hello current mailing list, I was wondering what the status of Alder/Raptor lake support is on FreeBSD? Does it boot? Integrated graphics are supported from what I recall with the newest drm drivers. Are there any plans for changes to our scheduler to account for efficiency and performance cores? Are there real world downsides of not having such a scheduler when running an Alder or Raptor lake CPU? Interested to hear from users using these CPU's right now in there system! The Reason I ask is that I'm interested in upgrading my home server hardware :-). Regards Dries --000000000000d4435c05f924dcd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello current mailing list,

I was wonde= ring what the status of Alder/Raptor lake support=C2=A0is on FreeBSD?
=
Does=C2=A0it boot? Integrated graphics are supported from what I recal= l with the newest drm drivers.
Are there any plans for changes to= our scheduler=C2=A0to account for efficiency and performance cores?
<= div>Are there real world downsides of not having such a scheduler=C2=A0when= running an Alder or Raptor lake CPU?

Interested= =C2=A0to hear from users using=C2=A0these CPU's right now in there syst= em!
The Reason I ask is that I'm interested in upgrading my h= ome server hardware :-).

Regards
Dries
--000000000000d4435c05f924dcd5-- From nobody Wed Apr 12 18:43:08 2023 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 4PxWmx26Nmz44WkK for ; Wed, 12 Apr 2023 18:43:13 +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 4PxWmw0GwZz4V0g; Wed, 12 Apr 2023 18:43:12 +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.16.1/8.16.1) with ESMTP id 33CIh9F1056032; Wed, 12 Apr 2023 13:43:09 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1681324989; bh=w8UrvL+opMvr4l38L4sm0BmKhE7HkBk89RYfK5WREhE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KSALKskXS/i2dksTS8MNkJpBcA5pk/lC2y1Lm0n48lYkdnoO4i7ODO/K7MKNZAUZE 0lv0lUyncazOZhSRUIhy9ksm876c0aOPc8RlbYWbvaMP1M6q5ceKsHTVEhmPqXzVoL PmFpPH/SoMXpF2oS58v0+xuzLy34OWsjvc9BHpDsz5dnrtI2FU54Hm3zmX6s40T6lW UJwWN2OHw+bRXVJdoYnEI2QnljrOy5P/pMikVq2aLtUryp7+OAKDIqz9tAc2wG2uzQ wreRa7qczk8U2dK9LAeEfKJlTmFuiTht6uStSS97vM/3D69ofsvF7bns99uj7egGZq es3oE29+4Y37A== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id KapDCr37NmTe2gAAs/W3XQ (envelope-from ); Wed, 12 Apr 2023 13:43:09 -0500 From: Mike Karels To: Dries Michiels Cc: freebsd-current Subject: Re: Status of Alder and Raptor lake on FreeBSD Current Date: Wed, 12 Apr 2023 13:43:08 -0500 X-Mailer: MailMate (1.14r5937) Message-ID: <1B74CD55-A473-42AC-AE8B-73AE60121143@karels.net> In-Reply-To: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4PxWmw0GwZz4V0g X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 12 Apr 2023, at 9:59, Dries Michiels wrote: > Hello current mailing list, > > I was wondering what the status of Alder/Raptor lake support is on FreeBSD? > Does it boot? Integrated graphics are supported from what I recall with the > newest drm drivers. -current and 13.2 boot and run on Alder Lake, and probably Raptor Lake (I haven’t heard of any tests). There is a bug, probably in hardware, that affects page invalidation on E-cores, but a workaround changes the mechanism on the E-cores to compensate. I have no information on graphics, maybe someone else does. > Are there any plans for changes to our scheduler to account for efficiency > and performance cores? > Are there real world downsides of not having such a scheduler when running > an Alder or Raptor lake CPU? I have been working on scheduler changes, but slowly. Things work surprisingly well without them though. An E-core is slower than the first thread on a P-core, but faster than the second thread. The scheduler puts fewer processes on the E-cores because of the shared cache in groups of 4 CPUs (vs 2 for SMT on the P-cores). Of course, with enough processes, they all get used. > Interested to hear from users using these CPU's right now in there system! > The Reason I ask is that I'm interested in upgrading my home server > hardware :-). I’m running -current on an i7-12700K, and it feels fast compared to my i7-10700K. Mike From nobody Wed Apr 12 23:42:20 2023 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 4PxfQN5KFPz450c6 for ; Wed, 12 Apr 2023 23:42:36 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (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 4PxfQN4kr0z4HB7; Wed, 12 Apr 2023 23:42:36 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-54ee0b73e08so252957027b3.0; Wed, 12 Apr 2023 16:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681342956; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aUDnanBtZf/xhaawNa4mMGIuglGMw3K5o2HurZimjoI=; b=N86OVTYDzEVh8xURL6iKjS1bnVwNRnWY2bjOlD7Wgcejzeit3VuiuVDjSreC3PoXcv wrlvbRnI4ZK2go0iwDsZsQrvLaynDG5Md66Tw1Fu+0gnEnkHlzaq7f8ec8DXX3nmPmRV 9jI5+aHTJ+SdQ8SQJDQLHO9v+FdJ9V2FMrD3w9uHaPQG4I0y4zUG55UqLVh93xfQPQ3c /tm8THLD05WAn1g3NsphPLboaBPTSqJSWQEpVSEwKzddhWs4pngSMy/DzTfNrt7oa5lg MxYIzhGdws/H4funRAsS3E5NvFesLqLJskU9llRzVVXBnTBsOKZAx1ZnunsvOtRW9PpE WrFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681342956; 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=aUDnanBtZf/xhaawNa4mMGIuglGMw3K5o2HurZimjoI=; b=UM2Hvw3HWCA2HLgbqLmk2rl/JaN4PeBNE9f465QYzElj+x6TdDVIOjlcIKrTyeTEIj zKWjjnFe4BmLjrliIPuSwLGWAJnnVYyqIDQz1fvsP4EdBixDW+PwXSXfy54zT6cbAy9n DwokSAStp3gA7Hj+pxXg2lANsNN9zOpxDAwYML5xR9zLHR/uqzvChHTmhPSRGv4AeBX5 LjXI4gwWSGdJxG9PwrjouW8CIuflYxpmjlciUvvODczjvvqHpLyz5JwofuWYSQ4oo/bE EGLLgaI3nHOscL+dERrbrB1qCBqecNMkSgrdP6MRMow3K1Y1p/UxL1KVGa+FtNsHgfBH dmoA== X-Gm-Message-State: AAQBX9cpAsezdMt361lXvRaZKPJ9cw5SNdgEp+znHwTgFF816qTDluHf fpQtOZhJOANRuy6yocWkp731p8ojmZnbo46+TVpQLRrP8x8= X-Google-Smtp-Source: AKy350YE42YUBzRb/+KikpctDuszuNC7i7gSnjm9iXFKL33sr0XUQwFvDk5HPuPJxRok6NOeGcUpyPMr4xWBcW04UM4= X-Received: by 2002:a81:ad0e:0:b0:544:cd0e:2f80 with SMTP id l14-20020a81ad0e000000b00544cd0e2f80mr159553ywh.8.1681342955968; Wed, 12 Apr 2023 16:42:35 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1B74CD55-A473-42AC-AE8B-73AE60121143@karels.net> In-Reply-To: <1B74CD55-A473-42AC-AE8B-73AE60121143@karels.net> From: Kevin Oberman Date: Wed, 12 Apr 2023 16:42:20 -0700 Message-ID: Subject: Re: Status of Alder and Raptor lake on FreeBSD Current To: mike@karels.net Cc: Dries Michiels , freebsd-current Content-Type: multipart/alternative; boundary="000000000000a2dcdf05f92c290f" X-Rspamd-Queue-Id: 4PxfQN4kr0z4HB7 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000a2dcdf05f92c290f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 12, 2023 at 11:43=E2=80=AFAM Mike Karels wrot= e: > On 12 Apr 2023, at 9:59, Dries Michiels wrote: > > > Hello current mailing list, > > > > I was wondering what the status of Alder/Raptor lake support is on > FreeBSD? > > Does it boot? Integrated graphics are supported from what I recall with > the > > newest drm drivers. > -current and 13.2 boot and run on Alder Lake, and probably Raptor Lake (I > haven=E2=80=99t heard of any tests). There is a bug, probably in hardwar= e, that > affects page invalidation on E-cores, but a workaround changes the > mechanism > on the E-cores to compensate. I have no information on graphics, maybe > someone else does. > It works with drm-515-kmod, but I have been unable to get VA-API or DRM to work much. driinfo reports swrast. Performance is pretty bad compared to my 12 year old Ivy Lake, but surprisingly fast with all 12 threads on my ThinkPad T16 running. a 1180p video runs at about 13% of the total CPU capacity. glxgears get a rather paltry 900 FPS. But everything seems to work. Mike > --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000a2dcdf05f92c290f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 12, 2023 at 11:43= =E2=80=AFAM Mike Karels <mike@karels.net> wrote:
=
On 12 Apr 2023, at 9:59, = Dries Michiels wrote:

> Hello current mailing list,
>
> I was wondering what the status of Alder/Raptor lake support is on Fre= eBSD?
> Does it boot? Integrated graphics are supported from what I recall wit= h the
> newest drm drivers.
-current and 13.2 boot and run on Alder L= ake, and probably Raptor Lake (I
haven=E2=80=99t heard of any tests).=C2=A0 There is a bug, probably in hard= ware, that
affects page invalidation on E-cores, but a workaround changes the mechanis= m
on the E-cores to compensate.=C2=A0 I have no information on graphics, mayb= e
someone else does.
=C2=A0
=
It works with drm-515-kmod, but I have been unable to get VA-API = or DRM to work much. driinfo reports swrast. Performance is pretty bad comp= ared to my 12 year old Ivy Lake, but surprisingly fast with all 12 threads = on my ThinkPad T16 running. a 1180p video runs at about 13% of the total CP= U capacity. glxgears get a rather paltry 900 FPS. But everything seems to w= ork.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mike
--
Kevin Oberm= an, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
<= /div>
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
--000000000000a2dcdf05f92c290f-- From nobody Thu Apr 13 05:28:13 2023 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 4Pxp5Y4q9qz45TD0 for ; Thu, 13 Apr 2023 05:28:33 +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 4Pxp5W2gfgz4CTn for ; Thu, 13 Apr 2023 05:28:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PS3kauxm; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681363708; bh=L5q5sALpsYKoVMC4oyt29NhN4/yoqXPpBQbs936dfSU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=PS3kauxm6DIGSpv+1nAPbJvgDLEDgxxRyr/VOq231OFg5nyvM99UX54yEu+4sgcnDMV6PNDejV+nxpHqoqpbXFUoszLoNGh7OkCUIypmX5pu9wcUTNXoXYFrrQKuiT6MzAmkN+AOjgTk/7mWmcn+fZcM7Dw1rVv3ZVmT9V9QwZei5yIQ+5X+q9rGJBeRM+fN1XbW+Q9ntRBVUB1v+hES5sjXwiHZLPVV6CiWUc+LT5hf/0+GEb7zE/ZlshyqwRQmyNrHhKFdqLrnlZQNhtHK0F3ZAVm0wI26XDC0MpEyZwcBw5VDZbwL0vyafd/9/jCvoCqWF5G3ZCBLmV87Qqks4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681363708; bh=9O8rW1estJc8tDGxkleHYAB6B85vzwHUhYwQCGbopZc=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XwlfmPfn+k69bT0bqPGrXaT/CF8O6IYde2LI86+Y+6vyJUFnkLT5SzPdx6x4pMwcmlBOdDtveVGZBWjtDsTRz0T+VW22DKxkjD2rbJExCsEk0b8vDKxuu7i1BwRo5eqsjtgZChlF9T5KSxgk8GD8Yg6UnmZtwzFAPVfq0gyp8uzMXwZTxhvU5K8maFNZuiVpROHpMC2M8i1HsnZ4uJwS02aBG8K7jxK3xS66ccwTnGCoEVOkr6tzfg5ufUtUCtsJJ8oOqy9uy/gPNwZzH73p5sjfTd05SP/4sOIIf7U96SqCJqs8Ge7+LGAgZvm/8YF3pPaczC4DjGJ5l/KBpMnjyQ== X-YMail-OSG: 5xF05S8VM1mXlDt0Hhdjw3cXXeBxGBurn3vLXMQAvqBqn1tA6D6YiC3adyZdze4 us5XQpDTOHbBQPagLAZSQdMVN9jU0U3w1_y7DmP9jQLmG7w8s0gp_x8IO3dYLlhE7umUuxXxBY5W .qZBHxQ8z1WYx59_u3L0UqTiuNujZ9GLaKPS3TtsQEUdcqG7p5AKWVTtVmqtdwhCHBIcmqjKI3fh ZSAppnZ9oSzT2ggAAvX26_ONCVXzoWlf.g8h0ED66Dt.pHI.WTWWnVOolmu7C2i7Q.4Cn_qNJEDx 7OG.xNgnhOHqogDwFXWYBxaEKK9dDbrqKn2LaWADMUW_k_J_InlfkHczMVj99j428XjacWE2.IVf RTXzrEh_6f1Tj_nxoLUqNzcaBZJQoek4MkL9oJtIexBUu5mCo4yY4ZlY2pbEwgQwqW8t0NKRfqYf 7FPBkVTXAcGdxZhpYfo8IhT1gqUn4NvTqepr2ExGY1MpeqRH98O9.2WwidPBgw..hVD0MOMEjMi3 Ziqp3SdZLz9z5U9232vivoBZbfNH._GAxjX242TrhQ7OkFVUrUkYcTx_.7mAyEIzt3bm.M8e5lew TejtaTQl1itIqdBHhnTBw5K2Kq3X9pMvBEliT.blWmfXdJDmm50UQaw4Powbuo88chPQYxx4.4GZ JLV2OTG7JKjqbMcJO34Dbr4ynPm0NiW1moU9SS64XlKy3PUybLuCEeGWYPn6aE1wzUhaCcDp5rMa jPPoLBu2v5785TA1_ivqNo9c6JTZaCm3SUI8_Ml1evAoisHYWUNyPCY7RNBCMDJilMaw68RjTwHh Owetkp0syY7TgUOCxY4iNCiCKALyaB4Wyxxh8tRc7Ds0GdFajxPItQVXQbWtkgwDhbnouyL_vkpz VntGAj2KfoCcZGcyMo_Qhj6mbYYqjDKaYVHDhOrgbI2RbOqviTpwy0yCVoDuBjnUQcRfqh4ecukf qfuoyGIKJk70bRWZst7hWgOc3uXhEIGxuK2cunlVIPFqsKNFe8lqsFnAT7k9mQQx2wYAkAuNzEUv KZdoM6SPOIQt_3.b8BMC8YCRjXZSSKijtiACS1HomsK_X3f6mcUPBOY7n7J9x.FZjHyvIDPrA.8p Zyu9_RRJQNrwtKlOTP_h.p6iac3tuWSRgndW.JCohOD0m2O3ydgIMqaquQqesrbpaxg.2tQ8mEHR dHbFLwYldhtj6IVTdsESpzzY1KEqvfTnXqCMiR6xH4996p6hAB0jzmNXSS5qM1fv6ElLlH9pMoFH 9PMTu54j6CZNqoi.NgOkgHLMAXct01YxjAxiOYjvogwLuDjPy1KFTCda91AQFQqC.tM5ZVDqt529 DdhH_Kz5FlBSliO6vcQybcFydpnCMNGWK993yjFHglUDysaHcgijZIQ7wgKI_HyCl48Sbc53E9hm VebnVbtGr1LfxL9ms2FK9ooOUTXbpYKyaTyRNvQCJRzztqxuOnU2bSPI4TF86bXs01N18X5JgkdK NqBRyrkxFPY_1Mk.10rsOHsvyzokvh2xc9sICGgkksomV85OmrYyiZRkfm99d5lCZd5hwKqiH8sp 1awiKLIG7RpkwvXEqsWflmvkXAvaVa8DPeankxP6qgVnbhJ4SIxJ._dFJYa9LuN_WAG622IvCgWP 6JCsFxDbJC9K4vFqGVm2zVblHAkCC9HLwrrRyPvIhSXZ.dOvf_in2f0bRuh1DN9B.seVLj7f0c8u MA1gVZiIEICxG6Kb.friXcZ42BWw9ctStAbjk9wgQAtD..lOxVIVLmKei8waoebj__YjMOzl.ixL dQLEgpGuhXs3fc8f7plKXBKI4s0LsI63TvXr3rtc6NRe0a9LliwV7mr3zVWZc7iMwv2ci2l1pTV0 QQfsiZB1uPm3mrPLHHYUuFMjRgJl2t2So1OBvjKkxiiNMeGIOJnkz4PUctuyje30n7maq5VtGdyz e6EdWR_5f9GL4MN5rTfInWGjME1.0AVPgLTptQrPRZW2pbZDOOtrl8ND2lq0VvomLa.vejy15UPC FzVg_.KfzkGvay9XqYZVUcszNUCfn.t.9qmfOFWu_PYZ2kenY1s.zdfQQcOk93PIQO9CKU._He5B E7LLJr7vQ.JuEP9MxCxmedWLSRnwwi21YJ2SbbbWfWpPRtiB9gt251GJabAkvQqn.QWf66NCHJS3 Rj3s5OgyvP1vT_XF31xUj3ouMw.TeuEMi5AigtG8SlT3O5as3IAB3sErnjs.KoCbAa1ZSaHJR8xL a3ywt3qh6TwiI5s7JrRxoK425PJWSkuqARcArS3iFDiccjQH7NLOvO_d3RwG4ihxddw7vqAZ1XZM Ky.x_tg5v6QY- X-Sonic-MF: X-Sonic-ID: cad348fe-098d-41dd-8eef-80fc4c0e9dd6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Apr 2023 05:28:28 +0000 Received: by hermes--production-gq1-546798879c-dcj2l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 19058c53ce8266ee25011cb0f97af078; Thu, 13 Apr 2023 05:28:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-Id: Date: Wed, 12 Apr 2023 22:28:13 -0700 Cc: Cy Schubert To: Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: 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)[-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]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from] X-Rspamd-Queue-Id: 4Pxp5W2gfgz4CTn X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N From: Charlie Li wrote on Date: Wed, 12 Apr 2023 20:11:16 UTC : > Charlie Li wrote: > > Mateusz Guzik wrote: > >> can you please test poudriere with > >> https://github.com/openzfs/zfs/pull/14739/files > >> > > After applying, on the md(4)-backed pool regardless of = block_cloning,=20 > > the cy@ `cp -R` test reports no differing (ie corrupted) files. Will=20= > > report back on poudriere results (no block_cloning). > >=20 > As for poudriere, build failures are still rolling in. These are (and=20= > have been) entirely random on every run. Some examples from this run: >=20 > lang/php81: > - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=20 > ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf = ${STAGEDIR}/${PREFIX}/etc > - consumers fail to build due to corrupted php.conf packaged >=20 > devel/ninja: > - phase: stage > - install -s -m 555=20 > /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=20 > /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > - consumers fail to build due to corrupted bin/ninja packaged >=20 > devel/netsurf-buildsystem: > - phase: stage > - mkdir -p=20 > = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= tsurf-buildsystem/makefiles=20 > = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= tsurf-buildsystem/testtools > for M in Makefile.top Makefile.tools Makefile.subdir = Makefile.pkgconfig=20 > Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > cp makefiles/$M=20 > = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= tsurf-buildsystem/makefiles/;=20 > \ > done > - graphics/libnsgif fails to build due to NUL characters in=20 > Makefile.{clang,subdir}, causing nothing to link Summary: I have problems building ports into packages via poudriere-devel use despite being fully updated/patched (as of when I started the experiment), never having enabled block_cloning ( still using openzfs-2.1-freebsd ). In other words, I can confirm other reports that have been made. The details follow. [Written as I was working on setting up for the experiments and then executing those experiments, adjusting as I went along.] I've run my own tests in a context that has never had the zpool upgrade and that jump from before the openzfs import to after the existing commits for trying to fix openzfs on FreeBSD. I report on the sequence of activities getting to the point of testing as well. By personal policy I keep my (non-temporary) pool's compatible with what the most recent ??.?-RELEASE supports, using openzfs-2.1-freebsd for now. The pools involved below have never had a zpool upgrade from where they started. (I've no pools that have ever had a zpool upgrade.) (Temporary pools are rare for me, such as this investigation. But I'm not testing block_cloning or anything new this time.) I'll note that I use zfs for bectl, not for redundancy. So my evidence is more limited in that respect. The activities were done on a HoneyComb (16 Cortex-A72 cores). The system has and supports ECC RAM, 64 GiBytes of RAM are present. I started by duplicating my normal zfs environment to an external USB3 NVMe drive and adjusting the host name and such to produce the below. (Non-debug, although I do not strip symbols.) : # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 I then did: git fetch, stash push ., merge --ff-only, stash apply . : my normal procedure. I then also applied the patch from: https://github.com/openzfs/zfs/pull/14739/files Then I did: buildworld buildkernel, install them, and rebooted. The result was: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 = main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 The later poudriere-devel based build of packages from ports is based on: # ~/fbsd-based-on-what-commit.sh -C /usr/ports 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) = devel/freebsd-gcc12: Bump to 12.2.0. Author: John Baldwin Commit: John Baldwin CommitDate: 2023-03-25 00:06:40 +0000 branch: main merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 merge-base: CommitDate: 2023-03-25 00:06:40 +0000 n613214 (--first-parent --count for merge-base) poudriere attempted to build 476 packages, starting with pkg (in order to build the 56 that I explicitly indicate that I want). It is my normal set of ports. The form of building is biased to allowing a high load average compared to the number of hardware threads (same as cores here): each builder is allowed to use the full count of hardware threads. The build used USE_TMPFS=3D"data" instead of the USE_TMPFS=3Dall I normally use on the build machine involved. And it produced some random errors during the attempted builds. A type of example that is easy to interpret without further exploration is: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse = error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) A fair number of errors are of the form: the build installing a previously built package for use in the builder but later the builder can not find some file from the package's installation. Another error reported was: ld: error: /usr/local/lib/libblkid.a: unknown file type For reference: [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] Queued: = 476 Built: 252 Failed: 11 Skipped: 213 Ignored: 0 Fetched: 0 = Tobuild: 0 Time: 00:37:52 I started another build that tried to build 224 packeges: the 11 failed and 213 skipped. Just 1 package built that failed before: [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | = sqlite3-3.41.0_1,1: Success It seems to be the only one where the original failure was not an example of complaining about the missing/corrupted content of a package install used for building. So it is an example of randomly varying behavior. That, in turn, allowed: [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 to build but everything else failed or was skipped. The sqlite3 vs. other failure difference suggests that writes have random problems but later reads reliably see the problem that resulted (before the content is deleted). After the above: # zpool status pool: zroot state: ONLINE config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p8 ONLINE 0 0 0 errors: No known data errors # zpool scrub zroot # zpool status pool: zroot state: ONLINE scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 = 22:15:39 2023 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p8 ONLINE 0 0 0 errors: No known data errors =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 13 05:52:21 2023 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 4Pxpd53dQ3z45Vxq; Thu, 13 Apr 2023 05:52:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pxpd50Q9mz3l95; Thu, 13 Apr 2023 05:52:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id moE3p9FBSjvm1mpsepA1Qg; Thu, 13 Apr 2023 05:52:24 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mpscpJAgNHFsOmpsdpTHOs; Thu, 13 Apr 2023 05:52:24 +0000 X-Authority-Analysis: v=2.4 cv=XZqaca15 c=1 sm=1 tr=0 ts=64379898 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=CjxXgO3LAAAA:8 a=kDZLfgLDAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=PDfvT9ULBxMJ-dlh9yIA:9 a=CjuIK1q_8ugA:10 a=Aez1uqWRNYMWVBb44gMB:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 0775C908; Wed, 12 Apr 2023 22:52:22 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id E8B211F0; Wed, 12 Apr 2023 22:52:21 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Millard cc: Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , Cy Schubert Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: References: Comments: In-reply-to Mark Millard message dated "Wed, 12 Apr 2023 22:28:13 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Apr 2023 22:52:21 -0700 Message-Id: <20230413055221.E8B211F0@slippy.cwsent.com> X-CMAE-Envelope: MS4xfNXk6Z6tF/DEUb/02Rm7PoY8z7gLfZfj/pIqE9g3figmUuA8pGI4ooq8louuaVk1g+np4dUYOcPpOiruEDq33jGuaXoUQdHA4N29/AEyYHTaroIfKBCH uTuxhWJWA3S5G+mgT2tjifQDUZiz9/AvvkzN9YzIxOcdMroiF024QcOUcZJj/s6XLrvVAnGzMW7trIjfNNbTDdJATrs16T74sJDfzFxWv6G+NegriyH7Mrht 7O8tU0u9fk6PvniuKMku3AeBJjT50xbtd1wGRJaUXHtqgN6e7S23I06ZB+GfPGqr7F/pzpLxw8YDWEZzL/W29PvWdMt3t6N1+zIruqsyMzBz6WnoEqZToYGw +q4z9F9f X-Rspamd-Queue-Id: 4Pxpd50Q9mz3l95 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message , Mark Millard write s: > From: Charlie Li wrote on > Date: Wed, 12 Apr 2023 20:11:16 UTC : > > > Charlie Li wrote: > > > Mateusz Guzik wrote: > > >> can you please test poudriere with > > >> https://github.com/openzfs/zfs/pull/14739/files > > >> > > > After applying, on the md(4)-backed pool regardless of = > block_cloning,=20 > > > the cy@ `cp -R` test reports no differing (ie corrupted) files. Will=20= > > > > report back on poudriere results (no block_cloning). > > >=20 > > As for poudriere, build failures are still rolling in. These are (and=20= > > > have been) entirely random on every run. Some examples from this run: > >=20 > > lang/php81: > > - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=20 > > ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf = > ${STAGEDIR}/${PREFIX}/etc > > - consumers fail to build due to corrupted php.conf packaged > >=20 > > devel/ninja: > > - phase: stage > > - install -s -m 555=20 > > /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=20 > > /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > > - consumers fail to build due to corrupted bin/ninja packaged > >=20 > > devel/netsurf-buildsystem: > > - phase: stage > > - mkdir -p=20 > > = > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > tsurf-buildsystem/makefiles=20 > > = > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > tsurf-buildsystem/testtools > > for M in Makefile.top Makefile.tools Makefile.subdir = > Makefile.pkgconfig=20 > > Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > > cp makefiles/$M=20 > > = > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > tsurf-buildsystem/makefiles/;=20 > > \ > > done > > - graphics/libnsgif fails to build due to NUL characters in=20 > > Makefile.{clang,subdir}, causing nothing to link > > Summary: I have problems building ports into packages > via poudriere-devel use despite being fully updated/patched > (as of when I started the experiment), never having enabled > block_cloning ( still using openzfs-2.1-freebsd ). > > In other words, I can confirm other reports that have > been made. > > The details follow. > > > [Written as I was working on setting up for the experiments > and then executing those experiments, adjusting as I went > along.] > > I've run my own tests in a context that has never had the > zpool upgrade and that jump from before the openzfs import to > after the existing commits for trying to fix openzfs on > FreeBSD. I report on the sequence of activities getting to > the point of testing as well. > > By personal policy I keep my (non-temporary) pool's compatible > with what the most recent ??.?-RELEASE supports, using > openzfs-2.1-freebsd for now. The pools involved below have > never had a zpool upgrade from where they started. (I've no > pools that have ever had a zpool upgrade.) > > (Temporary pools are rare for me, such as this investigation. > But I'm not testing block_cloning or anything new this time.) > > I'll note that I use zfs for bectl, not for redundancy. So > my evidence is more limited in that respect. > > The activities were done on a HoneyComb (16 Cortex-A72 cores). > The system has and supports ECC RAM, 64 GiBytes of RAM are > present. > > I started by duplicating my normal zfs environment to an > external USB3 NVMe drive and adjusting the host name and such > to produce the below. (Non-debug, although I do not strip > symbols.) : > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = > main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 = > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= > 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > > I then did: git fetch, stash push ., merge --ff-only, stash apply . : > my normal procedure. I then also applied the patch from: > > https://github.com/openzfs/zfs/pull/14739/files > > Then I did: buildworld buildkernel, install them, and rebooted. > > The result was: > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 = > main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 = > root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= > 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > > The later poudriere-devel based build of packages from ports is > based on: > > # ~/fbsd-based-on-what-commit.sh -C /usr/ports > 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) = > devel/freebsd-gcc12: Bump to 12.2.0. > Author: John Baldwin > Commit: John Baldwin > CommitDate: 2023-03-25 00:06:40 +0000 > branch: main > merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > n613214 (--first-parent --count for merge-base) > > poudriere attempted to build 476 packages, starting > with pkg (in order to build the 56 that I explicitly > indicate that I want). It is my normal set of ports. > The form of building is biased to allowing a high > load average compared to the number of hardware > threads (same as cores here): each builder is allowed > to use the full count of hardware threads. The build > used USE_TMPFS=3D"data" instead of the USE_TMPFS=3Dall I > normally use on the build machine involved. > > And it produced some random errors during the attempted > builds. A type of example that is easy to interpret > without further exploration is: > > pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse = > error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > > A fair number of errors are of the form: the build > installing a previously built package for use in the > builder but later the builder can not find some file > from the package's installation. > > Another error reported was: > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > For reference: > > [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] Queued: = > 476 Built: 252 Failed: 11 Skipped: 213 Ignored: 0 Fetched: 0 = > Tobuild: 0 Time: 00:37:52 > > I started another build that tried to build 224 packeges: > the 11 failed and 213 skipped. > > Just 1 package built that failed before: > > [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | = > sqlite3-3.41.0_1,1: Success > > It seems to be the only one where the original failure was not > an example of complaining about the missing/corrupted content > of a package install used for building. So it is an example > of randomly varying behavior. > > That, in turn, allowed: > > [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 > > to build but everything else failed or was skipped. > > The sqlite3 vs. other failure difference suggests that writes > have random problems but later reads reliably see the problem > that resulted (before the content is deleted). > > > After the above: > > # zpool status > pool: zroot > state: ONLINE > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p8 ONLINE 0 0 0 > > errors: No known data errors > >> # zpool status > pool: zroot > state: ONLINE > scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 = > 22:15:39 2023 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p8 ONLINE 0 0 0 > > errors: No known data errors > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com Let's try this again. Claws-mail didn't include the list address in the header. Trying to reply, again, using exmh instead. Did your pools suffer the EXDEV problem? The EXDEV also corrupted files. I think, without sufficient investigation we risk jumping to conclusions. I've taken an extremely cautious approach, rolling back snapshots (as much as possible, i.e. poudriere datasets) when EXDEV corruption was encountered. I did not rollback any snapshots in my MH mail directory. Rolling back snapshots of my MH maildir would result in loss of email. I have to live with that corruption. Corrupted files in my outgoing sent email directory remain: slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1 53 slippy$ There are 53 corrupted files in my note log of 9913 emails. Those files will never be fixed. They were corrupted by the EXDEV bug. Any new ZFS or ZFS patches cannot retroactively remove the corruption from those files. But my poudriere files, because the snapshots were rolled back, were "repaired" by the rolled back snapshots. I'm not convinced that there is presently active corruption since the problem has been fixed. I am convinced that whatever corruption that was written at the time will remain forever or until those files are deleted or replaced -- just like my email files written to disk at the time. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Thu Apr 13 06:21:19 2023 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 4PxqGt11Zgz45YFC for ; Thu, 13 Apr 2023 06:21:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4PxqGs2GhQz4Wsq for ; Thu, 13 Apr 2023 06:21:41 +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=1681366898; bh=CO8PRRu3TSsLc/F8pOb+6WdYJ9PxhDtllc2LhGE4UeA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JRtzimld5TFU5SrXYWwpaqC+MrtBsY3JoIdRkjx+uNfyx2oC0bqKMfwh6OcnKFce/MKZK0iWaB60on7/EvcU/KkQROb4OKU3EyOAuY7KAwmDZRr2G0I5AraKds4VLGL6LC+z/Y3e2bsicpG//HRNs3Mkiu6nuAX/QewCD8YNgFiEilLcjiI1dgS7g9ecKI+LC5UvHoAc1O6tLtW6k2t0l0BR8+VCfrrYum7KGc0PoVRinjXBJ3vyAEQSWccIrGOllyXsKQjI4cgrl/0gIKgCeXeXMm7c3XE0fYP1tCmayi3Jo9xunO0uOSSwr8lbKYFOwx9Giea5hFKRynWPieYKIg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681366898; bh=C7Tg+f5q7NYiKWciU0/pEo1Db4MuQH72/miLV4eiM/M=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=C2tgmlLgE2UJ7RQSHpZ7/aMNjKyN46m2bPxwK8FIZ7fTQiiIjT3XmGWe//1dQisxm4vcLfKjV8QYDIAv4bqTVC+skfpFkpUtbqrRADaJ1ZDfz2HjfkdQioNNDpklFG+HFa96OdANyQiS8jk0KxSDpDlJRjr7L7jy+8sXZ2Hyx+f2+I9cezK3+5jAOyXS4rdvx6uThkzPjjbMfwVJ2OtkUlBYDaHDgdyVfzxjRBbGhKYPu7Y4TLvp6SzWgf7aUYvOkVpClcZoduydmB+SjsP/Lh+h7UEi6IEBSiuECc6L49O6s72DwAB0Y0B4SqEyPNzXniPqx8ekjcwFXWXJ9C1APg== X-YMail-OSG: RyNtswIVM1npF6zm.gZ4eIQsHfA_tU385IEK__S.6YUuBJs9bysP5mTh.MCIaCH MWoLKCgIDaUp64d6Xfo1YDvytOIo_Tof3X5vMDBLZdvvYYS_vBU52qAf3s3t7b7M0cs1bbeNvb1k 8Fu.Ep7gDwLcoRzE9TcQqGa3HuoksLlpp.Ch9zGGQa_m9PGl.LmXrxjHDmMXNtgb9mdwLBUSyMAC kmUgjKyTEZzcYpG75EVZbWO7PnFwXhIgZcNZFdykhRuq2kzen3yY8cjnYIKzoMlfYrwDZHAynk0x s2EkkRH8d3Im4dsK8UyXaRsBo.2NYU9RCI1P3fFhL2Y1uI3r_1ju_fl5uIAd7AcYvpWTjQUWi9PC IaSChPnygLQZpnejKzHIH.ehSGc9XQxJ1x0To.f.3WkYIEuibE3Ag5qjzL5BXn_w8qX30vgBvh1N voPSMvtXPFMFbrMKKw3KFnBDMyiVVnXxSHmHfBvm0pZDynv9FNDrLvy9LKYJUjtfa5Eb7Gc43jm8 8veQxnYWloXgcfTpvV8WTI3e4DEreNU.KjuPS5cUEs9CbZi0sgvRTYxlvcDcwSeyzq.wVpE7_8mu 5yXBhF_8oxuo4Up85RwUKVOiKEohI4oud.5cQc28iMXBPUVA0C47RZPoOsm4CY5Wb3Tklf0D2j5L NfPxIVZD43wkV3yanZ3gWez2gi1cRwOtPuyxPLm7OSNiNvn36PXx01VZzwF1A0GjIOcbEJM8XY19 .sGsACoGnJxUyurpE1CWviySzsP2mANLi_bTrK..psXkGrPVKKpejZU3rIwUf3zsUb4VsvtmeqKr 5rJsqPhquiVBSnSRRVB98qaNranM_NrVLz1pH2.Bs7f8mfx20hkD7ad5Zlk.b0J4MJlTBKRQxT3n GPlzq5lPjxKjc97j33C4_4ITg4j9DR2_gGtOnDzOT96h1Mc2XiYPjKmppodFSXmrm_k0_3VKHxQF gzja31KqZErY1lNw1s8IO.wWALWObM_cjSJCq85cSALFiZnOYjngdPvncoxtGGSG0JK9ewIcJuN0 8_j0WcqFm6oGHeiLHwN8K4D4jL.kBxCQbLln27.bYS1CfmsMS8c.eRGPqEQxqV2Ra2JI.pDf4KIk 8iiD3_2LcO_p7_bHgJjbzI1Dt1xoCdDSFQHBMHmC0pqRiYoomXPlzcM_GOPclnsy2DdXid8Noam2 uPw3v9bYAADlC4ZNMqTEGjYWzRSfS1IoBm6HZkFauNKVpGUPt.HKNHBvqv_B9vI1AAfahf8jqn2F dboxoSy7URSlBQ9PVf._lyeLDFnQmAZw1n1OgJGdqujpFQHccSgePx6WqJ8Af12rasanO8qBpSOX cFDKkjuF8TizCkKLvi6u9SlICZZbgRkKqVYoToBUzw6RrSytL5AHAulqCOmD8WsocEtXVBv.Ktwh Y.0ZVegPR_ZRsrq5vF8GlH0pjQCJJTsDKMWYJs1ywsuFgc7GX8OpMjna6Slx4Zjv4P.rNLHWD6aQ gMKmL4zIypcg597YgX_EvPZWE5z_NFmyRIGAMVgarP2S6BiNhmRgkc84QNky4B5CfsY0zNL5E0y7 2h7M7a.0.prL9XJa45C5RruS8ZEcOpzHYIIV4C.AFEDWSh6qqx_MfuZVm0cRQI553sR3qAgjKV1v P1LzckclwWWjfnWv76AZVpxuTe_ge0nkLcxm._LgOo3R0EZ068Mw6jXcdaikAVCleMv9gfE0k72j YQrWY5D_B07I.22rkTwZ7plD91CyT_Tj17_MmYmSzDcSeGDm5Tb_GC3V13jw1TyewGtZPPR745JD WrES5ccK_lArK6lasj68eKFIV7c.uWHdSAxjvUP2dFl7zc7dYT6N1rIMh51oV_SI8h36IWDYSwWG WA9IVf1rAyH7wmi_vgTDZ.aehpMLSanJRfLBmrZYIsXRRtY7M91awTpiHrpBhYR3d.oMse_UA8Y1 8enro0o3gxhKK9NQDSqn5.17NZfy4DAwXkIPJ11u3C5JrJoa1dzFEAXCURs5uMsEH985jnXM8ure iwksHqbM04zw9GM6RjGzZAk7TtVCjlO030TXYOdIFCk.OI.b8VP9WHcgZHsORlxbzVwfyk8Am.YT nq5ZNBRM7JEdNUsRWV_oTiWUdzXst5sAWE7l2LA0q9vWfHTcfPMkMQjlg5lZztIYwu1QNU4gQCnn 3ip4jCsILMgYW6fih8hSMcXofSVQBebdzcfbQvrbMiHQRvQCHDfEr9uRD5YCYikGh1qrNmRnq7ZR ernJhSnfpYDGzor8rQCNkofjLFObGFshfCeh87c2FT4ZI.JHUNQyv_Hri2KijnQQo9IwKyyWSp1U gwEytkA-- X-Sonic-MF: X-Sonic-ID: 845b5ec2-8357-4222-b9db-1618602ddecd Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Apr 2023 06:21:38 +0000 Received: by hermes--production-bf1-5f9df5c5c4-wvm2h (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a481fa1bb45a3a50e0daa9b92e5d42cf; Thu, 13 Apr 2023 06:21:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <20230413055221.E8B211F0@slippy.cwsent.com> Date: Wed, 12 Apr 2023 23:21:19 -0700 Cc: Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230413055221.E8B211F0@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PxqGs2GhQz4Wsq X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N [This just puts my prior reply's material into Cy's adjusted resend of the original. The To/Cc should be coomplete this time.] On Apr 12, 2023, at 22:52, Cy Schubert = wrote: > In message , Mark = Millard=20 > write > s: >> From: Charlie Li wrote on >> Date: Wed, 12 Apr 2023 20:11:16 UTC : >>=20 >>> Charlie Li wrote: >>>> Mateusz Guzik wrote: >>>>> can you please test poudriere with >>>>> https://github.com/openzfs/zfs/pull/14739/files >>>>>=20 >>>> After applying, on the md(4)-backed pool regardless of =3D >> block_cloning,=3D20 >>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. = Will=3D20=3D >>=20 >>>> report back on poudriere results (no block_cloning). >>>> =3D20 >>> As for poudriere, build failures are still rolling in. These are = (and=3D20=3D >>=20 >>> have been) entirely random on every run. Some examples from this = run: >>> =3D20 >>> lang/php81: >>> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=3D20 >>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D >> ${STAGEDIR}/${PREFIX}/etc >>> - consumers fail to build due to corrupted php.conf packaged >>> =3D20 >>> devel/ninja: >>> - phase: stage >>> - install -s -m 555=3D20 >>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D20 >>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin >>> - consumers fail to build due to corrupted bin/ninja packaged >>> =3D20 >>> devel/netsurf-buildsystem: >>> - phase: stage >>> - mkdir -p=3D20 >>> =3D >> = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= =3D >> tsurf-buildsystem/makefiles=3D20 >>> =3D >> = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= =3D >> tsurf-buildsystem/testtools >>> for M in Makefile.top Makefile.tools Makefile.subdir =3D >> Makefile.pkgconfig=3D20 >>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ >>> cp makefiles/$M=3D20 >>> =3D >> = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= =3D >> tsurf-buildsystem/makefiles/;=3D20 >>> \ >>> done >>> - graphics/libnsgif fails to build due to NUL characters in=3D20 >>> Makefile.{clang,subdir}, causing nothing to link >>=20 >> Summary: I have problems building ports into packages >> via poudriere-devel use despite being fully updated/patched >> (as of when I started the experiment), never having enabled >> block_cloning ( still using openzfs-2.1-freebsd ). >>=20 >> In other words, I can confirm other reports that have >> been made. >>=20 >> The details follow. >>=20 >>=20 >> [Written as I was working on setting up for the experiments >> and then executing those experiments, adjusting as I went >> along.] >>=20 >> I've run my own tests in a context that has never had the >> zpool upgrade and that jump from before the openzfs import to >> after the existing commits for trying to fix openzfs on >> FreeBSD. I report on the sequence of activities getting to >> the point of testing as well. >>=20 >> By personal policy I keep my (non-temporary) pool's compatible >> with what the most recent ??.?-RELEASE supports, using >> openzfs-2.1-freebsd for now. The pools involved below have >> never had a zpool upgrade from where they started. (I've no >> pools that have ever had a zpool upgrade.) >>=20 >> (Temporary pools are rare for me, such as this investigation. >> But I'm not testing block_cloning or anything new this time.) >>=20 >> I'll note that I use zfs for bectl, not for redundancy. So >> my evidence is more limited in that respect. >>=20 >> The activities were done on a HoneyComb (16 Cortex-A72 cores). >> The system has and supports ECC RAM, 64 GiBytes of RAM are >> present. >>=20 >> I started by duplicating my normal zfs environment to an >> external USB3 NVMe drive and adjusting the host name and such >> to produce the below. (Non-debug, although I do not strip >> symbols.) : >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D >> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 =3D >> = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= =3D >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 >>=20 >> I then did: git fetch, stash push ., merge --ff-only, stash apply . : >> my normal procedure. I then also applied the patch from: >>=20 >> https://github.com/openzfs/zfs/pull/14739/files >>=20 >> Then I did: buildworld buildkernel, install them, and rebooted. >>=20 >> The result was: >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D >> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 =3D >> = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= =3D >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 >>=20 >> The later poudriere-devel based build of packages from ports is >> based on: >>=20 >> # ~/fbsd-based-on-what-commit.sh -C /usr/ports >> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D >> devel/freebsd-gcc12: Bump to 12.2.0. >> Author: John Baldwin >> Commit: John Baldwin >> CommitDate: 2023-03-25 00:06:40 +0000 >> branch: main >> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 >> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 >> n613214 (--first-parent --count for merge-base) >>=20 >> poudriere attempted to build 476 packages, starting >> with pkg (in order to build the 56 that I explicitly >> indicate that I want). It is my normal set of ports. >> The form of building is biased to allowing a high >> load average compared to the number of hardware >> threads (same as cores here): each builder is allowed >> to use the full count of hardware threads. The build >> used USE_TMPFS=3D3D"data" instead of the USE_TMPFS=3D3Dall I >> normally use on the build machine involved. >>=20 >> And it produced some random errors during the attempted >> builds. A type of example that is easy to interpret >> without further exploration is: >>=20 >> pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse = =3D >> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) >>=20 >> A fair number of errors are of the form: the build >> installing a previously built package for use in the >> builder but later the builder can not find some file >> from the package's installation. >>=20 >> Another error reported was: >>=20 >> ld: error: /usr/local/lib/libblkid.a: unknown file type >>=20 >> For reference: >>=20 >> [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] = Queued: =3D >> 476 Built: 252 Failed: 11 Skipped: 213 Ignored: 0 Fetched: 0 =3D >> Tobuild: 0 Time: 00:37:52 >>=20 >> I started another build that tried to build 224 packeges: >> the 11 failed and 213 skipped. >>=20 >> Just 1 package built that failed before: >>=20 >> [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | =3D >> sqlite3-3.41.0_1,1: Success >>=20 >> It seems to be the only one where the original failure was not >> an example of complaining about the missing/corrupted content >> of a package install used for building. So it is an example >> of randomly varying behavior. >>=20 >> That, in turn, allowed: >>=20 >> [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 >>=20 >> to build but everything else failed or was skipped. >>=20 >> The sqlite3 vs. other failure difference suggests that writes >> have random problems but later reads reliably see the problem >> that resulted (before the content is deleted). >>=20 >>=20 >> After the above: >>=20 >> # zpool status >> pool: zroot >> state: ONLINE >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> da0p8 ONLINE 0 0 0 >>=20 >> errors: No known data errors >>=20 >> =08=E0=B9=84=C2=8DM # zpool scrub zroot >> # zpool status >> pool: zroot >> state: ONLINE >> scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 =3D >> 22:15:39 2023 >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> da0p8 ONLINE 0 0 0 >>=20 >> errors: No known data errors >>=20 >>=20 >> =3D3D=3D3D=3D3D >> Mark Millard >> marklmi at yahoo.com >=20 >=20 > Let's try this again. Claws-mail didn't include the list address in = the=20 > header. Trying to reply, again, using exmh instead. >=20 >=20 > Did your pools suffer the EXDEV problem? The EXDEV also corrupted = files. As I reported, this was a jump from before the import to as things are tonight (here). So: NO, unless the existing code as of tonight still has the EXDEV problem! Prior to this experiment I'd not progressed any media beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > I think, without sufficient investigation we risk jumping to > conclusions. I've taken an extremely cautious approach, rolling back > snapshots (as much as possible, i.e. poudriere datasets) when EXDEV > corruption was encountered. Again: nothing between main-n261544-cee09bda03c8-dirty and main-n262122-2ef2c26f3f13-dirty was involved at any stage. >=20 > I did not rollback any snapshots in my MH mail directory. Rolling back > snapshots of my MH maildir would result in loss of email. I have to > live with that corruption. Corrupted files in my outgoing sent email > directory remain: >=20 > slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=20 > 53 > slippy$=20 >=20 > There are 53 corrupted files in my note log of 9913 emails. Those = files > will never be fixed. They were corrupted by the EXDEV bug. Any new ZFS > or ZFS patches cannot retroactively remove the corruption from those > files. >=20 > But my poudriere files, because the snapshots were rolled back, were > "repaired" by the rolled back snapshots. >=20 > I'm not convinced that there is presently active corruption since > the problem has been fixed. I am convinced that whatever corruption > that was written at the time will remain forever or until those files > are deleted or replaced -- just like my email files written to disk at > the time. My test results and procedure just do not fit your conclusion that things are okay now if block_clonging is completely avoided. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 13 06:42:52 2023 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 4PxqlM71ZNz45Zs1; Thu, 13 Apr 2023 06:42:55 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PxqlM5xJ0z3lN3; Thu, 13 Apr 2023 06:42:55 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id mmqmp3VKHuZMSmqfWpOI4B; Thu, 13 Apr 2023 06:42:54 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mqfUp4CUicyvumqfVp4k6P; Thu, 13 Apr 2023 06:42:54 +0000 X-Authority-Analysis: v=2.4 cv=VbHkgXl9 c=1 sm=1 tr=0 ts=6437a46e a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=8nJEP1OIZ-IA:10 a=dKHAf1wccvYA:10 a=CjxXgO3LAAAA:8 a=YxBL1-UpAAAA:8 a=kDZLfgLDAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=Q5sIUPrKt2Z6qAjYQ9sA:9 a=wPNLvfGTeEIA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=Aez1uqWRNYMWVBb44gMB:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 35E5CA1B; Wed, 12 Apr 2023 23:42:52 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 1E5C1318; Wed, 12 Apr 2023 23:42:52 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Millard cc: Cy Schubert , Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pawel@dawidek.net, pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: References: <20230413055221.E8B211F0@slippy.cwsent.com> Comments: In-reply-to Mark Millard message dated "Wed, 12 Apr 2023 23:21:19 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 12 Apr 2023 23:42:52 -0700 Message-Id: <20230413064252.1E5C1318@slippy.cwsent.com> X-CMAE-Envelope: MS4xfKVXIbi7ssLvnTb3JOj7dXnaImKSoPPshHeMdFgx8RPZheYaXcwaJnNEjbaQNKl28t+Wg7P/3YOesXP8fv4o4YF//5SNSrJaVZ64iKYmmVbJdQfQqTxo dWzqwlN3V1wCt2PwrQrjjJqk1YU8DGhsggYJWDXtYmx5hKHdlAAgwzHgN9AeU4e8bngQjUQZ3w3A0ZcUkqv53N8mBHVJzsvDf/8H7uejRAFJDGoLvrii/45i TO5SU/9E1jNL39RhCV7smd5ogkxQ2OrUzZIRaGnIc+oKhQscjmHpKghH/7GPvIWw5LsEQF27TVoXhO+4z3QAhZwYXLVgXBQLMZRdxYXvTPf5ssYAJ0Iwiq9I bK+Yn1NmmWB4iQNL0IPvsSWh+8pIERb41szoaTD4pv13rIlSwDU= X-Rspamd-Queue-Id: 4PxqlM5xJ0z3lN3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message , Mark Millard write s: > [This just puts my prior reply's material into Cy's > adjusted resend of the original. The To/Cc should > be coomplete this time.] > > On Apr 12, 2023, at 22:52, Cy Schubert = > wrote: > > > In message , Mark = > Millard=20 > > write > > s: > >> From: Charlie Li wrote on > >> Date: Wed, 12 Apr 2023 20:11:16 UTC : > >>=20 > >>> Charlie Li wrote: > >>>> Mateusz Guzik wrote: > >>>>> can you please test poudriere with > >>>>> https://github.com/openzfs/zfs/pull/14739/files > >>>>>=20 > >>>> After applying, on the md(4)-backed pool regardless of =3D > >> block_cloning,=3D20 > >>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. = > Will=3D20=3D > >>=20 > >>>> report back on poudriere results (no block_cloning). > >>>> =3D20 > >>> As for poudriere, build failures are still rolling in. These are = > (and=3D20=3D > >>=20 > >>> have been) entirely random on every run. Some examples from this = > run: > >>> =3D20 > >>> lang/php81: > >>> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=3D20 > >>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D > >> ${STAGEDIR}/${PREFIX}/etc > >>> - consumers fail to build due to corrupted php.conf packaged > >>> =3D20 > >>> devel/ninja: > >>> - phase: stage > >>> - install -s -m 555=3D20 > >>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D20 > >>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > >>> - consumers fail to build due to corrupted bin/ninja packaged > >>> =3D20 > >>> devel/netsurf-buildsystem: > >>> - phase: stage > >>> - mkdir -p=3D20 > >>> =3D > >> = > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > =3D > >> tsurf-buildsystem/makefiles=3D20 > >>> =3D > >> = > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > =3D > >> tsurf-buildsystem/testtools > >>> for M in Makefile.top Makefile.tools Makefile.subdir =3D > >> Makefile.pkgconfig=3D20 > >>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > >>> cp makefiles/$M=3D20 > >>> =3D > >> = > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > =3D > >> tsurf-buildsystem/makefiles/;=3D20 > >>> \ > >>> done > >>> - graphics/libnsgif fails to build due to NUL characters in=3D20 > >>> Makefile.{clang,subdir}, causing nothing to link > >>=20 > >> Summary: I have problems building ports into packages > >> via poudriere-devel use despite being fully updated/patched > >> (as of when I started the experiment), never having enabled > >> block_cloning ( still using openzfs-2.1-freebsd ). > >>=20 > >> In other words, I can confirm other reports that have > >> been made. > >>=20 > >> The details follow. > >>=20 > >>=20 > >> [Written as I was working on setting up for the experiments > >> and then executing those experiments, adjusting as I went > >> along.] > >>=20 > >> I've run my own tests in a context that has never had the > >> zpool upgrade and that jump from before the openzfs import to > >> after the existing commits for trying to fix openzfs on > >> FreeBSD. I report on the sequence of activities getting to > >> the point of testing as well. > >>=20 > >> By personal policy I keep my (non-temporary) pool's compatible > >> with what the most recent ??.?-RELEASE supports, using > >> openzfs-2.1-freebsd for now. The pools involved below have > >> never had a zpool upgrade from where they started. (I've no > >> pools that have ever had a zpool upgrade.) > >>=20 > >> (Temporary pools are rare for me, such as this investigation. > >> But I'm not testing block_cloning or anything new this time.) > >>=20 > >> I'll note that I use zfs for bectl, not for redundancy. So > >> my evidence is more limited in that respect. > >>=20 > >> The activities were done on a HoneyComb (16 Cortex-A72 cores). > >> The system has and supports ECC RAM, 64 GiBytes of RAM are > >> present. > >>=20 > >> I started by duplicating my normal zfs environment to an > >> external USB3 NVMe drive and adjusting the host name and such > >> to produce the below. (Non-debug, although I do not strip > >> symbols.) : > >>=20 > >> # uname -apKU > >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D > >> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 =3D > >> = > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= > =3D > >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > >>=20 > >> I then did: git fetch, stash push ., merge --ff-only, stash apply . : > >> my normal procedure. I then also applied the patch from: > >>=20 > >> https://github.com/openzfs/zfs/pull/14739/files > >>=20 > >> Then I did: buildworld buildkernel, install them, and rebooted. > >>=20 > >> The result was: > >>=20 > >> # uname -apKU > >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D > >> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 =3D > >> = > root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= > =3D > >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > >>=20 > >> The later poudriere-devel based build of packages from ports is > >> based on: > >>=20 > >> # ~/fbsd-based-on-what-commit.sh -C /usr/ports > >> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D > >> devel/freebsd-gcc12: Bump to 12.2.0. > >> Author: John Baldwin > >> Commit: John Baldwin > >> CommitDate: 2023-03-25 00:06:40 +0000 > >> branch: main > >> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > >> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > >> n613214 (--first-parent --count for merge-base) > >>=20 > >> poudriere attempted to build 476 packages, starting > >> with pkg (in order to build the 56 that I explicitly > >> indicate that I want). It is my normal set of ports. > >> The form of building is biased to allowing a high > >> load average compared to the number of hardware > >> threads (same as cores here): each builder is allowed > >> to use the full count of hardware threads. The build > >> used USE_TMPFS=3D3D"data" instead of the USE_TMPFS=3D3Dall I > >> normally use on the build machine involved. > >>=20 > >> And it produced some random errors during the attempted > >> builds. A type of example that is easy to interpret > >> without further exploration is: > >>=20 > >> pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse = > =3D > >> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > >>=20 > >> A fair number of errors are of the form: the build > >> installing a previously built package for use in the > >> builder but later the builder can not find some file > >> from the package's installation. > >>=20 > >> Another error reported was: > >>=20 > >> ld: error: /usr/local/lib/libblkid.a: unknown file type > >>=20 > >> For reference: > >>=20 > >> [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] = > Queued: =3D > >> 476 Built: 2> >> Tobuild: 0 Time: 00:37:52 > >>=20 > >> I started another build that tried to build 224 packeges: > >> the 11 failed and 213 skipped. > >>=20 > >> Just 1 package built that failed before: > >>=20 > >> [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | =3D > >> sqlite3-3.41.0_1,1: Success > >>=20 > >> It seems to be the only one where the original failure was not > >> an example of complaining about the missing/corrupted content > >> of a package install used for building. So it is an example > >> of randomly varying behavior. > >>=20 > >> That, in turn, allowed: > >>=20 > >> [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 > >>=20 > >> to build but everything else failed or was skipped. > >>=20 > >> The sqlite3 vs. other failure difference suggests that writes > >> have random problems but later reads reliably see the problem > >> that resulted (before the content is deleted). > >>=20 > >>=20 > >> After the above: > >>=20 > >> # zpool status > >> pool: zroot > >> state: ONLINE > >> config: > >>=20 > >> NAME STATE READ WRITE CKSUM > >> zroot ONLINE 0 0 0 > >> da0p8 ONLINE 0 0 0 > >>=20 > >> errors: No known data errors > >>=20 > >> =08=E0=B9=84=C2=8DM # zpool scrub zroot > >> # zpool status > >> pool: zroot > >> state: ONLINE > >> scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 =3D > >> 22:15:39 2023 > >> config: > >>=20 > >> NAME STATE READ WRITE CKSUM > >> zroot ONLINE 0 0 0 > >> da0p8 ONLINE 0 0 0 > >>=20 > >> errors: No known data errors > >>=20 > >>=20 > >> =3D3D=3D3D=3D3D > >> Mark Millard > >> marklmi at yahoo.com > >=20 > >=20 > > Let's try this again. Claws-mail didn't include the list address in = > the=20 > > header. Trying to reply, again, using exmh instead. > >=20 > >=20 > > Did your pools suffer the EXDEV problem? The EXDEV also corrupted = > files. > > As I reported, this was a jump from before the import > to as things are tonight (here). So: NO, unless the > existing code as of tonight still has the EXDEV problem! > > Prior to this experiment I'd not progressed any media > beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > > > I think, without sufficient investigation we risk jumping to > > conclusions. I've taken an extremely cautious approach, rolling back > > snapshots (as much as possible, i.e. poudriere datasets) when EXDEV > > corruption was encountered. > > Again: nothing between main-n261544-cee09bda03c8-dirty and > main-n262122-2ef2c26f3f13-dirty was involved at any stage. > > >=20 > > I did not rollback any snapshots in my MH mail directory. Rolling back > > snapshots of my MH maildir would result in loss of email. I have to > > live with that corruption. Corrupted files in my outgoing sent email > > directory remain: > >=20 > > slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=20 > > 53 > > slippy$=20 > >=20 > > There are 53 corrupted files in my note log of 9913 emails. Those = > files > > will never be fixed. They were corrupted by the EXDEV bug. Any new ZFS > > or ZFS patches cannot retroactively remove the corruption from those > > files. > >=20 > > But my poudriere files, because the snapshots were rolled back, were > > "repaired" by the rolled back snapshots. > >=20 > > I'm not convinced that there is presently active corruption since > > the problem has been fixed. I am convinced that whatever corruption > > that was written at the time will remain forever or until those files > > are deleted or replaced -- just like my email files written to disk at > > the time. > > My test results and procedure just do not fit your conclusion > that things are okay now if block_clonging is completely avoided. Admitting I'm wrong: sending copies of my last reply to you back to myself, again and again, three times, I've managed to reproduce the corruption you are talking about. >From my previous email to you. header. Trying to reply ^^^^^^^^^ Here it is, nine additional bytes of garbage. In another instance about 500 bytes were removed. I can reproduce the corruption at will now. The EXDEV patch is applied. Block_cloning is disabled. > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Thu Apr 13 06:52:53 2023 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 4PxqzC1lBnz45bkc for ; Thu, 13 Apr 2023 06:53:11 +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 4PxqzB4fDgz40RX for ; Thu, 13 Apr 2023 06:53:10 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; none Received: from outgoing.leidinger.net (p5b165130.dip0.t-ipconnect.de [91.22.81.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 905F9280A1 for ; Thu, 13 Apr 2023 08:52:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1681368776; 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=bWldago0k2E4j27RlB1aVe/L6cIPFMAL7GEI+j2t90E=; b=weI0M5rYDifJS/3GaJS1bDnslps+brhXqts3y9JfSSipVB8vpKOFnUFxVhgnLdLiwGQc8O Sag3zYPIWLlCUMRe2WSdV4od2w87OxoGQtJGOPCKyabw7m1bBSQ/mc/SdGe1whH2Lo0Ldx tkjmWQ6rLjlGxliiOpevath6OlPvyVA96tKTyv3oNO1gm32URLOf2KqiI6zccmoXGbEzBz GduOpTDIpEeMREX8HZ6SeEFlNGi4p9bnIZE1Pi+AlmK5bznorvWilXUCuEJ+XiFctIf1EJ Dska5rhWeILc/HUWFrmsx89ypD2bL3a7UCE8cZMKG8xtrsfChn5yinfCoUPdBg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 5BF48A0C8 for ; Thu, 13 Apr 2023 08:52:53 +0200 (CEST) Received: from www (uid 80) (envelope-from Alexander@leidinger.net) id 68656 by webmail.leidinger.net (DragonFly Mail Agent v0.13+ on webmail.leidinger.net); Thu, 13 Apr 2023 08:52:53 +0200 Date: Thu, 13 Apr 2023 08:52:53 +0200 Message-ID: <20230413085253.Horde.bYgKkPjxGfDPP_pwWqnyTN2@webmail.leidinger.net> From: Alexander Leidinger To: Mark Millard Cc: Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , Cy Schubert Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_XJcTNEGi5tSrLXujDCZB1br"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4PxqzB4fDgz40RX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_XJcTNEGi5tSrLXujDCZB1br Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Mark Millard (from Wed, 12 Apr 2023=20=20 22:28:13=20-0700): > A fair number of errors are of the form: the build > installing a previously built package for use in the > builder but later the builder can not find some file > from the package's installation. As a data point, last year I had such issues with one particular=20=20 package.=20It was consistent no matter how often I was updating the=20=20 ports=20tree. Poudriere always failed on port X which was depending on=20= =20 port=20Y (don't remember the names). The problem was, that port Y was=20=20 build=20successfully but an extract of it was not having a file it was=20= =20 supposed=20to have. IIRC I fixed the issue by building the port Y=20=20 manually,=20as re-building port Y with poudriere didn't change the=20=20 outcome. So=20it seems this may not be specific to the most recent ZFS version,=20= =20 but=20could be an older issue. It may be the case that the more recent=20= =20 ZFS=20version amplifies the problem. It can also be that it is related=20= =20 to=20a specific use case in poudriere. I remember a recent mail which talks about poudriere failing to copy=20=20 files=20in resource-limited environments, see=20=20 https://lists.freebsd.org/archives/dev-commits-src-all/2023-April/025153.ht= ml While=20the issue you are trying to pin-point may not be related to this=20= =20 discussion,=20I mention it because it smells to me like we could be in a=20= =20 situation=20where a similar combination of unrelated to each other=20=20 FreeBSD=20features could form a combination which triggers the issue at=20= =20 hand. Bye, Alexander. --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_XJcTNEGi5tSrLXujDCZB1br Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmQ3psQACgkQEg2wmwP4 2IYtNA//TmbSVqDv8LUhp46+N91wzieAFOeiJqQSMIvbmmn8fALAQyCe5qfczV3z SDsNI6JwNAUxWC6e4v933DoTH56D6ychOigtANR4IMhJt3XkWnsKnz8gby8/JEMG g1ua2lRRApd0b8cNsoadgWPIWw+y9TiVNrdCWivYkw0IfvpOZmLvsVgghmMIof4Y 8U4T+p9kyw2aezqBftGbncxGHcwIErZWAaYUG7gnt00jX5Nfr2Xg6Fu3LCSwge0U g5pECfZdmlCMHRsjVm+K2j01a7QWOwzLCFuPZKhMVThazYeaP8YMqSpVLYihwGnG ntIMz0s1iLe8T+PD/+Y/nNzMi2VM5YQ5TSq8Hhbc/DQGUBhn2nesCdhKWGV5UEUK qx62XOlSdClZxweShi3ewNfmqqsRaewF5kjZRPj88UBqWvxCQg8LsqzKQDbuSbIN tj6dvyA9jT8r4DbhLw+VQnczihQR5sZiEC6fre2yD0pTX/3vCYy9BVQqfkFYRcMh 6Uv5O+gfwCrO/QW7seq1wt9ReGCWG3liskakwszlHnAnYiQcY6QA3035M8KpdQ5x kko69pCpAqaRYP3RKXda//naTzWLNApRa0aOk1RcDQbBSKVEedSqbCPcAWu8nyYl jFff14YvJ8vVxUK1JMd4XJxJx1iaPSsuvWaSWxFeItO6TbNQxww= =kBIp -----END PGP SIGNATURE----- --=_XJcTNEGi5tSrLXujDCZB1br-- From nobody Thu Apr 13 06:56:47 2023 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 4Pxr3Y5GvTz45bt7 for ; Thu, 13 Apr 2023 06:56:57 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Received: from mail.stormshield.eu (mail.stormshield.eu [91.212.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stormshield.eu", Issuer "Stormshield Servers CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pxr3X1W2bz45Z7 for ; Thu, 13 Apr 2023 06:56:55 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=signer header.b=Svc8ibxU; spf=pass (mx1.freebsd.org: domain of Stephane.ROCHOY@stormshield.eu designates 91.212.116.25 as permitted sender) smtp.mailfrom=Stephane.ROCHOY@stormshield.eu; dmarc=pass (policy=quarantine) header.from=stormshield.eu DKIM-Signature: v=1; a=rsa-sha256; d=stormshield.eu; s=signer; c=simple/simple; t=1681369008; h=from:subject:to:date:message-id; bh=598jaugNP1jRA8dGtBYKSNzDNqm0zYY3/fL1JbvCk4M=; b=Svc8ibxUESQh9nYrOdinugCATkBeosRnh3RL+Gb812r0zLUePyP49qIiVNSIDwQmsCS/k8Kt+rs xN8zCiLJeByKHzvO8bf6JfMZGUAFt+n7bRqk8oK+6jK31FvRecLrbp1MzUuOm7QHKXR74Pr9TV4zB JTqJYPRajDKo/WZaSu2AVQC5DXACqvJCgdaQ4KTgXsdUTNr3MKCjXby1e1QUEv6zm04t9tbPD8K/e 7d4OZ1inspEi7BvxO4Gpo81p4soV8r37u3ryieqJZIS9IMJ9XCOPb+zi1F3qQlNJsoI+uZhpNricN 3wor3TmbnDEBIl1MJRobVzU8NB5df2hLLwvA== Received: from cthulhu.stephaner.labo.int (10.2.16.1) by ICTDCCEXCH001.one.local (10.180.4.1) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Thu, 13 Apr 2023 08:56:48 +0200 Received: by cthulhu.stephaner.labo.int (Postfix, from userid 1001) id E70191FDC9; Thu, 13 Apr 2023 08:56:47 +0200 (CEST) References: User-agent: mu4e 1.2.0; emacs 27.1 From: Stephane Rochoy To: Subject: Re: Status of Alder and Raptor lake on FreeBSD Current In-Reply-To: Date: Thu, 13 Apr 2023 08:56:47 +0200 Message-ID: <86edooi828.fsf@cthulhu.stephaner.labo.int> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.2.16.1] X-ClientProxiedBy: ICTDCCEXCH001.one.local (10.180.4.1) To ICTDCCEXCH001.one.local (10.180.4.1) X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=signer]; R_SPF_ALLOW(-0.20)[+ip4:91.212.116.25]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; HAS_XOIP(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR] X-Rspamd-Queue-Id: 4Pxr3X1W2bz45Z7 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Dries Michiels writes: > I was wondering what the status of Alder/Raptor lake support is=20 > on FreeBSD? > Does it boot? Integrated graphics are supported from what I=20 > recall with the > newest drm drivers. > Are there any plans for changes to our scheduler to account for=20 > efficiency > and performance cores? > Are there real world downsides of not having such a scheduler=20 > when running > an Alder or Raptor lake CPU? > > Interested to hear from users using these CPU's right now in=20 > there system! > The Reason I ask is that I'm interested in upgrading my home=20 > server > hardware :-). Hi, AFAIK, last status was given by Mike Karels (karels@) on Feb 7, 2023 on freebsd-stable@ [1]. I'm also interested in any news on the topic :) [1]=20 https://lists.freebsd.org/archives/freebsd-stable/2023-February/001103.html Regards, -- St=C3=A9phane Rochoy O: Stormshield From nobody Thu Apr 13 07:04:26 2023 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 4PxrDM3TYQz45cSF; Thu, 13 Apr 2023 07:04:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PxrDM1xxPz4Gvd; Thu, 13 Apr 2023 07:04:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id mdvup8Jikjvm1mr0PpA4Ij; Thu, 13 Apr 2023 07:04:29 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mr0NpjqeLyAOemr0OpcT3T; Thu, 13 Apr 2023 07:04:29 +0000 X-Authority-Analysis: v=2.4 cv=e5oV9Il/ c=1 sm=1 tr=0 ts=6437a97d a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=8nJEP1OIZ-IA:10 a=dKHAf1wccvYA:10 a=VxmjJ2MpAAAA:8 a=CjxXgO3LAAAA:8 a=YxBL1-UpAAAA:8 a=kDZLfgLDAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=kahnpYOlYw8TZN4Y7l8A:9 a=wPNLvfGTeEIA:10 a=LyydU4Oes_UA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=Aez1uqWRNYMWVBb44gMB:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id C7047A47; Thu, 13 Apr 2023 00:04:26 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 8A54F25A; Thu, 13 Apr 2023 00:04:26 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Mark Millard , Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pawel@dawidek.net, pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: <20230413064252.1E5C1318@slippy.cwsent.com> References: <20230413055221.E8B211F0@slippy.cwsent.com> <20230413064252.1E5C1318@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Wed, 12 Apr 2023 23:42:52 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 13 Apr 2023 00:04:26 -0700 Message-Id: <20230413070426.8A54F25A@slippy.cwsent.com> X-CMAE-Envelope: MS4xfDW1U4wOl8PpVSdbzcrob7O+642sN8+uc4pGtrEjSS7AP2D9093BZW21qNUGquzta+VOp5v+vWMEkO6gJwXMe5F02zvxvxxN8iv+5SPKcXgKGZ0ZU/7H hOyUYRStgZKdY7mRV/tmEye84z02L3iFRYFo2YXTd2+JPRKxvQ6y5ljiI9z0oWbClUCfLFtYjC2f6cJFr93vn6tcZjruSVb8Z5uZLbun/GVPwbfnblviIwQq ew+PDWhKR70Ovl4HiH2ibUKLpRS+96pgj+K/p0fXvJ0wNSVGGAgPW+0Ut6RtzacWBPlyuacAcDU+CLJO81u6txlnuLESJnvn8nnU+4rF9ydgTR+mU08Gf67e KzGqicr3YZQ47qC0gNZySaPT1Z5yzky5Y+4SH0LUe1clhhbYU0k= X-Rspamd-Queue-Id: 4PxrDM1xxPz4Gvd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <20230413064252.1E5C1318@slippy.cwsent.com>, Cy Schubert writes: > In message , Mark Millard > write > s: > > [This just puts my prior reply's material into Cy's > > adjusted resend of the original. The To/Cc should > > be coomplete this time.] > > > > On Apr 12, 2023, at 22:52, Cy Schubert = > > wrote: > > > > > In message , Mark = > > Millard=20 > > > write > > > s: > > >> From: Charlie Li wrote on > > >> Date: Wed, 12 Apr 2023 20:11:16 UTC : > > >>=20 > > >>> Charlie Li wrote: > > >>>> Mateusz Guzik wrote: > > >>>>> can you please test poudriere with > > >>>>> https://github.com/openzfs/zfs/pull/14739/files > > >>>>>=20 > > >>>> After applying, on the md(4)-backed pool regardless of =3D > > >> block_cloning,=3D20 > > >>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. = > > Will=3D20=3D > > >>=20 > > >>>> report back on poudriere results (no block_cloning). > > >>>> =3D20 > > >>> As for poudriere, build failures are still rolling in. These are = > > (and=3D20=3D > > >>=20 > > >>> have been) entirely random on every run. Some examples from this = > > run: > > >>> =3D20 > > >>> lang/php81: > > >>> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=3D20 > > >>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D > > >> ${STAGEDIR}/${PREFIX}/etc > > >>> - consumers fail to build due to corrupted php.conf packaged > > >>> =3D20 > > >>> devel/ninja: > > >>> - phase: stage > > >>> - install -s -m 555=3D20 > > >>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D20 > > >>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > > >>> - consumers fail to build due to corrupted bin/ninja packaged > > >>> =3D20 > > >>> devel/netsurf-buildsystem: > > >>> - phase: stage > > >>> - mkdir -p=3D20 > > >>> =3D > > >> = > > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > > =3D > > >> tsurf-buildsystem/makefiles=3D20 > > >>> =3D > > >> = > > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > > =3D > > >> tsurf-buildsystem/testtools > > >>> for M in Makefile.top Makefile.tools Makefile.subdir =3D > > >> Makefile.pkgconfig=3D20 > > >>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > > >>> cp makefiles/$M=3D20 > > >>> =3D > > >> = > > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= > > =3D > > >> tsurf-buildsystem/makefiles/;=3D20 > > >>> \ > > >>> done > > >>> - graphics/libnsgif fails to build due to NUL characters in=3D20 > > >>> Makefile.{clang,subdir}, causing nothing to link > > >>=20 > > >> Summary: I have problems building ports into packages > > >> via poudriere-devel use despite being fully updated/patched > > >> (as of when I started the experiment), never having enabled > > >> block_cloning ( still using openzfs-2.1-freebsd ). > > >>=20 > > >> In other words, I can confirm other reports that have > > >> been made. > > >>=20 > > >> The details follow. > > >>=20 > > >>=20 > > >> [Written as I was working on setting up for the experiments > > >> and then executing those experiments, adjusting as I went > > >> along.] > > >>=20 > > >> I've run my own tests in a context that has never had the > > >> zpool upgrade and that jump from before the openzfs import to > > >> after the existing commits for trying to fix openzfs on > > >> FreeBSD. I report on the sequence of activities getting to > > >> the point of testing as well. > > >>=20 > > >> By personal policy I keep my (non-temporary) pool's compatible > > >> with what the most recent ??.?-RELEASE supports, using > > >> openzfs-2.1-freebsd for now. The pools involved below have > > >> never had a zpool upgrade from where they started. (I've no > > >> pools that have ever had a zpool upgrade.) > > >>=20 > > >> (Temporary pools are rare for me, such as this investigation. > > >> But I'm not testing block_cloning or anything new this time.) > > >>=20 > > >> I'll note that I use zfs for bectl, not for redundancy. So > > >> my evidence is more limited in that respect. > > >>=20 > > >> The activities were done on a HoneyComb (16 Cortex-A72 cores). > > >> The system has and supports ECC RAM, 64 GiBytes of RAM are > > >> present. > > >>=20 > > >> I started by duplicating my normal zfs environment to an > > >> external USB3 NVMe drive and adjusting the host name and such > > >> to produce the below. (Non-debug, although I do not strip > > >> symbols.) : > > >>=20 > > >> # uname -apKU > > >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D > > >> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 =3D > > >> = > > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= > > =3D > > >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > > >>=20 > > >> I then did: git fetch, stash push ., merge --ff-only, stash apply . : > > >> my normal procedure. I then also applied the patch from: > > >>=20 > > >> https://github.com/openzfs/zfs/pull/14739/files > > >>=20 > > >> Then I did: buildworld buildkernel, install them, and rebooted. > > >>=20 > > >> The result was: > > >>=20 > > >> # uname -apKU > > >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D > > >> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 =3D > > >> = > > root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= > > =3D > > >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > > >>=20 > > >> The later poudriere-devel based build of packages from ports is > > >> based on: > > >>=20 > > >> # ~/fbsd-based-on-what-commit.sh -C /usr/ports > > >> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D > > >> devel/freebsd-gcc12: Bump to 12.2.0. > > >> Author: John Baldwin > > >> Commit: John Baldwin > > >> CommitDate: 2023-03-25 00:06:40 +0000 > > >> branch: main > > >> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > > >> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > > >> n613214 (--first-parent --count for merge-base) > > >>=20 > > >> poudriere attempted to build 476 packages, starting > > >> with pkg (in order to build the 56 that I explicitly > > >> indicate that I want). It is my normal set of ports. > > >> The form of building is biased to allowing a high > > >> load average compared to the number of hardware > > >> threads (same as cores here): each builder is allowed > > >> to use the full count of hardware threads. The build > > >> used USE_TMPFS=3D3D"data" instead of the USE_TMPFS=3D3Dall I > > >> normally use on the build machine involved. > > >>=20 > > >> And it produced some random errors during the attempted > > >> builds. A type of example that is easy to interpret > > >> without further exploration is: > > >>=20 > > >> pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse = > > =3D > > >> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > > >> A fair number of errors are of the form: the build > > >> installing a previously built package for use in the > > >> builder but later the builder can not find some file > > >> from the package's installation. > > >>=20 > > >> Another error reported was: > > >>=20 > > >> ld: error: /usr/local/lib/libblkid.a: unknown file type > > >>=20 > > >> For reference: > > >>=20 > > >> [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] = > > Queued: =3D > > >> 476 Built: 2ol: zroot > > >> state: ONLINE > > >> config: > > >>=20 > > >> NAME STATE READ WRITE CKSUM > > >> zroot ONLINE 0 0 0 > > >> da0p8 ONLINE 0 0 0 > > >>=20 > > >> errors: No known data errors > > >>=20 > > >> =08=E0=B9=84=C2=8DM # zpool scrub zroot > > >> # zpool status > > >> pool: zroot > > >> state: ONLINE > > >> scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 =3D > > >> 22:15:39 2023 > > >> config: > > >>=20 > > >> NAME STATE READ WRITE CKSUM > > >> zroot ONLINE 0 0 0 > > >> da0p8 ONLINE 0 0 0 > > >>=20 > > >> errors: No known data errors > > >>=20 > > >>=20 > > >> =3D3D=3D3D=3D3D > > >> Mark Millard > > >> marklmi at yahoo.com > > >=20 > > >=20 > > > Let's try this again. Claws-mail didn't include the list address in = > > the=20 > > > header. Trying to reply, again, using exmh instead. > > >=20 > > >=20 > > > Did your pools suffer the EXDEV problem? The EXDEV also corrupted = > > files. > > > > As I reported, this was a jump from before the import > > to as things are tonight (here). So: NO, unless the > > existing code as of tonight still has the EXDEV problem! > > > > Prior to this experiment I'd not progressed any media > > beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > > > > > I think, without sufficient investigation we risk jumping to > > > conclusions. I've taken an extremely cautious approach, rolling back > > > snapshots (as much as possible, i.e. poudriere datasets) when EXDEV > > > corruption was encountered. > > > > Again: nothing between main-n261544-cee09bda03c8-dirty and > > main-n262122-2ef2c26f3f13-dirty was involved at any stage. > > > > >=20 > > > I did not rollback any snapshots in my MH mail directory. Rolling back > > > snapshots of my MH maildir would result in loss of email. I have to > > > live with that corruption. Corrupted files in my outgoing sent email > > > directory remain: > > >=20 > > > slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=20 > > > 53 > > > slippy$=20 > > >=20 > > > There are 53 corrupted files in my note log of 9913 emails. Those = > > files > > > will never be fixed. They were corrupted by the EXDEV bug. Any new ZFS > > > or ZFS patches cannot retroactively remove the corruption from those > > > files. > > >=20 > > > But my poudriere files, because the snapshots were rolled back, were > > > "repaired" by the rolled back snapshots. > > >=20 > > > I'm not convinced that there is presently active corruption since > > > the problem has been fixed. I am convinced that whatever corruption > > > that was written at the time will remain forever or until those files > > > are deleted or replaced -- just like my email files written to disk at > > > the time. > > > > My test results and procedure just do not fit your conclusion > > that things are okay now if block_clonging is completely avoided. > > Admitting I'm wrong: sending copies of my last reply to you back to myself, > again and again, three times, I've managed to reproduce the corruption you > are talking about. This email itself was also corrupted. Below is what was sent. Good thing multiple copies are saved by exmh. Admitting I'm wrong: sending copies of my last reply to you back to myself, again and again, three times, I've managed to reproduce the corruption you are talking about. >From my previous email to you. header. Trying to reply ^^^^^^^^^ Here it is, nine additional bytes of garbage. In another instance about 500 bytes were removed. I can reproduce the corruption at will now. The EXDEV patch is applied. Block_cloning is disabled. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Thu Apr 13 07:10:32 2023 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 4PxrMH3sRmz45chF; Thu, 13 Apr 2023 07:10:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PxrMH2DSYz4QG0; Thu, 13 Apr 2023 07:10:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id mnQSp9Bhrjvm1mr6IpA4W1; Thu, 13 Apr 2023 07:10:34 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mr6GpJQi4HFsOmr6HpTKil; Thu, 13 Apr 2023 07:10:34 +0000 X-Authority-Analysis: v=2.4 cv=XZqaca15 c=1 sm=1 tr=0 ts=6437aaea a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=8nJEP1OIZ-IA:10 a=dKHAf1wccvYA:10 a=VxmjJ2MpAAAA:8 a=CjxXgO3LAAAA:8 a=YxBL1-UpAAAA:8 a=kDZLfgLDAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=1EHfynvRDzDv6SEXHlQA:9 a=wPNLvfGTeEIA:10 a=tCI1PRuhg74A:10 a=LyydU4Oes_UA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=Aez1uqWRNYMWVBb44gMB:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 2F06BAA8; Thu, 13 Apr 2023 00:10:32 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 18BFF31F; Thu, 13 Apr 2023 00:10:32 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Mark Millard , Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pawel@dawidek.net, pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: <20230413070426.8A54F25A@slippy.cwsent.com> References: <20230413055221.E8B211F0@slippy.cwsent.com> <20230413064252.1E5C1318@slippy.cwsent.com> <20230413070426.8A54F25A@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Thu, 13 Apr 2023 00:04:26 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 13 Apr 2023 00:10:32 -0700 Message-Id: <20230413071032.18BFF31F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfAN0PUpmcKlBumtDvar9Xq23zko3pOE7tmlMv3+AX23f8VBbUUKzTc2xxxyh9MoNLNjdzmTmWb0zkktqKsfV79vJHwtIka0Rbme3xVTNHUGky8Xt7zzA 5OHFc2dEIKmKdSXGcGyQhBtBy+IxMPe75cFBtgGmLZ0B71xZjUSYAont7dIh1D2lSAyqywYcFFcgABX3RBgleX3LxjqwrPqak6ck+cMIMFm2wfxADJ7uUBK5 De9ijGEgtoUQJN6QlFadz6x85NN2dMXONR+T/pZFfTkVN6jqu7kUPwRXP/sV3s7608HzpUPRFj/XFdUZS2uDp3MUSugDq/8KVPDbTJ8J5ppv4ouqfZSPPUdw A4pBGXWCAEiaIWIf/u5xIgiMP8uNoOT8UH82BeHKp9efhxJkRdY= X-Rspamd-Queue-Id: 4PxrMH2DSYz4QG0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <20230413070426.8A54F25A@slippy.cwsent.com>, Cy Schubert writes: > In message <20230413064252.1E5C1318@slippy.cwsent.com>, Cy Schubert writes: > > In message , Mark Millard > > write > > s: > > > [This just puts my prior reply's material into Cy's > > > adjusted resend of the original. The To/Cc should > > > be coomplete this time.] > > > > > > On Apr 12, 2023, at 22:52, Cy Schubert = > > > wrote: > > > > > > > In message , Mark = > > > Millard=20 > > > > write > > > > s: > > > >> From: Charlie Li wrote on > > > >> Date: Wed, 12 Apr 2023 20:11:16 UTC : > > > >>=20 > > > >>> Charlie Li wrote: > > > >>>> Mateusz Guzik wrote: > > > >>>>> can you please test poudriere with > > > >>>>> https://github.com/openzfs/zfs/pull/14739/files > > > >>>>>=20 > > > >>>> After applying, on the md(4)-backed pool regardless of =3D > > > >> block_cloning,=3D20 > > > >>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. = > > > Will=3D20=3D > > > >>=20 > > > >>>> report back on poudriere results (no block_cloning). > > > >>>> =3D20 > > > >>> As for poudriere, build failures are still rolling in. These are = > > > (and=3D20=3D > > > >>=20 > > > >>> have been) entirely random on every run. Some examples from this = > > > run: > > > >>> =3D20 > > > >>> lang/php81: > > > >>> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=3D20 > > > >>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D > > > >> ${STAGEDIR}/${PREFIX}/etc > > > >>> - consumers fail to build due to corrupted php.conf packaged > > > >>> =3D20 > > > >>> devel/ninja: > > > >>> - phase: stage > > > >>> - install -s -m 555=3D20 > > > >>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D20 > > > >>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > > > >>> - consumers fail to build due to corrupted bin/ninja packaged > > > >>> =3D20 > > > >>> devel/netsurf-buildsystem: > > > >>> - phase: stage > > > >>> - mkdir -p=3D20 > > > >>> =3D > > > >> = > > > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/n > e= > > > =3D > > > >> tsurf-buildsystem/makefiles=3D20 > > > >>> =3D > > > >> = > > > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/n > e= > > > =3D > > > >> tsurf-buildsystem/testtools > > > >>> for M in Makefile.top Makefile.tools Makefile.subdir =3D > > > >> Makefile.pkgconfig=3D20 > > > >>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > > > >>> cp makefiles/$M=3D20 > > > >>> =3D > > > >> = > > > /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/n > e= > > > =3D > > > >> tsurf-buildsystem/makefiles/;=3D20 > > > >>> \ > > > >>> done > > > >>> - graphics/libnsgif fails to build due to NUL characters in=3D20 > > > >>> Makefile.{clang,subdir}, causing nothing to link > > > >>=20 > > > >> Summary: I have problems building ports into packages > > > >> via poudriere-devel use despite being fully updated/patched > > > >> (as of when I started the experiment), never having enabled > > > >> block_cloning ( still using openzfs-2.1-freebsd ). > > > >>=20 > > > >> In other words, I can confirm other reports that have > > > >> been made. > > > >>=20 > > > >> The details follow. > > > >>=20 > > > >>=20 > > > >> [Written as I was working on setting up for the experiments > > > >> and then executing those experiments, adjusting as I went > > > >> along.] > > > >>=20 > > > >> I've run my own tests in a context that has never had the > > > >> zpool upgrade and that jump from before the openzfs import to > > > >> after the existing commits for trying to fix openzfs on > > > >> FreeBSD. I report on the sequence of activities getting to > > > >> the point of testing as well. > > > >>=20 > > > >> By personal policy I keep my (non-temporary) pool's compatible > > > >> with what the most recent ??.?-RELEASE supports, using > > > >> openzfs-2.1-freebsd for now. The pools involved below have > > > >> never had a zpool upgrade from where they started. (I've no > > > >> pools that have ever had a zpool upgrade.) > > > >>=20 > > > >> (Temporary pools are rare for me, such as this investigation. > > > >> But I'm not testing block_cloning or anything new this time.) > > > >>=20 > > > >> I'll note that I use zfs for bectl, not for redundancy. So > > > >> my evidence is more limited in that respect. > > > >>=20 > > > >> The activities were done on a HoneyComb (16 Cortex-A72 cores). > > > >> The system has and supports ECC RAM, 64 GiBytes of RAM are > > > >> present. > > > >>=20 > > > >> I started by duplicating my normal zfs environment to an > > > >> external USB3 NVMe drive and adjusting the host name and such > > > >> to produce the below. (Non-debug, although I do not strip > > > >> symbols.) : > > > >>=20 > > > >> # uname -apKU > > > >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D > > > >> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 =3D > > > >> = > > > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm > 6= > > > =3D > > > >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > > > >>=20 > > > >> I then did: git fetch, stash push ., merge --ff-only, stash apply . : > > > >> my normal procedure. I then also applied the patch from: > > > >>=20 > > > >> https://github.com/openzfs/zfs/pull/14739/files > > > >>=20 > > > >> Then I did: buildworld buildkernel, install them, and rebooted. > > > >>=20 > > > >> The result was: > > > >>=20 > > > >> # uname -apKU > > > >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D > > > >> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 =3D > > > >> = > > > root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm > 6= > > > =3D > > > >> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > > > >>=20 > > > >> The later poudriere-devel based build of packages from ports is > > > >> based on: > > > >>=20 > > > >> # ~/fbsd-based-on-what-commit.sh -C /usr/ports > > > >> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D > > > >> devel/freebsd-gcc12: Bump to 12.2.0. > > > >> Author: John Baldwin > > > >> Commit: John Baldwin > > > >> CommitDate: 2023-03-25 00:06:40 +0000 > > > >> branch: main > > > >> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > > > >> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > > > >> n613214 (--first-parent --count for merge-base) > > > >>=20 > > > >> poudriere attempted to build 476 packages, starting > > > >> with pkg (in order to build the 56 that I explicitly > > > >> indicate that I want). It is my normal set of ports. > > > >> The form of building is biased to allowing a high > > > >> load average compared to the number of hardware > > > >> threads (same as cores here): each builder is allowed > > > >> to use the full count of hardware threads. The build >> > > >> normally use on the build machine involved. > > > >>=20 > > > >> And it produced some random errors during the attempted > > > >> builds. A type of example that is easy to interpret > > > >> without further exploration is: > > > >>=20 > > > >> pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse > = > > > =3D > > > >> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > 0 > > > >> da0p8 ONLINE 0 0 0 > > > >>=20 > > > >> errors: No known data errors > > > >>=20 > > > >>=20 > > > >> =3D3D=3D3D=3D3D > > > >> Mark Millard > > > >> marklmi at yahoo.com > > > >=20 > > > >=20 > > > > Let's try this again. Claws-mail didn't include the list address in = > > > the=20 > > > > header. Trying to reply, again, using exmh instead. > > > >=20 > > > >=20 > > > > Did your pools suffer the EXDEV problem? The EXDEV also corrupted = > > > files. > > > > > > As I reported, this was a jump from before the import > > > to as things are tonight (here). So: NO, unless the > > > existing code as of tonight still has the EXDEV problem! > > > > > > Prior to this experiment I'd not progressed any media > > > beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > > > > > > > I think, without sufficient investigation we risk jumping to > > > > conclusions. I've taken an extremely cautious approach, rolling back > > > > snapshots (as much as possible, i.e. poudriere datasets) when EXDEV > > > > corruption was encountered. > > > > > > Again: nothing between main-n261544-cee09bda03c8-dirty and > > > main-n262122-2ef2c26f3f13-dirty was involved at any stage. > > > > > > >=20 > > > > I did not rollback any snapshots in my MH mail directory. Rolling back > > > > snapshots of my MH maildir would result in loss of email. I have to > > > > live with that corruption. Corrupted files in my outgoing sent email > > > > directory remain: > > > >=20 > > > > slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=20 > > > > 53 > > > > slippy$=20 > > > >=20 > > > > There are 53 corrupted files in my note log of 9913 emails. Those = > > > files > > > > will never be fixed. They were corrupted by the EXDEV bug. Any new ZFS > > > > or ZFS patches cannot retroactively remove the corruption from those > > > > files. > > > >=20 > > > > But my poudriere files, because the snapshots were rolled back, were > > > > "repaired" by the rolled back snapshots. > > > >=20 > > > > I'm not convinced that there is presently active corruption since > > > > the problem has been fixed. I am convinced that whatever corruption > > > > that was written at the time will remain forever or until those files > > > > are deleted or replaced -- just like my email files written to disk at > > > > the time. > > > > > > My test results and procedure just do not fit your conclusion > > > that things are okay now if block_clonging is completely avoided. > > > > Admitting I'm wrong: sending copies of my last reply to you back to myself, > > > again and again, three times, I've managed to reproduce the corruption you > > are talking about. > > This email itself was also corrupted. Below is what was sent. Good thing > multiple copies are saved by exmh. > > Admitting I'm wrong: sending copies of my last reply to you back to myself, > again and again, three times, I've managed to reproduce the corruption you > are talking about. This email itself was also corrupted. Below is what was sent. Good thing multiple copies are saved by exmh. Admitting I'm wrong: sending copies of my last reply to you back to myself, again and again, three times, I've managed to reproduce the corruption you are talking about. >From my previous email to you. header. Trying to reply:::::::::, again, using exmh instead. ^^^^^^^^^ Here it is, nine additional bytes of garbage. I've replaced the garbage with colons because nulls mess up a lot of things, including cut&paste. In another instance about 500 bytes were removed. I can reproduce the corruption at will now. The EXDEV patch is applied. Block_cloning is disabled. Somehow nulls and other garbage are inserted in the middle of emails after the ZFS upgrade. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Thu Apr 13 08:17:47 2023 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 4PxssC0LHVz44Vkb for ; Thu, 13 Apr 2023 08:18:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4PxssB3qfYz4NDY for ; Thu, 13 Apr 2023 08:18:06 +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=1681373884; bh=C1dOU6e8fSFpVSeCukzP+SV4Erg0Fz19yu+ukYqsJ/g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JvJ7Kumsp/b7t1GXFRW5abhyhyTQ6EF10whtx4XZpwnbE/0hjj8yWureVI9L5a8lIMQGuEPkr7XhJvv7Zu6+kLNaFkhfXQpLywAYcpnIMcqclLPff1LSB5+rH8TrWX4b0Udo1tb7u4xWB9/Mt8NOXD0B2rXDDUrmYdAOaAKbf+DAcG7g1LDuVGmEGCBWJAXOuHCIK3ucUQe7OzWIckZQ2suswbhdWcUJbUtja/a1cQ5KHk1/m3eeiPaFMhG6WxooF06DX6rjVi8fB90S27GtyBnsT82gG4bnY4MpLO9ujYx87ce5p53gzvyaLne9XxjHfLWbNA7O57pKcEU7aL2SKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681373884; bh=m2VQhuuQB1aQDBH3j3gVNC4CS031BpIAfY7HLl4UgGe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gkRXvR1AHdGq5Q6kCHOh0C3atu1s5Q0QcO7gIzuxEGy2OuJ8XC22EpR88aNtJDrYLU65uNukEfR2P791CbtoJ9LzG89PwCAf7JBcw41y3gM1VkkIADKokijC3c2AT9YXtj7nxAfZ/GwTJ+ME7+flnEoeWf0URhrxPtdNUxyi4QspiKuBW3H6GkNEcjUbIU0UmbouC3vUS31uL4TFZCdHHH5N62c+fi9gds3ZNWlda5hnT1F55+Xhmimzi6pRd3t0lDjTrTKqCo47xuMT+7194fSpJ2RR6w89oDpqXNahkOM85mAqJrdI69ExJAkjq0vKUUzZaucTl07OOH2Mlcqk2Q== X-YMail-OSG: us00UUIVM1lhPGKEbMsO3Vo9EMZOMgxwjVUA12qk1w.1QoFFc3H65dyJpegPhOx e5joNi8JF0BlY7koTYLAcQzrXu2eEjgoayScNLWF6NxeYQPTqDKAfwDa.l_W_xXdbkMXdHTsjdGe L6XHOdcVxNaDjRDvdc49NOFwzv.M6Gj87q8.rvL12EJJUPMB8wv4ZE3KDFW409tbJF4PfyjjGRp3 f1ovyoXqYpT0WprV.V3DGuEZzPDH.K8edTqdp8nRVaI48pbdnULYhxKCODs04SIod7iddDbUBXrC 9088CerLN43GcoZmHGKQLUEt7YGL2hUdeg2nxi1jUFF5MK9tPFVqujYA_.unTcUet.u0LeU3TmOj N1cinta9pZaplObxT7KWf.Isgc2shNFc_K_7o2KTvb6K_ZoC6GLmVk7YRjPTpx738E.08DpgWmXR G3_ir19NLhtpDOw4._8_r.By8Ip9AhxMMWFZWuGFuUe3pgddAgrQCmhMBOAIivlmltBbdFbxUODX FBiDySqfHSZZkWN6MS8KrUTtzz6GQ8QSGp8JZgq.zKVGLydCxW7lWA3Exl24HekoNir3X9dbCTfN _RtnTDBGl1yIMjxHopNTGTxhXVtgW2h6PMiRY_nQKNSgzulnr__hLhJ.3QtVbwfY.f3gLmDTITsl gbCGyM0gWOzkMYWdikteXlxQmkQtDM58ch9Vvd2WNycyML2e4qp8I1.CYhL4ApvO41lVwwVfnih. xvZedDVeKQ.UvTiAakjaF8IDAAyWFO4aSPdzftXccsfcZDIgW5UUARR73na9PRDGCK5CkAohwh0Q ktp40pPQROkzkLSsUbA7joyZvVHVfAOxseqelF1SJEUL9g5YcLz0bJotBOaF81bDKQwQFdyLQYkA 35q.uSTfJT4H_r_F1Aw30KIegQuEVvtfT5xpjOq4GX5.oAlxzYnuSc_dwA3uQdAkxfNw4epAB86. 0OmTgyoqYy0h2Zj2mJtYwzbOYcnkruY8nYUJ37yBK7xT8vIO_ZI213gnGd2gkLdfdHFnE9Ay8tNA YrmKqHO2exJWIbrP2Ep2ZYZlJawIVqnHXxKR3CLApNS1s4VE_5Y7ScAxEuUt3Ffu2W8gXRSSs.P_ aGW3tozvuP3JXsiSBDl8IiURgO6W2iB44QErMvA_FpmQfoSoYjGvzJ34UEPW6F.esLGGJ2U4Ijp1 IwxGaaxr9jhplGnDn7itRI4vqjpM196QsDB6bLO4ms6x_MqGKFOMNS4qdTKAY8Z36JSU7Zg__hY8 OqbviH.SOHnzGE32JWQ4SRGyuhuOrC7xEmagyqg5vrvyGzhEQonHi5ov6EnkeKYogVsGy0Dq0mGB RrlZOEBN5FfO8cy9wQn_gdPTkVrkRzhE.nUB0wdpCtJCFPgvAe5IgtcTSUlv5knHAzzJBX7gQn2m PcjIy0965uKHXPhha8XTLnV4Zw1FXNgBQLRjDal10RXyr6eK2qINf4Ln6hzYmZcYGykp68roCqp0 1iTpCkNah8fHdlJsaRqaIvLemYfB_XBnhLX69PwXK.jOtalzeWb2yHybGSm6uGYfxdJ5If_hOC5T 16KJTS7ZNgiy3jmBNGYBb9zaHxXegAqvdAxxvEup0m2iCRKAThD4ITUjNlirjua2kGU1orQ5Qr69 A42sAMI779rr.rfqUhk3u_UvpF4KyjZeHU3CUCjVJ0cTmY_ry1O1BA1r8Pf2i2i4YkGBtXx15qyG u_daV.5wypgSEhIQiTeCWzRcz7wDLVtHQIw3HJAWh8vrkpLR07QBA0YEYkUB0K15Imv0b2fC0N4O uxIBpA4pjNRes.SlGm2_E6nPLkEgE3PcINKJs6mVNwvtcX_tDPuOC6kaxeHmi1.zOr3u19U_8toZ xRll8MhfX8LNIKDD_GV6mVcOMnENiRi3t64BYRjSgBnYPnnn34v_NqW5JsKNXai6aLrgO1dAs3Qc lIxj3Hs49NJb7jxaLBsdHgJ6k1oTT4slZOCYjDAjVwGQFnUm3a15YBnMyH4Md84fFOQSh.r.b2Vb h3PKYZhLU431L.abvDrvC5.pPUE1S8YIF4qKxhKdCWQmhqxezm1UTKg2bC0_NbCx8UgGDSADQRVa rtudwisvt.riBbyUB5FJj__L7.Pf_O08bdn85r3ZWmLCGDD6E29LWPoRaMqqIQ6DqGJtIUGITYac iZE8u0I8QjmZTB.tgPf4BQ6sMuwotO2CZhfiB2kI0WtAfxJpbFivmUkeMiecn.QGeIO9VjoefLww uEE8V5vlA2ejJZExzVeJkbO5iKGf9quUqcugUfaCHmZz2UZIZX84pRS6WXnFOxibNOcbNmae7jJJ .YaosNy8- X-Sonic-MF: X-Sonic-ID: e25b280d-d20b-498c-a59f-027cfa4446b1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Apr 2023 08:18:04 +0000 Received: by hermes--production-bf1-5f9df5c5c4-fgkgh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 236d662cbf8a2ac996c8884c5ed1f944; Thu, 13 Apr 2023 08:18:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <20230413085253.Horde.bYgKkPjxGfDPP_pwWqnyTN2@webmail.leidinger.net> Date: Thu, 13 Apr 2023 01:17:47 -0700 Cc: Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , Cy Schubert Content-Transfer-Encoding: quoted-printable Message-Id: <10AB86BC-FECC-40B2-AF09-AF1732D819E3@yahoo.com> References: <20230413085253.Horde.bYgKkPjxGfDPP_pwWqnyTN2@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PxssB3qfYz4NDY X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 12, 2023, at 23:52, Alexander Leidinger = wrote: > Quoting Mark Millard (from Wed, 12 Apr 2023 = 22:28:13 -0700): >=20 >> A fair number of errors are of the form: the build >> installing a previously built package for use in the >> builder but later the builder can not find some file >> from the package's installation. >=20 > As a data point, last year I had such issues with one particular = package. It was consistent no matter how often I was updating the ports = tree. Poudriere always failed on port X which was depending on port Y = (don't remember the names). The problem was, that port Y was build = successfully but an extract of it was not having a file it was supposed = to have. IIRC I fixed the issue by building the port Y manually, as = re-building port Y with poudriere didn't change the outcome. >=20 > So it seems this may not be specific to the most recent ZFS version, = but could be an older issue. It may be the case that the more recent ZFS = version amplifies the problem. It can also be that it is related to a = specific use case in poudriere. In my procedure I'm building the same versions of the same ports that I'd built in the pre-ZFS-import context, just in my jail for experiments instead of in the jail for normal use. (So I still have the original package files available.) I am working a distinct media that started as a copy of my good context. In other words, I was reporting differences with the known-status as shown by prior builds of the same /usr/ports/ tree. The difference is just my progressing FreeBSD's version. I'm even using the exact same machine to do the builds, but with distinct media. (My good environment's FreeBSD still predates the zfs import.) > I remember a recent mail which talks about poudriere failing to copy = files in resource-limited environments, see = https://lists.freebsd.org/archives/dev-commits-src-all/2023-April/025153.h= tml > While the issue you are trying to pin-point may not be related to this = discussion, I mention it because it smells to me like we could be in a = situation where a similar combination of unrelated to each other FreeBSD = features could form a combination which triggers the issue at hand. My procedure eliminates this alternative. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 13 09:42:57 2023 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 4Pxvl80qM1z44d8s for ; Thu, 13 Apr 2023 09:43:00 +0000 (UTC) (envelope-from danilo@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 4Pxvl73hM4z3MbL for ; Thu, 13 Apr 2023 09:42:59 +0000 (UTC) (envelope-from danilo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681378979; 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=A777V/OQMH/wCXiERmZs+VcN4EZtzYLfOJ7lG5UajCk=; b=gAWJ0dz8MDHb2/+gSgZkMxaKBPZh6eu4MH/i/PmolrsqLZtf047R/i8ZGVXasNiAkCmDHL hk1FdDabaLgkm3Kz8u19JsAqBo4siDV/UEJ68hhdOUdtYp9/UnNqwq4S5pQzprfN+LrA+6 BhNe5hRfLQAqioyk34NhNqzEzRyw/74bLFGlOEtcCFYZOg0TWJr4ISnzuovvLfABICuTZA 28AeDGGbMNqN5TgcH4nA/yyJqlbIFCYhZ4J5QJ29lT23lFj+iVmKaMljO/WVfuiUSFYnj0 sDIYYMjiech9TKMW0OwEYUMhuubFCnUO++8VL1Vk61iXqjCSOMUWpnPfxt3WfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681378979; 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=A777V/OQMH/wCXiERmZs+VcN4EZtzYLfOJ7lG5UajCk=; b=DKVTt2oPJdr9nrtZwUMLJU1AB15XkbwvqqJWagz6DULDjj3+mh9BtRkjFQOqrol9rna3+E K1kISxfMY8ww14vX14vR6d6ol5lLiUvLZRp51yhBKbj1ZDzi2yuCcezKDicbj0kIif2gFh DhGUybtUZ277pG2xEGd8guSZHo8B5/ZvlNGfbB9tX2VlQ7+8cz8ZFotgOHQSXORtSCEwiM lrAIFz+Dy+BEck9PLBHkOSCe9Da1K6VRclpd93+jXnsn5kPN1YutA3Ij6DzxKDf1EEnga7 zRBA14oXCD9lRU5pk5Hgyc/4+4a+uDmKBQEWWirbm8SsBrV7NpvGAJNvAxBPxQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681378979; a=rsa-sha256; cv=none; b=K/vIoqRF1LV/YQrdFDznneYp3q/tEaMmgMoHkySseOA3LopHA4CPPKe/XtKp5lfnJ2Iky2 DMZgYybEgaTlQIF2u//OsvgFAbvWnoDto1LNI2WMgyT9OIs6klgolUFeSju7a/xrulJcKV s1+4ULnMF6CEb5N32sClRKNZYVDY3jcOfLGN+OMI4lxTKPHi05SOlSlPctou7Pw17ffIeO x5HXEhnTV7jonl2APXLUZb0pHbXVCe6yghX5JmXzrtdHD192CDWsFKu6RFfwhf3be9TjkX PChlXyVZVHLr3d/F7ri9ABB0ZMwFClAZxnRiSDqZ2hQ3TqvOH8CtMcorybqI/A== Received: from [192.168.5.80] (unknown [37.228.205.220]) (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: danilo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pxvl71L8bzbr0 for ; Thu, 13 Apr 2023 09:42:59 +0000 (UTC) (envelope-from danilo@FreeBSD.org) Message-ID: Date: Thu, 13 Apr 2023 10:42:57 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: freebsd-current@freebsd.org References: Content-Language: en-US From: Danilo Egea Gondolfo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 13/04/2023 06:28, Mark Millard wrote: > From: Charlie Li wrote on > Date: Wed, 12 Apr 2023 20:11:16 UTC : > >> Charlie Li wrote: >>> Mateusz Guzik wrote: >>>> can you please test poudriere with >>>> https://github.com/openzfs/zfs/pull/14739/files >>>> >>> After applying, on the md(4)-backed pool regardless of block_cloning, >>> the cy@ `cp -R` test reports no differing (ie corrupted) files. Will >>> report back on poudriere results (no block_cloning). >>> >> As for poudriere, build failures are still rolling in. These are (and >> have been) entirely random on every run. Some examples from this run: >> >> lang/php81: >> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development >> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf ${STAGEDIR}/${PREFIX}/etc >> - consumers fail to build due to corrupted php.conf packaged >> >> devel/ninja: >> - phase: stage >> - install -s -m 555 >> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja >> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin >> - consumers fail to build due to corrupted bin/ninja packaged >> >> devel/netsurf-buildsystem: >> - phase: stage >> - mkdir -p >> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/netsurf-buildsystem/makefiles >> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/netsurf-buildsystem/testtools >> for M in Makefile.top Makefile.tools Makefile.subdir Makefile.pkgconfig >> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ >> cp makefiles/$M >> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/netsurf-buildsystem/makefiles/; >> \ >> done >> - graphics/libnsgif fails to build due to NUL characters in >> Makefile.{clang,subdir}, causing nothing to link > Summary: I have problems building ports into packages > via poudriere-devel use despite being fully updated/patched > (as of when I started the experiment), never having enabled > block_cloning ( still using openzfs-2.1-freebsd ). > > In other words, I can confirm other reports that have > been made. > > The details follow. > > > [Written as I was working on setting up for the experiments > and then executing those experiments, adjusting as I went > along.] > > I've run my own tests in a context that has never had the > zpool upgrade and that jump from before the openzfs import to > after the existing commits for trying to fix openzfs on > FreeBSD. I report on the sequence of activities getting to > the point of testing as well. > > By personal policy I keep my (non-temporary) pool's compatible > with what the most recent ??.?-RELEASE supports, using > openzfs-2.1-freebsd for now. The pools involved below have > never had a zpool upgrade from where they started. (I've no > pools that have ever had a zpool upgrade.) > > (Temporary pools are rare for me, such as this investigation. > But I'm not testing block_cloning or anything new this time.) > > I'll note that I use zfs for bectl, not for redundancy. So > my evidence is more limited in that respect. > > The activities were done on a HoneyComb (16 Cortex-A72 cores). > The system has and supports ECC RAM, 64 GiBytes of RAM are > present. > > I started by duplicating my normal zfs environment to an > external USB3 NVMe drive and adjusting the host name and such > to produce the below. (Non-debug, although I do not strip > symbols.) : > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > > I then did: git fetch, stash push ., merge --ff-only, stash apply . : > my normal procedure. I then also applied the patch from: > > https://github.com/openzfs/zfs/pull/14739/files > > Then I did: buildworld buildkernel, install them, and rebooted. > > The result was: > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > > The later poudriere-devel based build of packages from ports is > based on: > > # ~/fbsd-based-on-what-commit.sh -C /usr/ports > 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) devel/freebsd-gcc12: Bump to 12.2.0. > Author: John Baldwin > Commit: John Baldwin > CommitDate: 2023-03-25 00:06:40 +0000 > branch: main > merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > n613214 (--first-parent --count for merge-base) > > poudriere attempted to build 476 packages, starting > with pkg (in order to build the 56 that I explicitly > indicate that I want). It is my normal set of ports. > The form of building is biased to allowing a high > load average compared to the number of hardware > threads (same as cores here): each builder is allowed > to use the full count of hardware threads. The build > used USE_TMPFS="data" instead of the USE_TMPFS=all I > normally use on the build machine involved. > > And it produced some random errors during the attempted > builds. A type of example that is easy to interpret > without further exploration is: > > pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > > A fair number of errors are of the form: the build > installing a previously built package for use in the > builder but later the builder can not find some file > from the package's installation. > > Another error reported was: > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > For reference: > > [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] Queued: 476 Built: 252 Failed: 11 Skipped: 213 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 00:37:52 > > I started another build that tried to build 224 packeges: > the 11 failed and 213 skipped. > > Just 1 package built that failed before: > > [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | sqlite3-3.41.0_1,1: Success > > It seems to be the only one where the original failure was not > an example of complaining about the missing/corrupted content > of a package install used for building. So it is an example > of randomly varying behavior. > > That, in turn, allowed: > > [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 > > to build but everything else failed or was skipped. > > The sqlite3 vs. other failure difference suggests that writes > have random problems but later reads reliably see the problem > that resulted (before the content is deleted). > > > After the above: > > # zpool status > pool: zroot > state: ONLINE > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p8 ONLINE 0 0 0 > > errors: No known data errors > > # zpool scrub zroot > # zpool status > pool: zroot > state: ONLINE > scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 22:15:39 2023 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > da0p8 ONLINE 0 0 0 > > errors: No known data errors > > > === > Mark Millard > marklmi at yahoo.com > > Hi, I'm having a funny issue here and I'm wondering if it is related. When building one of my ports I will, eventually, not always, get a file full of zeros as a result. The build will create copies of crispy-setup and, every once in a while, one of them will be a blob of zeros: I'm running the recent ZFS update but I never upgraded my pool: FreeBSD capeta 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n262091-eed92455e600: Tue Apr 11 16:06:42 IST 2023 danilo@capeta:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 cp crispy-setup crispy-doom-setup --- crispy-heretic-setup --- cp crispy-setup crispy-heretic-setup --- crispy-hexen-setup --- cp crispy-setup crispy-hexen-setup --- crispy-strife-setup --- cp crispy-setup crispy-strife-setup $ ls -l work/stage/usr/local/bin/crispy-*-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-doom-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-heretic-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-hexen-setup -r-xr-xr-x  1 danilo  wheel  923488 Apr 13 10:10 work/stage/usr/local/bin/crispy-strife-setup $ file work/stage/usr/local/bin/crispy-*-setup work/stage/usr/local/bin/crispy-doom-setup:    ELF 64-bit LSB executable... work/stage/usr/local/bin/crispy-heretic-setup: ELF 64-bit LSB executable... work/stage/usr/local/bin/crispy-hexen-setup:   data work/stage/usr/local/bin/crispy-strife-setup:  ELF 64-bit LSB executable... $ hexdump work/stage/usr/local/bin/crispy-hexen-setup 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00e1760 From nobody Thu Apr 13 11:04:57 2023 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 4PxxYk3Hw4z44mn5; Thu, 13 Apr 2023 11:04:58 +0000 (UTC) (envelope-from vishwin@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 4PxxYk2WrZz3PLC; Thu, 13 Apr 2023 11:04:58 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681383898; 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=jc3oYf4fXTD/yFk4LugxhsBgEpe+W6ofOjINkwJB2hI=; b=UsIWl3STBmfSgNtppMYEyAuLiYskYkO6GfWCKOom15qFePi/9ngo8xMp7Jh7oCVR8P5U7T W/Ci2cHv6A97rCt694mATX9Pxkf415PlCmTF+CmF9Nqqcx3MFIXrv8sxcmUPp4qul18env 4HXsEhuxNOF1hyRweEx/CTAeaYFc20i8qmDD83Yf84Nj6M7C/MNzxNelGg0rtBzFH6XK0/ 34ufIdHACP3d/AxVpZSgne37EGopXuqYvmtcvf3xoBrspPRPaaxArsQMppCzTQwQ78Pmh5 E2a4D31z4cLvqBf0uAc1xxSSzTgni9AuBdizfjlzg7s8hchCl5Tt5SDwyzwTdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681383898; 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=jc3oYf4fXTD/yFk4LugxhsBgEpe+W6ofOjINkwJB2hI=; b=BGNsL3Lx7b4V7JBeqw0VGy7GrZp+nmnErXQoQ8Knq7PG0oxXcecJB1XHqqXfMKQj69hZ4I QY+GdhOdc1fV6ctZ2PbkBGPQsm1gIQR4tt2D3obgZkpqw9L/8LtJyzPIVNoUHz7JYYoJqw J7fQyMxGtnAqscStRGL6dMfi9irjm60i6/8c2ed+rR5YZWbTyVHxnl2CLOrDGk0SdSsAHT TCd6UU1FoDK7mdWYtY9zdleVwzw3WrW5RtzoDk28pTah9Fj2XAz2McWjm4PgON6LPR4G+V pFQXmm4EcNLjmmZgAvYHbLAn9hxHvJ2q4tQphlYWgrgiQmy4TfCpYtXDd7HReA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681383898; a=rsa-sha256; cv=none; b=hf7SUzsxjcLhYKrZFCpbf+myb0HDkG84m3x0TAwPjZl06LhTyuHXg4aFL/xL4WzentTO1g 6NLCCFVx8pqYBndNOYItXImzJ5wN/0WniCIy4oLWoSIjD3EBnDoAmD4YOtdYadp+JYcDKZ dX4YFmICZ44YQ+9HGNkqLa+eoMXpjE9M9FR4x7GlzGNFXxZurBdAWHVp7pLURvCLNJCDmL mhVKuHxEgn7RdWTnCFHj5G4ozcu202UJEDhRvtVI1Tqe1BytBCMu7MySlAdvjs7B8ME412 NrO8CWnxsLvsE1rxo1KwEl8G3Nz9UtN3/T7TyIPJK7DzgIaHal3OF5iX+wu7Vw== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PxxYj6b9szd9Y; Thu, 13 Apr 2023 11:04:57 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: Date: Thu, 13 Apr 2023 07:04:57 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: =?UTF-8?Q?Pawe=c5=82_Jakub_Dawidek?= , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org References: <20230413071032.18BFF31F@slippy.cwsent.com> From: Charlie Li Organization: FreeBSD Project In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------UKCQp4ej4cOAKv08aye80fKU" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------UKCQp4ej4cOAKv08aye80fKU Content-Type: multipart/mixed; boundary="------------fpdu0TTcHiqeNaThx660EQD6"; protected-headers="v1" From: Charlie Li To: =?UTF-8?Q?Pawe=c5=82_Jakub_Dawidek?= , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> In-Reply-To: --------------fpdu0TTcHiqeNaThx660EQD6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGF3ZcWCIEpha3ViIERhd2lkZWsgd3JvdGU6DQo+IENhbiB5b3UgcGxlYXNlIHRyeSB0aGlz IHBhdGNoOg0KPiA8aHR0cHM6Ly9naXRodWIuY29tL29wZW56ZnMvemZzL3B1bGwvMTQ3Mzk+ DQo+IA0KPiBVbmZvcnR1bmF0ZWx5IEkgZG9u4oCZdCBzZWUgaG93IHRoaXMgY2FuIGhhcHBl biB3aXRoIGJsb2NrIGNsb25pbmcgZGlzYWJsZWQuDQo+IA0KVGhpcyBwYXRjaCBtYWRlIG5v IGRpZmZlcmVuY2UgaW4gcG91ZHJpZXJlOyBjb3JydXB0aW9uIHN0aWxsIHJvbGxlZCBpbi4N Cg0KLS0gDQpDaGFybGllIExpDQrigKZub3BlLCBzdGlsbCBkb24ndCBoYXZlIGFuIGV4aXQg bGluZS4NCg0K --------------fpdu0TTcHiqeNaThx660EQD6-- --------------UKCQp4ej4cOAKv08aye80fKU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ34dkFAwAAAAAACgkQ/reFK+KbPofd 6w//RmNDw6vl+XQnOZ2CjOxRYHRzERFg3WK+9pSpVREwAizB/lFXU3WxIHWveoWpRxTeufK2sN7K +nsZaMH7jbKYjE82zD4DczZLR2d+HquHVFiJzYKX3UnZk3ILJYGTCuEchQHj47rIlWj5Pi7s0OZT ZDoh306YMYKEztkdA46OuGOWZhgp9ltYtMvZRcCSm2nLMPz7NQ8V52//yltGjsT4rFcjX9leRi4k CyM0bu71up7qUDcZZT2r0N1R5BkQxYinBt6n4/t0zdfwcZL3qI26G0mFI2oEStj094We3+P3tnaZ l0O1j8NFn5V7Sf64oacYYUZuz1ibD/09e3SzZwg6GX7Dhh9O+uO7BF7uJ3oHVLk4z00B89hoEdqo Kdg+IzRPLrp0bf38D/gX1zmQ3RRHRMD24vg4Oz0oGeZgEuOdv5EWK1SU4h769Pi+y0anvobHahR+ SeUGLWjcrDL5EDwFi10acueOSpxAuq8g85VuSuxmsOiX7raETKRjFN/qR7JvR0IPdlBKPIVElPNI 6wnNuteHQFC2SDG3fvxp8urN7KxEPNdW6sUn04CXWiNQ9vQuvfCUJ+2a9CUE45cf2eITEzZU6mHJ vUlOW31FCgg3nKa+e7yCYbZ8ulEvka6ROoWXdcHdB0mijHNiRPteTFhib2SKJPtQgrLJz+W4fy1y pjA= =zWTB -----END PGP SIGNATURE----- --------------UKCQp4ej4cOAKv08aye80fKU-- From nobody Thu Apr 13 11:36:31 2023 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 4PxyG91585z44qVl for ; Thu, 13 Apr 2023 11:36:33 +0000 (UTC) (envelope-from vishwin@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 4PxyG900Npz3GQR; Thu, 13 Apr 2023 11:36:33 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681385793; 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=oaQBxJnCkh7A5dIXckVqcCq/ZbKgKxB+VnZc8dEUtOw=; b=Pplnnd1JqD1PX+pR7TwbGG0gYydwnh3rDBDKWgV4YQZqJVCs21zfgyxFAWl4r3c3NPfaJT 7E9I+0kWYM74qVc/hXy/MCI78uamrXYhfTdKE3FKeUGEvqciXoa+xp1o3ilv2MTArK4yGW Mpn4/ngTy9kM+Gbu3373Oj/6/dG/sff6py5Dbrz6SD9tsjCC2Sg7MGrhd+qP+uHD/RnUUo Dg2kB18RmEogJs3Wo3hwpACDJXzTwKKmkGW/riw8M82j0oMA9xhtzwCNtz5irvt0M1QG7C lQMS3d+3CsHeQT19hauwgDVMB6RdKWCEey1MHPJ+i+iY3u2WapYmOoblgxNO0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681385793; 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=oaQBxJnCkh7A5dIXckVqcCq/ZbKgKxB+VnZc8dEUtOw=; b=YmGKik8RgLXG5YQ/o/ZfG3eUz1ogo9PO0rbUIRi+nqjYkd5KYew50kNiR75wEN9vFKtHI4 LMsJH6jwCJnZQtoMCO/7HFQ1n4Y6FTdCmHTxbKijm5OeQhucbsiu3oPRh1+gdCNEen9+Ne 1WMaJkHdV3Yu8QGqKPVGJ8dSy/HAFHn01pn4QV5EjIvgnB0aNxGZ5hFtMW+eqakf+Pc7o0 uO1HOhxxkdi+I95ztrzzeWsLPyXHgGQNfwI2+eN2VrRJHO+V6yTkzpJVGh/RKc8/lxBIYd 2rXcnKvQYvDzjarOMqr5Pg42mHedaG2lr0iWi7/4SBDrpKISHVq/D8HrwcQqUQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681385793; a=rsa-sha256; cv=none; b=IvC1eyQSNqtioWSrNPFQXZgI75cnV3FNwuORLJgZ7kABT0wTILjirdIpwbjiqRMcZWLTXT YiznUeyhmiHzO1rohLPt9Z/Bs5nK8QNW4siJpJ1Sjh1YWU4x97T6XYawOFAuVeDEjdCCbP yB6oiDlc9BCme0/KA1sHAwd9SudpDGLgTbnMatTqer3F/kK6wr4rWSVKU6rGb9TWj1mbRP eDT4xOsBU0Lz9utCgOtcyt2Q8LCqHHy9P4TbTf/zl0joOZd89ESCsdfSk/gLhgWPEImoGo BQ4u73i6lbfL/tWIDOSZJ8mX/NLZaqK3mdBWffLjkxi+oeyMhztQpxFdnb2ypA== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PxyG855Ygzdny; Thu, 13 Apr 2023 11:36:32 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: Date: Thu, 13 Apr 2023 07:36:31 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Danilo Egea Gondolfo , freebsd-current@freebsd.org References: From: Charlie Li Organization: FreeBSD Project In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------b3b6cGkmsUnKnoyH2aNmO7iw" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------b3b6cGkmsUnKnoyH2aNmO7iw Content-Type: multipart/mixed; boundary="------------74A3I1yZUIawl1a8hh6qfvIE"; protected-headers="v1" From: Charlie Li To: Danilo Egea Gondolfo , freebsd-current@freebsd.org Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: In-Reply-To: --------------74A3I1yZUIawl1a8hh6qfvIE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGFuaWxvIEVnZWEgR29uZG9sZm8gd3JvdGU6DQo+IEknbSBoYXZpbmcgYSBmdW5ueSBpc3N1 ZSBoZXJlIGFuZCBJJ20gd29uZGVyaW5nIGlmIGl0IGlzIHJlbGF0ZWQuDQo+IA0KPiBXaGVu IGJ1aWxkaW5nIG9uZSBvZiBteSBwb3J0cyBJIHdpbGwsIGV2ZW50dWFsbHksIG5vdCBhbHdh eXMsIGdldCBhIGZpbGUgDQo+IGZ1bGwgb2YgemVyb3MgYXMgYSByZXN1bHQuDQo+IA0KPiBU aGUgYnVpbGQgd2lsbCBjcmVhdGUgY29waWVzIG9mIGNyaXNweS1zZXR1cCBhbmQsIGV2ZXJ5 IG9uY2UgaW4gYSB3aGlsZSwgDQo+IG9uZSBvZiB0aGVtIHdpbGwgYmUgYSBibG9iIG9mIHpl cm9zOg0KPiANCj4gSSdtIHJ1bm5pbmcgdGhlIHJlY2VudCBaRlMgdXBkYXRlIGJ1dCBJIG5l dmVyIHVwZ3JhZGVkIG15IHBvb2w6DQo+IA0KVGhpcyBpcyBleGFjdGx5IGl0LiBUaGUgY29w eSBvcGVyYXRpb24gd2l0aGluIHRoZSBzYW1lIGRhdGFzZXQgd2lsbCANCnNvbWV0aW1lcyB0 dXJuIHVwIGNvcnJ1cHRpb24gYW5kIHJhbmRvbWx5LCBzbyBub3QgdGhlIHNhbWUgZmlsZShz KSBnZXQgaGl0Lg0KDQotLSANCkNoYXJsaWUgTGkNCuKApm5vcGUsIHN0aWxsIGRvbid0IGhh dmUgYW4gZXhpdCBsaW5lLg0KDQo= --------------74A3I1yZUIawl1a8hh6qfvIE-- --------------b3b6cGkmsUnKnoyH2aNmO7iw Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ36T8FAwAAAAAACgkQ/reFK+KbPoet CQ/8DVejL8HOddJ4U2l8W83THjQx0NVFHitaHVCxhveU/RCEPpYesqujreOCs2zuOno7kxdeZ1Ah FCcYCW7TM3H3nxYalzZ9AhqfmwnR0YPv6lAq75RUD2Lb1eHvOgVLsWyTQYiX3Wb80cxEf2FfeFeo 1H3fkaYqhjvGewxYPPcAoOlVFLh6t+kqf8Cj7rZy6cS7uIkdC20tL7I43j+ZfVcrNG3O3ahJpFgD 6gm7uiQJsOc6iNqjz0vRRb4PPg5QjgvSIpeRdQmasrVXr1LkbdfT5RpPRjt3PMhkvwZ/a7jsTpN7 nDr40J4kexc7dY8zxnBnMMpM2okcuQLGi1TTIy7/y3r0xJjB7e1sHpjmB2TKE7Yuum3HAwJmPfA0 Ju1DdM6OmXVoBXrugXrceDrKBi3Qrags9lmc8UTSgPz/yKAXjIO60orn8V4qKMqyAhze4LI3MFLL XoBUyDy54nARQJFERA0Iru9hP70A33SCkfceOhzO/+Om/LTKATJvJRmpSfmeJPqZcy9ICtgmVpFI /cWXHOCPN7LFcIL00zmykuUiLMC8jg0bpoQ2go6pVUGmTPpIK2j2GGJb2IMbGsgokqZfzwb+1n0H qiA4mA2PRDJKj8M+kH4x8ZcNwjVU9EsyTacaf7u282Kk0mZDrXEE2clWjuo/4YGU/8MaoTTjfci9 C/U= =NiXW -----END PGP SIGNATURE----- --------------b3b6cGkmsUnKnoyH2aNmO7iw-- From nobody Thu Apr 13 13:25:56 2023 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 4Py0hk1l4Tz450wQ for ; Thu, 13 Apr 2023 13:26:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (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 4Py0hh5RtZz4SVr for ; Thu, 13 Apr 2023 13:26:12 +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=1681392371; bh=hX96yStHZUlFMdbWl043umvAmyXPama4W72l75gNeTo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KmnObWmS7e2WNihU/73tYtWGufJcPg7yEEaEDauYhZVnW2FbLohIj13qZ2oypww2n+I8MtQvbonnhKPuUc2PeQIGN1A0q7Ng/XLca2ITjkMo/S9a7vznjeNhwVNXeEUOzbVBEbnRl+6axiSafmZxAc+0YL8i7Fe1EOs2yknR6L2G1vSk8tu0sTW6+N1EDBR01PLv8nzbBxZ5WbjIecHX/5cXnOv/7nqVaflgWVKuMj0e6/aule5DSFzSpFZCy3iYXtyqNaaKDUbQVL5dbzAbi2tXmcLlCZapeaNm9e5GDGVqn7fAU1B40U4/adV/PWiML8Tq677xu4wR4ArLYLYgDQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681392371; bh=g8FU5jPnJN5nQLS12favE5Ng97OOV76KYIrGsN6+yPy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iGvsva2hsf9sYGD7cnU+Y66k6gLDf1ii0tz3txLKlI/JJzLsHh8PUrViLn8nWjqlz92TDLT63FqUMmcXq7zxFllwhE9cqhvyJA7U4/Gmp4YpRUMLqgnVvaS96xpAXii+8jOnfSKxkVxYx+JkXxhG9eD37WPmVTaeqM3CFzcW327xfAF0ovIFPEztbn/w1mnQ+oJKog9RvYwmc2JT+VWk4j8uRq4JAxeh9aZ5+RQ4mXTVx9tRDJVq4ukhcOH27bR3sTJnbbovh7F86C3M7D7CsU7xU1yJZStKZUmx/9eumqfb5lNYRFV85fWAnQb/p+0a6BXtFzM/1ZgC5nmoxXB7wg== X-YMail-OSG: G_Ip5O4VM1lVr4RV7U6kyN.iIh6LiTzAKs3nY.Ioqup7wWhUBvsA7Kro2QSRTCY vO6kX2mjbQEKaVonYWs5IaEUoSIGpMONOxQmVS2BHpAdrSgM.Vdx4vRAjeoH7B2WS2j6hq_i5A4H yhyykVE1L0_YHv4.3OFtdKoFX.iA1Q5WQk_6q2zX3g.1w0gZ503yUv4LIlwJztuvPjmUPKQRDQuu 74Y22uHeL3Y90AVfJYfvldmjZmqj8X42mVlwvcK0ZCHQlJberaXpiV_KnQOf_wzAPhcAd2WjDMve PWS7H96Z9pgf7CwaDdF2oq30DenxiWDAR9TNgwlo8XNOBdddU.IcD.lN3oOERojmJKT_qKQuZ_BI bADGcUMrGOpF.rWUxsDQRc0rB2tu_WWFn3u_HMqpBRLGYazDEGGYNOYPeg0qgyy4AB3Mxw3.YZ3X wZCvDZKWNwyskL9cbnEanuU.3WBp84wrJ3hnVp8fkJ4SV5r6y6c5mqhFB0.qpQycyqGjhCGzTEuy 6tRjHCZ9OkO74Tv7Ou6y7MNY49LuVLKdtfONIbn52F346qSoEgIfLTt_x6JTvYVEYW_vgNzqqehL 31YEFJdzANzbK7dwsUIz1PDhTOYtXwk6ltPe8HG0.R7tWr6aKRf1Na5N6Fw_QU1_1k70MulkO.fM 8g2rONnc0uD9vi.wtkGJV.9Su5LpfD25NM3RHY9WAM5VWZdK5wkf9ZjjDdSRKZwy_yVhSyGjlLlp fHhl5ybS5.OMwTgvlnvYpbHozzjPZwmKpTCylW9N8D8iKNsNUEZS53aLF45L_oAclo4IqVPY8.Ag WQ2D6gGF0UaQViy2yf2yWTAtUXddoA8hzQh6bRWjgvALIHLMREKwGcR_v8BpJxUmuAJkEHLgZ5Wl M_hssnlyAKFNDEXP55eRQQ91AdyN_UPQMk9QMao6kIyQxqPInxqsAAcauEBQZgut3RyMp2Fo6mmX xZvJURIm.sI58CYnEarYU5zn7Mvl9mgdqYtrMLp3xfSYqs7y2hjHnmg.jtyjy3tNVaZMZOeR6ZLs WE4t.25O5gGNcJ.8rJog0s1FLVwKEcdixx2VEfLBgQB4OzcG8Y7mNTSBxd2bOx0kV6I0DMR3AEqK mPanpTKp4rq.gxv.08n690SV3p1XUGrbzxDNHkRtLCMlC8Q8lHxHuzN4r3AzmASAibsBEfGsbzCK jie.Km.JAaUe4BfyjfgNh_6KhmkDYH8WXdDifbjSkCR8xCjtYNTOMtx8yYVBJ73KGSNxFEQqV2Pi yINx8wusVKqAzbvnUTP9TcYQ_TFtj5QVRrL2.LWMYDmkkdaIzwiNDfGqWEwSosvVwsdo9bF3fERL VqHHDVlXrZucTu_v13zt.dT5SE6R1ADLFNSkY2xa5fAYCfW7gj.TORR77n4jiFNnteATEQ_m1gmd yUWnsi26In4us8PjqxAHJSDbb2Sb5iaBD_.C85cisrkVJSr3QEYcnqQMvsI1.N5OQ.3PfJRcJzFE rInNf5uBYpsgfG46_RyVpCh7oTIufeFnH2zUvfoMwlY2W9L9Ps.D10NFW1FvSBL52zxTA.qA_0ow X6tvjEYZqWvVP5NSmNQbF1AlGLZW5M2.dsZOakfPHaacmYBlEGhXbvuZ.dyJZ7AfMcOwVogGYZub tr5kkuklSKoxnHmYRAkhLU5w9EOcVvUaqQ4jjxSq2qXo1KJF50.LYt0G8zeRBaKoYpwbdt7ZtRTI 6fbzdGstG.oRPxm1.0AqhDltYoKxUh.1gj7vvddoHk0OyZzzVchUX92XycqM5n9XiSOS.Of5DK3X IJ2Va0hMrw83QvRhus2sG86oa2w1pMPegkKW6sVWgCICUnrHEDQ41wALc16pee7_Ztg6lCO4pkqq hBwYV7IkmDtPxSPtCWmKzwA.fa48xPg441RZ.lBlMgnKe5qlfLdyYQeJc8rYvC3kWCN86f4CymFX P_3Vlr0CboXc0eavvH6_P3jDkh3dN2lWYsj5EqNnywGq46AIwiNi6YGfHpokghNELkcTEOvnDPm. TCan_vYCa2mGqzHUcAEnHiKq7zrj_adufhq1TXi1ZvuLkTcv8eRCjjWKnXN6F2t.0TvTBK96cRNT eInPoR0XTWdXVLqM5PG0J.QtAJMI3JE0NpE22Axjbpb7Nn_cwwCiJ5HEKc80eeyrYpKY2mQC_ZQu p3IcpbamNEgxK9Kf2on59Nlh4V9OP4AgCTT1slIR0bGM37D2yfT5ZQaDWZl63_AZR0FTLRdeHBtO VksrNmmwSLx1U1x9xE0vQRWM0KJ4soP3Lz63r9rNMd_rHTZgx_OYezW.q1WwFt2Mx4lH0RsG.Gzc YpIAVEg-- X-Sonic-MF: X-Sonic-ID: a7b92d98-66e5-4635-9de2-49e08ca638af Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Apr 2023 13:26:11 +0000 Received: by hermes--production-bf1-5f9df5c5c4-fgkgh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e8b018cb9f140281bc97a5129d934e73; Thu, 13 Apr 2023 13:26:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: Date: Thu, 13 Apr 2023 06:25:56 -0700 Cc: Charlie Li , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1DEBDF0D-DEF7-4986-922C-2C2A645875A5@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> To: =?utf-8?Q?Pawe=C5=82_Jakub_Dawidek?= X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4Py0hh5RtZz4SVr X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 13, 2023, at 04:04, Charlie Li wrote: > Pawe=C5=82 Jakub Dawidek wrote: >> Can you please try this patch: >> >> Unfortunately I don=E2=80=99t see how this can happen with block = cloning disabled. > This patch made no difference in poudriere; corruption still rolled = in. >=20 Same "made no difference" here. = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014512.= html indicated that I'd applied the patch already: "I then also applied the = patch from: https://github.com/openzfs/zfs/pull/14739/files" Cy reported the same in: = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014519.= html "The EXDEV patch is applied. Block_cloning is disabled." =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 13 13:33:21 2023 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 4Py0s22rt3z451y8; Thu, 13 Apr 2023 13:33:26 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Py0s13hRtz3F7R; Thu, 13 Apr 2023 13:33:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id mc7ip87BQjvm1mx4mpAVdf; Thu, 13 Apr 2023 13:33:24 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mx4kplAu6yAOemx4kpcpIf; Thu, 13 Apr 2023 13:33:24 +0000 X-Authority-Analysis: v=2.4 cv=e5oV9Il/ c=1 sm=1 tr=0 ts=643804a4 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=dKHAf1wccvYA:10 a=13WrDtVnAAAA:8 a=YxBL1-UpAAAA:8 a=VxmjJ2MpAAAA:8 a=CjxXgO3LAAAA:8 a=kDZLfgLDAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ihgffkLAiP3tzcNCCncA:9 a=QEXdDO2ut3YA:10 a=tCI1PRuhg74A:10 a=LyydU4Oes_UA:10 a=qcMfyop8IQhGkljw9-nY:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=7gXAzLPJhVmCkEl4_tsf:22 a=Aez1uqWRNYMWVBb44gMB:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id B5F5CEBF; Thu, 13 Apr 2023 06:33:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 873DE42A; Thu, 13 Apr 2023 06:33:21 -0700 (PDT) Date: Thu, 13 Apr 2023 06:33:21 -0700 From: Cy Schubert To: =?ISO-8859-1?Q?Pawe=3F?= Jakub Dawidek Cc: Mark Millard , Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <20230413063321.60344b1f@cschubert.com> In-Reply-To: References: <20230413071032.18BFF31F@slippy.cwsent.com> Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfG/NhU8usWTT6E/Oy5taytMLmD+KXjVD0TFXLPq3b+df0Y/7ACTlNJousOPmmk/XbR+u/jy0TF+uuK6FGlBTbNvrmFGzZYkkuxQGj3RpNvDXfFUyiyds 8RArMpP81K8AlkIsKUtNuXBTNOeCbHqNISKxvawcIqYXyNu05H8r3BtB0NPuTxKCNthzRMPnNu3lL+PeGqROckXnoL4MeKAq2c8W0RVEfaZWAH/BT70WLChg 9ojhyZa6KqCd1cmqrLT3FQr1H5trDaJxbN9KKjJCUcOfvk/pcChU+cqkvcRq/1PGhnPF//Sp0uNvvesM8HLjjHIlxxhv52CXE74WmWGIgoG046x8orIk9g8S lkmqDqdTRavV0cdk+CUzfMVAkhP/IITd7i4aHz6bh/tqsZ6+xts= X-Rspamd-Queue-Id: 4Py0s13hRtz3F7R X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Thu, 13 Apr 2023 19:54:42 +0900 Pawe=C5=82 Jakub Dawidek wrote: > On Apr 13, 2023, at 16:10, Cy Schubert wrote: > >=20 > > =EF=BB=BFIn message <20230413070426.8A54F25A@slippy.cwsent.com>, Cy Sch= ubert writes: > > In message <20230413064252.1E5C1318@slippy.cwsent.com>, Cy Schubert wri= tes: > >> In message , Mark Mill= ard > >>> write > >>> s: > >>> [This just puts my prior reply's material into Cy's > >>>> adjusted resend of the original. The To/Cc should > >>>> be coomplete this time.] > >>>>=20 > >>>> On Apr 12, 2023, at 22:52, Cy Schubert = =3D > >>>> wrote: > >>>>=20 > >>>> In message , Mark =3D > >>>>> Millard=3D20 > >>>> write > >>>>> s: > >>>>> From: Charlie Li wrote on > >>>>>> Date: Wed, 12 Apr 2023 20:11:16 UTC : > >>>>>> =3D20 > >>>>>> Charlie Li wrote: > >>>>>>> Mateusz Guzik wrote: > >>>>>>>> can you please test poudriere with > >>>>>>>>> https://github.com/openzfs/zfs/pull/14739/files > >>>>>>>>> =3D20 > >>>>>>>>> After applying, on the md(4)-backed pool regardless of =3D3D > >>>>>>>> block_cloning,=3D3D20 > >>>>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. =3D > >>>>>>>> Will=3D3D20=3D3D > >>>> =3D20 > >>>>>> report back on poudriere results (no block_cloning). > >>>>>>>> =3D3D20 > >>>>>>>> As for poudriere, build failures are still rolling in. These are= =3D > >>>>>>> (and=3D3D20=3D3D > >>>> =3D20 > >>>>>> have been) entirely random on every run. Some examples from this = =3D > >>>>>>> run: > >>>> =3D3D20 > >>>>>>> lang/php81: > >>>>>>> - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=3D= 3D20 > >>>>>>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D3D > >>>>>>> ${STAGEDIR}/${PREFIX}/etc > >>>>>> - consumers fail to build due to corrupted php.conf packaged > >>>>>>> =3D3D20 > >>>>>>> devel/ninja: > >>>>>>> - phase: stage > >>>>>>> - install -s -m 555=3D3D20 > >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D3D20 > >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > >>>>>>> - consumers fail to build due to corrupted bin/ninja packaged > >>>>>>> =3D3D20 > >>>>>>> devel/netsurf-buildsystem: > >>>>>>> - phase: stage > >>>>>>> - mkdir -p=3D3D20 > >>>>>>> =3D3D > >>>>>>> =3D > >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/= share/n > >>>> e=3D > >> =3D3D > >>>> tsurf-buildsystem/makefiles=3D3D20 > >>>>>> =3D3D > >>>>>>> =3D > >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/= share/n > >>>> e=3D > >> =3D3D > >>>> tsurf-buildsystem/testtools > >>>>>> for M in Makefile.top Makefile.tools Makefile.subdir =3D3D > >>>>>>> Makefile.pkgconfig=3D3D20 > >>>>>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > >>>>>>> cp makefiles/$M=3D3D20 > >>>>>>> =3D3D > >>>>>>> =3D > >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/= share/n > >>>> e=3D > >> =3D3D > >>>> tsurf-buildsystem/makefiles/;=3D3D20 > >>>>>> \ > >>>>>>> done > >>>>>>> - graphics/libnsgif fails to build due to NUL characters in=3D3D20 > >>>>>>> Makefile.{clang,subdir}, causing nothing to link > >>>>>>> =3D20 > >>>>>> Summary: I have problems building ports into packages > >>>>>> via poudriere-devel use despite being fully updated/patched > >>>>>> (as of when I started the experiment), never having enabled > >>>>>> block_cloning ( still using openzfs-2.1-freebsd ). > >>>>>> =3D20 > >>>>>> In other words, I can confirm other reports that have > >>>>>> been made. > >>>>>> =3D20 > >>>>>> The details follow. > >>>>>> =3D20 > >>>>>> =3D20 > >>>>>> [Written as I was working on setting up for the experiments > >>>>>> and then executing those experiments, adjusting as I went > >>>>>> along.] > >>>>>> =3D20 > >>>>>> I've run my own tests in a context that has never had the > >>>>>> zpool upgrade and that jump from before the openzfs import to > >>>>>> after the existing commits for trying to fix openzfs on > >>>>>> FreeBSD. I report on the sequence of activities getting to > >>>>>> the point of testing as well. > >>>>>> =3D20 > >>>>>> By personal policy I keep my (non-temporary) pool's compatible > >>>>>> with what the most recent ??.?-RELEASE supports, using > >>>>>> openzfs-2.1-freebsd for now. The pools involved below have > >>>>>> never had a zpool upgrade from where they started. (I've no > >>>>>> pools that have ever had a zpool upgrade.) > >>>>>> =3D20 > >>>>>> (Temporary pools are rare for me, such as this investigation. > >>>>>> But I'm not testing block_cloning or anything new this time.) > >>>>>> =3D20 > >>>>>> I'll note that I use zfs for bectl, not for redundancy. So > >>>>>> my evidence is more limited in that respect. > >>>>>> =3D20 > >>>>>> The activities were done on a HoneyComb (16 Cortex-A72 cores). > >>>>>> The system has and supports ECC RAM, 64 GiBytes of RAM are > >>>>>> present. > >>>>>> =3D20 > >>>>>> I started by duplicating my normal zfs environment to an > >>>>>> external USB3 NVMe drive and adjusting the host name and such > >>>>>> to produce the below. (Non-debug, although I do not strip > >>>>>> symbols.) : > >>>>>> =3D20 > >>>>>> # uname -apKU > >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D3D > >>>>>> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 =C2= =A0=C2=A0=C2=A0=C2=A0=3D3D > >>>>>> =3D > >>>>>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-= src/arm > >>>> 6=3D > >> =3D3D > >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > >>>>>> =3D20 > >>>>>> I then did: git fetch, stash push ., merge --ff-only, stash apply = . : > >>>>>> my normal procedure. I then also applied the patch from: > >>>>>> =3D20 > >>>>>> https://github.com/openzfs/zfs/pull/14739/files > >>>>>> =3D20 > >>>>>> Then I did: buildworld buildkernel, install them, and rebooted. > >>>>>> =3D20 > >>>>>> The result was: > >>>>>> =3D20 > >>>>>> # uname -apKU > >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D3D > >>>>>> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 =C2= =A0=C2=A0=C2=A0=C2=A0=3D3D > >>>>>> =3D > >>>>>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-= src/arm > >>>> 6=3D > >> =3D3D > >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 > >>>>>> =3D20 > >>>>>> The later poudriere-devel based build of packages from ports is > >>>>>> based on: > >>>>>> =3D20 > >>>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports > >>>>>> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D3D > >>>>>> devel/freebsd-gcc12: Bump to 12.2.0. > >>>>>> Author: =C2=A0=C2=A0=C2=A0=C2=A0John Baldwin > >>>>>> Commit: =C2=A0=C2=A0=C2=A0=C2=A0John Baldwin > >>>>>> CommitDate: 2023-03-25 00:06:40 +0000 > >>>>>> branch: main > >>>>>> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > >>>>>> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > >>>>>> n613214 (--first-parent --count for merge-base) > >>>>>> =3D20 > >>>>>> poudriere attempted to build 476 packages, starting > >>>>>> with pkg (in order to build the 56 that I explicitly > >>>>>> indicate that I want). It is my normal set of ports. > >>>>>> The form of building is biased to allowing a high > >>>>>> load average compared to the number of hardware > >>>>>> threads (same as cores here): each builder is allowed > >>>>>> to use the full count of hardware threads. The build > >>>>>> =E2=82=AC=C3=8FL=E2=82=AC=E2=82=AC=E2=82=AC=E2=82=AC=E2=80=B9=15 >= > >> used USE_TMPFS=3D3D3D"data" instead of the USE_TMPFS=3D3D3Dall I > >> normally use on the build machine involved. > >>>>>> =3D20 > >>>>>> And it produced some random errors during the attempted > >>>>>> builds. A type of example that is easy to interpret > >>>>>> without further exploration is: > >>>>>> =3D20 > >>>>>> pkg_resources.extern.packaging.requirements.InvalidRequirement: Pa= rse > >>>>>> =3D > >> =3D3D > >>>> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A00 > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0da0p8 =C2=A0=C2=A0=C2= =A0=C2=A0ONLINE =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 =C2=A0=C2=A0=C2=A0=C2= =A00 =C2=A0=C2=A0=C2=A0=C2=A00 > >>>>>> =3D20 > >>>>>> errors: No known data errors > >>>>>> =3D20 > >>>>>> =3D20 > >>>>>> =3D3D3D=3D3D3D=3D3D3D > >>>>>> Mark Millard > >>>>>> marklmi at yahoo.com > >>>>>> =3D20 > >>>>> =3D20 > >>>>> Let's try this again. Claws-mail didn't include the list address in= =3D > >>>>> the=3D20 > >>>> header. Trying to reply, again, using exmh instead. > >>>>> =3D20 > >>>>> =3D20 > >>>>> Did your pools suffer the EXDEV problem? The EXDEV also corrupted = =3D > >>>>> files. > >>>>=20 > >>>> As I reported, this was a jump from before the import > >>>> to as things are tonight (here). So: NO, unless the > >>>> existing code as of tonight still has the EXDEV problem! > >>>>=20 > >>>> Prior to this experiment I'd not progressed any media > >>>> beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > >>>>=20 > >>>> I think, without sufficient investigation we risk jumping to > >>>>> conclusions. I've taken an extremely cautious approach, rolling back > >>>>> snapshots (as much as possible, i.e. poudriere datasets) when EXDEV > >>>>> corruption was encountered. > >>>>>=20 > >>>> Again: nothing between main-n261544-cee09bda03c8-dirty and > >>>> main-n262122-2ef2c26f3f13-dirty was involved at any stage. > >>>>=20 > >>>> =3D20 > >>>>> I did not rollback any snapshots in my MH mail directory. Rolling b= ack > >>>>> snapshots of my MH maildir would result in loss of email. I have to > >>>>> live with that corruption. Corrupted files in my outgoing sent email > >>>>> directory remain: > >>>>> =3D20 > >>>>> slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=3D20 > >>>>> 53 > >>>>> slippy$=3D20 > >>>>> =3D20 > >>>>> There are 53 corrupted files in my note log of 9913 emails. Those = =3D > >>>>> files > >>>> will never be fixed. They were corrupted by the EXDEV bug. Any new Z= FS > >>>>> or ZFS patches cannot retroactively remove the corruption from those > >>>>> files. > >>>>> =3D20 > >>>>> But my poudriere files, because the snapshots were rolled back, were > >>>>> "repaired" by the rolled back snapshots. > >>>>> =3D20 > >>>>> I'm not convinced that there is presently active corruption since > >>>>> the problem has been fixed. I am convinced that whatever corruption > >>>>> that was written at the time will remain forever or until those fil= es > >>>>> are deleted or replaced -- just like my email files written to disk= at > >>>>> the time. > >>>>>=20 > >>>> My test results and procedure just do not fit your conclusion > >>>> that things are okay now if block_clonging is completely avoided. > >>>>=20 > >>> Admitting I'm wrong: sending copies of my last reply to you back to m= yself, > >>>=20 > >> again and again, three times, I've managed to reproduce the corruption= you > >>> are talking about. > >>>=20 > >> This email itself was also corrupted. Below is what was sent. Good thi= ng > >> multiple copies are saved by exmh. > >>=20 > >> Admitting I'm wrong: sending copies of my last reply to you back to my= self, > >> again and again, three times, I've managed to reproduce the corruption= you > >> are talking about. > >>=20 > > This email itself was also corrupted. Below is what was sent. Good thing > > multiple copies are saved by exmh. > >=20 > > Admitting I'm wrong: sending copies of my last reply to you back to mys= elf, > > again and again, three times, I've managed to reproduce the corruption = you > > are talking about. > >=20 > > From my previous email to you. > >=20 > > header. Trying to reply:::::::::, again, using exmh instead. > > =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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^^^^^^^^^ > > Here it is, nine additional bytes of garbage. I've replaced the garbage > > with colons because nulls mess up a lot of things, including cut&paste. > >=20 > > In another instance about 500 bytes were removed. I can reproduce the > > corruption at will now. > >=20 > > The EXDEV patch is applied. Block_cloning is disabled. > >=20 > > Somehow nulls and other garbage are inserted in the middle of emails af= ter > > the ZFS upgrade. > >=20 > Can you please try this patch: >=20 > github.com The patch was applied yesterday at noon (PDT). >=20 >=20 >=20 > Unfortunately I don=E2=80=99t see how this can happen with block cloning = disabled. It does and it's reproducible. >=20 > --=C2=A0 > Pawe=C5=82 Jakub Dawidek >=20 --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0 From nobody Thu Apr 13 13:48:26 2023 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 4Py1BN3wZnz453CJ; Thu, 13 Apr 2023 13:48:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 4Py1BN1xkRz3v3C; Thu, 13 Apr 2023 13:48:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32c.google.com with SMTP id x22-20020a9d6296000000b006a42c37ddcdso1844306otk.1; Thu, 13 Apr 2023 06:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681393707; x=1683985707; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E66lyzydUgVBgSAemf9jaZxb1uimf/I7PLpXzx95GKE=; b=Lwjac2ujwXnpF/DHxtPnuatf8+CaWAtpth7cLx4XMNgYBY1ZyL2nG8INKMQNXpT+TU DKFFCTCDafliFVPpVDxynMarSY7SebRD+THnEdSWuLxmtV0RaEvJQ4zi3sq+wQ5qSSza CBBJC7C/o+HKGSOqGO8UNY1MZKo0VADcWfIlIDVXnXZluKI2H18XD8Tr85xeY58UwoWQ AvXpPakjWFezn6YzII0agLAiJ+euVeZmxRskLmk9GIBxtG41JSuCarBjw0pX9ilTPESO yoEI4t04AGJgcgVC9MHwy+7wjLMNCwaa+MnxDvzL/PoEDZpNxQHGnT8g6gcKIT1qhPuU 8Q+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681393707; x=1683985707; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E66lyzydUgVBgSAemf9jaZxb1uimf/I7PLpXzx95GKE=; b=HWLT1DxUc8YzZBEtbf8DCMRTEAvcFVvj+kBxirC5VzL79jiNwfg55jff97SlsNKfwY m35uajyJY4hn2p6MrdE/GtNrstJngCbABRk6kHWpNdXRp7RUDXqd29NVsvTUFwF+TBxj PamGUmLVZrUsXute4FoFi7Lt+Anj0DTwC4WXgrDHId+3WkzF4mOz2emU1Jswa/UqMw6Y GqQxv4aV1sEc8W9y+oRy5nlOfxSd0+frgbeghSRD25mNne4puOgBpiKXet6ASSjNWOye w3Ah/xY+lP6/0C3e75rHSofZXnhxWieQRNREo6ZN3Y76DiPBldy8MTs7Y8XQpCcuFgJS sk5A== X-Gm-Message-State: AAQBX9dike+Xqwt1JKk/KjWPbkdrmC9XpS80A830LsCsZ5JlgUcY9CaG bilKerNObdocdIsiU/skv9rCo8bhCCIf0CieFpw= X-Google-Smtp-Source: AKy350ZQeJf0wGOecyyrl9c4U7h1uTIBLhiqZYX3nqqCrAS0G5TrKGiELi8fTkYKmtBt7RsZrws8TIB/claih0r73Z0= X-Received: by 2002:a05:6830:2093:b0:6a1:cbc6:f1b3 with SMTP id y19-20020a056830209300b006a1cbc6f1b3mr616405otq.2.1681393707011; Thu, 13 Apr 2023 06:48:27 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:74cf:0:b0:49c:b071:b1e3 with HTTP; Thu, 13 Apr 2023 06:48:26 -0700 (PDT) In-Reply-To: <20230413063321.60344b1f@cschubert.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> From: Mateusz Guzik Date: Thu, 13 Apr 2023 15:48:26 +0200 Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: Cy Schubert Cc: "Pawe? Jakub Dawidek" , Mark Millard , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Py1BN1xkRz3v3C X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/13/23, Cy Schubert wrote: > On Thu, 13 Apr 2023 19:54:42 +0900 > Pawe=C5=82 Jakub Dawidek wrote: > >> On Apr 13, 2023, at 16:10, Cy Schubert wrote= : >> > >> > =EF=BB=BFIn message <20230413070426.8A54F25A@slippy.cwsent.com>, Cy Sc= hubert >> > writes: >> > In message <20230413064252.1E5C1318@slippy.cwsent.com>, Cy Schubert >> > writes: >> >> In message , Mark >> >> Millard >> >>> write >> >>> s: >> >>> [This just puts my prior reply's material into Cy's >> >>>> adjusted resend of the original. The To/Cc should >> >>>> be coomplete this time.] >> >>>> >> >>>> On Apr 12, 2023, at 22:52, Cy Schubert = =3D >> >>>> wrote: >> >>>> >> >>>> In message , Mark = =3D >> >>>>> Millard=3D20 >> >>>> write >> >>>>> s: >> >>>>> From: Charlie Li wrote on >> >>>>>> Date: Wed, 12 Apr 2023 20:11:16 UTC : >> >>>>>> =3D20 >> >>>>>> Charlie Li wrote: >> >>>>>>> Mateusz Guzik wrote: >> >>>>>>>> can you please test poudriere with >> >>>>>>>>> https://github.com/openzfs/zfs/pull/14739/files >> >>>>>>>>> =3D20 >> >>>>>>>>> After applying, on the md(4)-backed pool regardless of =3D3D >> >>>>>>>> block_cloning,=3D3D20 >> >>>>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. = =3D >> >>>>>>>> Will=3D3D20=3D3D >> >>>> =3D20 >> >>>>>> report back on poudriere results (no block_cloning). >> >>>>>>>> =3D3D20 >> >>>>>>>> As for poudriere, build failures are still rolling in. These ar= e >> >>>>>>>> =3D >> >>>>>>> (and=3D3D20=3D3D >> >>>> =3D20 >> >>>>>> have been) entirely random on every run. Some examples from this = =3D >> >>>>>>> run: >> >>>> =3D3D20 >> >>>>>>> lang/php81: >> >>>>>>> - post-install: @${INSTALL_DATA} >> >>>>>>> ${WRKSRC}/php.ini-development=3D3D20 >> >>>>>>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D3D >> >>>>>>> ${STAGEDIR}/${PREFIX}/etc >> >>>>>> - consumers fail to build due to corrupted php.conf packaged >> >>>>>>> =3D3D20 >> >>>>>>> devel/ninja: >> >>>>>>> - phase: stage >> >>>>>>> - install -s -m 555=3D3D20 >> >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D3D20 >> >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin >> >>>>>>> - consumers fail to build due to corrupted bin/ninja packaged >> >>>>>>> =3D3D20 >> >>>>>>> devel/netsurf-buildsystem: >> >>>>>>> - phase: stage >> >>>>>>> - mkdir -p=3D3D20 >> >>>>>>> =3D3D >> >>>>>>> =3D >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local= /share/n >> >>>> e=3D >> >> =3D3D >> >>>> tsurf-buildsystem/makefiles=3D3D20 >> >>>>>> =3D3D >> >>>>>>> =3D >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local= /share/n >> >>>> e=3D >> >> =3D3D >> >>>> tsurf-buildsystem/testtools >> >>>>>> for M in Makefile.top Makefile.tools Makefile.subdir =3D3D >> >>>>>>> Makefile.pkgconfig=3D3D20 >> >>>>>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do >> >>>>>> \ >> >>>>>>> cp makefiles/$M=3D3D20 >> >>>>>>> =3D3D >> >>>>>>> =3D >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local= /share/n >> >>>> e=3D >> >> =3D3D >> >>>> tsurf-buildsystem/makefiles/;=3D3D20 >> >>>>>> \ >> >>>>>>> done >> >>>>>>> - graphics/libnsgif fails to build due to NUL characters in=3D3D= 20 >> >>>>>>> Makefile.{clang,subdir}, causing nothing to link >> >>>>>>> =3D20 >> >>>>>> Summary: I have problems building ports into packages >> >>>>>> via poudriere-devel use despite being fully updated/patched >> >>>>>> (as of when I started the experiment), never having enabled >> >>>>>> block_cloning ( still using openzfs-2.1-freebsd ). >> >>>>>> =3D20 >> >>>>>> In other words, I can confirm other reports that have >> >>>>>> been made. >> >>>>>> =3D20 >> >>>>>> The details follow. >> >>>>>> =3D20 >> >>>>>> =3D20 >> >>>>>> [Written as I was working on setting up for the experiments >> >>>>>> and then executing those experiments, adjusting as I went >> >>>>>> along.] >> >>>>>> =3D20 >> >>>>>> I've run my own tests in a context that has never had the >> >>>>>> zpool upgrade and that jump from before the openzfs import to >> >>>>>> after the existing commits for trying to fix openzfs on >> >>>>>> FreeBSD. I report on the sequence of activities getting to >> >>>>>> the point of testing as well. >> >>>>>> =3D20 >> >>>>>> By personal policy I keep my (non-temporary) pool's compatible >> >>>>>> with what the most recent ??.?-RELEASE supports, using >> >>>>>> openzfs-2.1-freebsd for now. The pools involved below have >> >>>>>> never had a zpool upgrade from where they started. (I've no >> >>>>>> pools that have ever had a zpool upgrade.) >> >>>>>> =3D20 >> >>>>>> (Temporary pools are rare for me, such as this investigation. >> >>>>>> But I'm not testing block_cloning or anything new this time.) >> >>>>>> =3D20 >> >>>>>> I'll note that I use zfs for bectl, not for redundancy. So >> >>>>>> my evidence is more limited in that respect. >> >>>>>> =3D20 >> >>>>>> The activities were done on a HoneyComb (16 Cortex-A72 cores). >> >>>>>> The system has and supports ECC RAM, 64 GiBytes of RAM are >> >>>>>> present. >> >>>>>> =3D20 >> >>>>>> I started by duplicating my normal zfs environment to an >> >>>>>> external USB3 NVMe drive and adjusting the host name and such >> >>>>>> to produce the below. (Non-debug, although I do not strip >> >>>>>> symbols.) : >> >>>>>> =3D20 >> >>>>>> # uname -apKU >> >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D3D >> >>>>>> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 >> >>>>>> =3D3D >> >>>>>> =3D >> >>>>>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main= -src/arm >> >>>> 6=3D >> >> =3D3D >> >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 >> >>>>>> =3D20 >> >>>>>> I then did: git fetch, stash push ., merge --ff-only, stash apply= . >> >>>>>> : >> >>>>>> my normal procedure. I then also applied the patch from: >> >>>>>> =3D20 >> >>>>>> https://github.com/openzfs/zfs/pull/14739/files >> >>>>>> =3D20 >> >>>>>> Then I did: buildworld buildkernel, install them, and rebooted. >> >>>>>> =3D20 >> >>>>>> The result was: >> >>>>>> =3D20 >> >>>>>> # uname -apKU >> >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D3D >> >>>>>> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 >> >>>>>> =3D3D >> >>>>>> =3D >> >>>>>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main= -src/arm >> >>>> 6=3D >> >> =3D3D >> >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 >> >>>>>> =3D20 >> >>>>>> The later poudriere-devel based build of packages from ports is >> >>>>>> based on: >> >>>>>> =3D20 >> >>>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports >> >>>>>> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D3D >> >>>>>> devel/freebsd-gcc12: Bump to 12.2.0. >> >>>>>> Author: John Baldwin >> >>>>>> Commit: John Baldwin >> >>>>>> CommitDate: 2023-03-25 00:06:40 +0000 >> >>>>>> branch: main >> >>>>>> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 >> >>>>>> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 >> >>>>>> n613214 (--first-parent --count for merge-base) >> >>>>>> =3D20 >> >>>>>> poudriere attempted to build 476 packages, starting >> >>>>>> with pkg (in order to build the 56 that I explicitly >> >>>>>> indicate that I want). It is my normal set of ports. >> >>>>>> The form of building is biased to allowing a high >> >>>>>> load average compared to the number of hardware >> >>>>>> threads (same as cores here): each builder is allowed >> >>>>>> to use the full count of hardware threads. The build >> >>>>>> =E2=82=AC=C3=8FL=E2=82=AC=E2=82=AC=E2=82=AC=E2=82=AC=E2=80=B9 > = > >> used USE_TMPFS=3D3D3D"data" instead of the >> >>>>>> USE_TMPFS=3D3D3Dall I >> >> normally use on the build machine involved. >> >>>>>> =3D20 >> >>>>>> And it produced some random errors during the attempted >> >>>>>> builds. A type of example that is easy to interpret >> >>>>>> without further exploration is: >> >>>>>> =3D20 >> >>>>>> pkg_resources.extern.packaging.requirements.InvalidRequirement: >> >>>>>> Parse >> >>>>>> =3D >> >> =3D3D >> >>>> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected >> >>>> W:(0-9A-Za-z) >> >>>>>> 0 >> >> da0p8 ONLINE 0 0 0 >> >>>>>> =3D20 >> >>>>>> errors: No known data errors >> >>>>>> =3D20 >> >>>>>> =3D20 >> >>>>>> =3D3D3D=3D3D3D=3D3D3D >> >>>>>> Mark Millard >> >>>>>> marklmi at yahoo.com >> >>>>>> =3D20 >> >>>>> =3D20 >> >>>>> Let's try this again. Claws-mail didn't include the list address i= n >> >>>>> =3D >> >>>>> the=3D20 >> >>>> header. Trying to reply, again, using exmh instead. >> >>>>> =3D20 >> >>>>> =3D20 >> >>>>> Did your pools suffer the EXDEV problem? The EXDEV also corrupted = =3D >> >>>>> files. >> >>>> >> >>>> As I reported, this was a jump from before the import >> >>>> to as things are tonight (here). So: NO, unless the >> >>>> existing code as of tonight still has the EXDEV problem! >> >>>> >> >>>> Prior to this experiment I'd not progressed any media >> >>>> beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. >> >>>> >> >>>> I think, without sufficient investigation we risk jumping to >> >>>>> conclusions. I've taken an extremely cautious approach, rolling >> >>>>> back >> >>>>> snapshots (as much as possible, i.e. poudriere datasets) when EXDE= V >> >>>>> corruption was encountered. >> >>>>> >> >>>> Again: nothing between main-n261544-cee09bda03c8-dirty and >> >>>> main-n262122-2ef2c26f3f13-dirty was involved at any stage. >> >>>> >> >>>> =3D20 >> >>>>> I did not rollback any snapshots in my MH mail directory. Rolling >> >>>>> back >> >>>>> snapshots of my MH maildir would result in loss of email. I have t= o >> >>>>> live with that corruption. Corrupted files in my outgoing sent >> >>>>> email >> >>>>> directory remain: >> >>>>> =3D20 >> >>>>> slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=3D20 >> >>>>> 53 >> >>>>> slippy$=3D20 >> >>>>> =3D20 >> >>>>> There are 53 corrupted files in my note log of 9913 emails. Those = =3D >> >>>>> files >> >>>> will never be fixed. They were corrupted by the EXDEV bug. Any new >> >>>> ZFS >> >>>>> or ZFS patches cannot retroactively remove the corruption from >> >>>>> those >> >>>>> files. >> >>>>> =3D20 >> >>>>> But my poudriere files, because the snapshots were rolled back, >> >>>>> were >> >>>>> "repaired" by the rolled back snapshots. >> >>>>> =3D20 >> >>>>> I'm not convinced that there is presently active corruption since >> >>>>> the problem has been fixed. I am convinced that whatever corruptio= n >> >>>>> that was written at the time will remain forever or until those >> >>>>> files >> >>>>> are deleted or replaced -- just like my email files written to dis= k >> >>>>> at >> >>>>> the time. >> >>>>> >> >>>> My test results and procedure just do not fit your conclusion >> >>>> that things are okay now if block_clonging is completely avoided. >> >>>> >> >>> Admitting I'm wrong: sending copies of my last reply to you back to >> >>> myself, >> >>> >> >> again and again, three times, I've managed to reproduce the corruptio= n >> >> you >> >>> are talking about. >> >>> >> >> This email itself was also corrupted. Below is what was sent. Good >> >> thing >> >> multiple copies are saved by exmh. >> >> >> >> Admitting I'm wrong: sending copies of my last reply to you back to >> >> myself, >> >> again and again, three times, I've managed to reproduce the corruptio= n >> >> you >> >> are talking about. >> >> >> > This email itself was also corrupted. Below is what was sent. Good >> > thing >> > multiple copies are saved by exmh. >> > >> > Admitting I'm wrong: sending copies of my last reply to you back to >> > myself, >> > again and again, three times, I've managed to reproduce the corruption >> > you >> > are talking about. >> > >> > From my previous email to you. >> > >> > header. Trying to reply:::::::::, again, using exmh instead. >> > ^^^^^^^^^ >> > Here it is, nine additional bytes of garbage. I've replaced the garbag= e >> > with colons because nulls mess up a lot of things, including cut&paste= . >> > >> > In another instance about 500 bytes were removed. I can reproduce the >> > corruption at will now. >> > >> > The EXDEV patch is applied. Block_cloning is disabled. >> > >> > Somehow nulls and other garbage are inserted in the middle of emails >> > after >> > the ZFS upgrade. >> > >> Can you please try this patch: >> >> github.com > > The patch was applied yesterday at noon (PDT). > >> >> >> >> Unfortunately I don=E2=80=99t see how this can happen with block cloning >> disabled. > > It does and it's reproducible. > There is corruption with the recent import, with the https://github.com/openzfs/zfs/pull/14739/files patch applied and block cloning disabled on the pool. There is no corruption with top of main with zfs merge reverted altogether. Which commit results in said corruption remains to be seen, a variant of the tree with just block cloning support reverted just for testing purposes is about to be evaluated. --=20 Mateusz Guzik From nobody Thu Apr 13 13:56:35 2023 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 4Py1Mq3Lmcz453l3; Thu, 13 Apr 2023 13:56:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Py1Mq1D7Mz4CSq; Thu, 13 Apr 2023 13:56:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id mwNcp9lNbjvm1mxRGpAZDG; Thu, 13 Apr 2023 13:56:38 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id mxREpKrD7HFsOmxRFpTjry; Thu, 13 Apr 2023 13:56:38 +0000 X-Authority-Analysis: v=2.4 cv=XZqaca15 c=1 sm=1 tr=0 ts=64380a16 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=YxBL1-UpAAAA:8 a=13WrDtVnAAAA:8 a=VxmjJ2MpAAAA:8 a=CjxXgO3LAAAA:8 a=kDZLfgLDAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=EkcXrb_YAAAA:8 a=RS6mBWU6Sx5l2QwkfgEA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=tCI1PRuhg74A:10 a=LyydU4Oes_UA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=qcMfyop8IQhGkljw9-nY:22 a=7gXAzLPJhVmCkEl4_tsf:22 a=Aez1uqWRNYMWVBb44gMB:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id AE6CCEE1; Thu, 13 Apr 2023 06:56:35 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 6B62F354; Thu, 13 Apr 2023 06:56:35 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mateusz Guzik cc: Cy Schubert , "Pawe? Jakub Dawidek" , Mark Millard , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> Comments: In-reply-to Mateusz Guzik message dated "Thu, 13 Apr 2023 15:48:26 +0200." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Apr 2023 06:56:35 -0700 Message-Id: <20230413135635.6B62F354@slippy.cwsent.com> X-CMAE-Envelope: MS4xfN3etariwi3B9xU2Y4dzcEvxS8pHXGrI7IJMdsJjVogiK2nKIdP2Nld2h9Y+W4l9li5UM7+JJ+jpxeBMxy2GE9w7cUXM5oyX2AF4uH+vpR8TUHoPQhuS 6OlAcyWHdpaCpnRaKyJCrk3WCkBqzPzTnqDB3Bjovdhc7V9gDa2331Ih5bGrWHnMJnFQuSeaaoGu9HlRyaOmoiy1oLzvUNYnljVB/feztTraTwYg2rb2G5qP lXkIPiZV9ZEIhPpC41ZB41gnaVKGtX+ys5OssL5bNO6xnZXzQzSH7Uwb9r5kiguv86YukUegrAc7oUcqjPyBr0qDXgG3bPgjk3bKETr0DH1ukhsxrC13kzO5 zeShxyvL3lSNQOSccdyhKZPp2H2ZLbuNOT4C5kl1f0h3foHAk0s= X-Rspamd-Queue-Id: 4Py1Mq1D7Mz4CSq X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message , Mateusz Guzik writes: > On 4/13/23, Cy Schubert wrote: > > On Thu, 13 Apr 2023 19:54:42 +0900 > > Pawe=C5=82 Jakub Dawidek wrote: > > > >> On Apr 13, 2023, at 16:10, Cy Schubert wrote= > : > >> > > >> > =EF=BB=BFIn message <20230413070426.8A54F25A@slippy.cwsent.com>, Cy Sc= > hubert > >> > writes: > >> > In message <20230413064252.1E5C1318@slippy.cwsent.com>, Cy Schubert > >> > writes: > >> >> In message , Mark > >> >> Millard > >> >>> write > >> >>> s: > >> >>> [This just puts my prior reply's material into Cy's > >> >>>> adjusted resend of the original. The To/Cc should > >> >>>> be coomplete this time.] > >> >>>> > >> >>>> On Apr 12, 2023, at 22:52, Cy Schubert = > =3D > >> >>>> wrote: > >> >>>> > >> >>>> In message , Mark = > =3D > >> >>>>> Millard=3D20 > >> >>>> write > >> >>>>> s: > >> >>>>> From: Charlie Li wrote on > >> >>>>>> Date: Wed, 12 Apr 2023 20:11:16 UTC : > >> >>>>>> =3D20 > >> >>>>>> Charlie Li wrote: > >> >>>>>>> Mateusz Guzik wrote: > >> >>>>>>>> can you please test poudriere with > >> >>>>>>>>> https://github.com/openzfs/zfs/pull/14739/files > >> >>>>>>>>> =3D20 > >> >>>>>>>>> After applying, on the md(4)-backed pool regardless of =3D3D > >> >>>>>>>> block_cloning,=3D3D20 > >> >>>>>> the cy@ `cp -R` test reports no differing (ie corrupted) files. = > =3D > >> >>>>>>>> Will=3D3D20=3D3D > >> >>>> =3D20 > >> >>>>>> report back on poudriere results (no block_cloning). > >> >>>>>>>> =3D3D20 > >> >>>>>>>> As for poudriere, build failures are still rolling in. These ar= > e > >> >>>>>>>> =3D > >> >>>>>>> (and=3D3D20=3D3D > >> >>>> =3D20 > >> >>>>>> have been) entirely random on every run. Some examples from this = > =3D > >> >>>>>>> run: > >> >>>> =3D3D20 > >> >>>>>>> lang/php81: > >> >>>>>>> - post-install: @${INSTALL_DATA} > >> >>>>>>> ${WRKSRC}/php.ini-development=3D3D20 > >> >>>>>>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D3D > >> >>>>>>> ${STAGEDIR}/${PREFIX}/etc > >> >>>>>> - consumers fail to build due to corrupted php.conf packaged > >> >>>>>>> =3D3D20 > >> >>>>>>> devel/ninja: > >> >>>>>>> - phase: stage > >> >>>>>>> - install -s -m 555=3D3D20 > >> >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D3D20 > >> >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > >> >>>>>>> - consumers fail to build due to corrupted bin/ninja packaged > >> >>>>>>> =3D3D20 > >> >>>>>>> devel/netsurf-buildsystem: > >> >>>>>>> - phase: stage > >> >>>>>>> - mkdir -p=3D3D20 > >> >>>>>>> =3D3D > >> >>>>>>> =3D > >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local= > /share/n > >> >>>> e=3D > >> >> =3D3D > >> >>>> tsurf-buildsystem/makefiles=3D3D20 > >> >>>>>> =3D3D > >> >>>>>>> =3D > >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local= > /share/n > >> >>>> e=3D > >> >> =3D3D > >> >>>> tsurf-buildsystem/testtools > >> >>>>>> for M in Makefile.top Makefile.tools Makefile.subdir =3D3D > >> >>>>>>> Makefile.pkgconfig=3D3D20 > >> >>>>>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do > >> >>>>>> \ > >> >>>>>>> cp makefiles/$M=3D3D20 > >> >>>>>>> =3D3D > >> >>>>>>> =3D > >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local= > /share/n > >> >>>> e=3D > >> >> =3D3D > >> >>>> tsurf-buildsystem/makefiles/;=3D3D20 > >> >>>>>> \ > >> >>>>>>> done > >> >>>>>>> - graphics/libnsgif fails to build due to NUL characters in=3D3D= > 20 > >> >>>>>>> Makefile.{clang,subdir}, causing nothing to link > >> >>>>>>> =3D20 > >> >>>>>> Summary: I have problems building ports into packages > >> >>>>>> via poudriere-devel use despite being fully updated/patched > >> >>>>>> (as of when I started the experiment), never having enabled > >> >>>>>> block_cloning ( still using openzfs-2.1-freebsd ). > >> >>>>>> =3D20 > >> >>>>>> In other words, I can confirm other reports that have > >> >>>>>> been made. > >> >>>>>> =3D20 > >> >>>>>> The details follow. > >> >>>>>> =3D20 > >> >>>>>> =3D20 > >> >>>>>> [Written as I was working on setting up for the experiments > >> >>>>>> and then executing those experiments, adjusting as I went > >> >>>>>> along.] > >> >>>>>> =3D20 > >> >>>>>> I've run my own tests in a context that has never had the > >> >>>>>> zpool upgrade and that jump from before the openzfs import to > >> >>>>>> after the existing commits for trying to fix openzfs on > >> >>>>>> FreeBSD. I report on the sequence of activities getting to > >> >>>>>> the point of testing as well. > >> >>>>>> =3D20 > >> >>>>>> By personal policy I keep my (non-temporary) pool's compatible > >> >>>>>> with what the most recent ??.?-RELEASE supports, using > >> >>>>>> openzfs-2.1-freebsd for now. The pools involved below have > >> >>>>>> never had a zpool upgrade from where they started. (I've no > >> >>>>>> pools that have ever had a zpool upgrade.) > >> >>>>>> =3D20 > >> >>>>>> (Temporary pools are rare for me, such as this investigation. > >> >>>>>> But I'm not testing block_cloning or anything new this time.) > >> >>>>>> =3D20 > >> >>>>>> I'll note that I use zfs for bectl, not for redundancy. So > >> >>>>>> my evidence is more limited in that respect. > >> >>>>>> =3D20 > >> >>>>>> The activities were done on a HoneyComb (16 Cortex-A72 cores). > >> >>>>>> The system has and supports ECC RAM, 64 GiBytes of RAM are > >> >>>>>> present. > >> >>>>>> =3D20 > >> >>>>>> I started by duplicating my normal zfs environment to an > >> >>>>>> external USB3 NVMe drive and adjusting the host name and such > >> >>>>>> to produce the below. (Non-debug, although I do not strip > >> >>>>>> symbols.) : > >> >>>>>> =3D20 > >> >>>>>> # uname -apKU > >> >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 =3D3D > >> >>>>>> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 > >> >>>>>> =3D3D > >> >>>>>> =3D > >> >>>>>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main= > -src/arm > >> >>>> 6=3D > >> >> =3D3D > >> >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > >> >>>>>> =3D20 > >> >>>>>> I then did: git fetch, stash push ., merge --ff-only, stash apply= > . > >> >>>>>> : > >> >>>>>> my normal procedure. I then also applied the patch from: > >> >>>>>> =3D20 > >> >>>>>> https://github.com/openzfs/zfs/pull/14739/files > >> >>>>>> =3D20 > >> >>>>>> Then I did: buildworld buildkernel, install them, and rebooted. > >> >>>>>> =3D20 > >> >>>>>> The result was: > >> >>>>>> =3D20 > >> >>>>>> # uname -apKU > >> >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 =3D3D > >> >>>>>> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 > >> >>>>>> =3D3D > >> >>>>>> =3D > >> >>>>>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main= > -src/arm > >> >>>> 6=3D > >> >> =3D3D > >> >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarc> >> >>>>>> =3D20 > >> >>>>>> The later poudriere-devel based build of packages from ports is > >> >>>>>> based on: > >> >>>>>> =3D20 > >> >>>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports > >> >>>>>> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D3D > >> >>>>>> devel/freebsd-gcc12: Bump to 12.2.0. > >> >>>>>> Author: John Baldwin > >> >>>>>> Commit: John Baldwin > >> >>>>>> CommitDate: 2023-03-25 00:06:40 +0000 > >> >>>>>> branch: main > >> >>>>>> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > >> >>>>>> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > >> >>>>>> n613214 (--first-parent --count for merge-base) > >> >>>>>> =3D20 > >> >>>>>> poudriere attempted to build 476 packages, starting > >> >>>>>> with pkg (in order to build the 56 that I explicitly > >> >>>>>> indicate that I want). It is my normal set of ports. > >> >>>>>> The form of building is biased to allowing a high > >> >>>>>> load average compared to the number of hardware > >> >>>>>> threads (same as cores here): each builder is allowed > >> >>>>>> to use the full count of hardware threads. The build > >> >>>>>> =E2=82=AC=C3=8FL=E2=82=AC=E2=82=AC=E2=82=AC=E2=82=AC=E2=80=B9 > = > > >> used USE_TMPFS=3D3D3D"data" instead of the > >> >>>>>> USE_TMPFS=3D3D3Dall I > >> >> normally use on the build machine involved. > >> >>>>>> =3D20 > >> >>>>>> And it produced some random errors during the attempted > >> >>>>>> builds. A type of example that is easy to interpret > >> >>>>>> without further exploration is: > >> >>>>>> =3D20 > >> >>>>>> pkg_resources.extern.packaging.requirements.InvalidRequirement: > >> >>>>>> Parse > >> >>>>>> =3D > >> >> =3D3D > >> >>>> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected > >> >>>> W:(0-9A-Za-z) > >> >>>>>> 0 > >> >> da0p8 ONLINE 0 0 0 > >> >>>>>> =3D20 > >> >>>>>> errors: No known data errors > >> >>>>>> =3D20 > >> >>>>>> =3D20 > >> >>>>>> =3D3D3D=3D3D3D=3D3D3D > >> >>>>>> Mark Millard > >> >>>>>> marklmi at yahoo.com > >> >>>>>> =3D20 > >> >>>>> =3D20 > >> >>>>> Let's try this again. Claws-mail didn't include the list address i= > n > >> >>>>> =3D > >> >>>>> the=3D20 > >> >>>> header. Trying to reply, again, using exmh instead. > >> >>>>> =3D20 > >> >>>>> =3D20 > >> >>>>> Did your pools suffer the EXDEV problem? The EXDEV also corrupted = > =3D > >> >>>>> files. > >> >>>> > >> >>>> As I reported, this was a jump from before the import > >> >>>> to as things are tonight (here). So: NO, unless the > >> >>>> existing code as of tonight still has the EXDEV problem! > >> >>>> > >> >>>> Prior to this experiment I'd not progressed any media > >> >>>> beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > >> >>>> > >> >>>> I think, without sufficient investigation we risk jumping to > >> >>>>> conclusions. I've taken an extremely cautious approach, rolling > >> >>>>> back > >> >>>>> snapshots (as much as possible, i.e. poudriere datasets) when EXDE= > V > >> >>>>> corruption was encountered. > >> >>>>> > >> >>>> Again: nothing between main-n261544-cee09bda03c8-dirty and > >> >>>> main-n262122-2ef2c26f3f13-dirty was involved at any stage. > >> >>>> > >> >>>> =3D20 > >> >>>>> I did not rollback any snapshots in my MH mail directory. Rolling > >> >>>>> back > >> >>>>> snapshots of my MH maildir would result in loss of email. I have t= > o > >> >>>>> live with that corruption. Corrupted files in my outgoing sent > >> >>>>> email > >> >>>>> directory remain: > >> >>>>> =3D20 > >> >>>>> slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=3D20 > >> >>>>> 53 > >> >>>>> slippy$=3D20 > >> >>>>> =3D20 > >> >>>>> There are 53 corrupted files in my note log of 9913 emails. Those = > =3D > >> >>>>> files > >> >>>> will never be fixed. They were corrupted by the EXDEV bug. Any new > >> >>>> ZFS > >> >>>>> or ZFS patches cannot retroactively remove the corruption from > >> >>>>> those > >> >>>>> files. > >> >>>>> =3D20 > >> >>>>> But my poudriere files, because the snapshots were rolled back, > >> >>>>> were > >> >>>>> "repaired" by the rolled back snapshots. > >> >>>>> =3D20 > >> >>>>> I'm not convinced that there is presently active corruption since > >> >>>>> the problem has been fixed. I am convinced that whatever corruptio= > n > >> >>>>> that was written at the time will remain forever or until those > >> >>>>> files > >> >>>>> are deleted or replaced -- just like my email files written to dis= > k > >> >>>>> at > >> >>>>> the time. > >> >>>>> > >> >>>> My test results and procedure just do not fit your conclusion > >> >>>> that things are okay now if block_clonging is completely avoided. > >> >>>> > >> >>> Admitting I'm wrong: sending copies of my last reply to you back to > >> >>> myself, > >> >>> > >> >> again and again, three times, I've managed to reproduce the corruptio= > n > >> >> you > >> >>> are talking about. > >> >>> > >> >> This email itself was also corrupted. Below is what was sent. Good > >> >> thing > >> >> multiple copies are saved by exmh. > >> >> > >> >> Admitting I'm wrong: sending copies of my last reply to you back to > >> >> myself, > >> >> again and again, three times, I've managed to reproduce the corruptio= > n > >> >> you > >> >> are talking about. > >> >> > >> > This email itself was also corrupted. Below is what was sent. Good > >> > thing > >> > multiple copies are saved by exmh. > >> > > >> > Admitting I'm wrong: sending copies of my last reply to you back to > >> > myself, > >> > again and again, three times, I've managed to reproduce the corruption > >> > you > >> > are talking about. > >> > > >> > From my previous email to you. > >> > > >> > header. Trying to reply:::::::::, again, using exmh instead. > >> > ^^^^^^^^^ > >> > Here it is, nine additional bytes of garbage. I've replaced the garbag= > e > >> > with colons because nulls mess up a lot of things, including cut&paste= > . > >> > > >> > In another instance about 500 bytes were removed. I can reproduce the > >> > corruption at will now. > >> > > >> > The EXDEV patch is applied. Block_cloning is disabled. > >> > > >> > Somehow nulls and other garbage are inserted in the middle of emails > >> > after > >> > the ZFS upgrade. > >> > > >> Can you please try this patch: > >> > >> github.com > > > > The patch was applied yesterday at noon (PDT). > > > >> > >> > >> > >> Unfortunately I don=E2=80=99t see how this can happen with block cloning > >> disabled. > > > > It does and it's reproducible. > > > > There is corruption with the recent import, with the > https://github.com/openzfs/zfs/pull/14739/files patch applied and > block cloning disabled on the pool. Same here. > > There is no corruption with top of main with zfs merge reverted altogether. I'm in the process of building a branch reverting the merge altogether and will test it on my sandbox machine later today. > > Which commit results in said corruption remains to be seen, a variant > of the tree with just block cloning support reverted just for testing > purposes is about to be evaluated. > > --=20 > Mateusz Guzik -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Thu Apr 13 14:05:04 2023 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 4Py1Yd03Hkz458k6 for ; Thu, 13 Apr 2023 14:05:09 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 4Py1Yc5XwDz4QMB for ; Thu, 13 Apr 2023 14:05:08 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x834.google.com with SMTP id l11so16556147qtj.4 for ; Thu, 13 Apr 2023 07:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1681394707; x=1683986707; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SwC4h0o6JTZ2nbjTjoaKtAalDE+xU9li87T6BCp0I7o=; b=HyUKMBNZsr0LFsouXEig+tpUec9Dr1KpKLfsJid76mXIKq+1I03HooJ0qVkDEnjiCw O7L2hfSyFDMYmCvLcvTKYjOIzlvQ+78y/TU8PamRnt7sHH7UyAHwIDcP/2ZggjMcKv+u LkHZoSI98vKY2V0EjMf4LBhhz+F++304ft8f2SKxiYTN7B7EE4EP2W3rEhqSX8a4/O5q +RFuxAbRY6O2Gd9kFlNXtIYhsqe57ssnNIIh69IeMnSwtlfhQkjesr3Uj8HWRa7eyHNV xiL0RvAfHgllQ4YbFnKQGDWMaRI0ZTZ7yO7qioG+/sIVtKaw39+6Lxo1wG3o3IvfL5SV Nn7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681394707; x=1683986707; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SwC4h0o6JTZ2nbjTjoaKtAalDE+xU9li87T6BCp0I7o=; b=Nu0WKQVGsEUEyssTOxCSnr0V3GTjjmMyRjkTdrVld7TKyirmII7ke1IywzejNoFlkl HPdEgBwBFihB1/KMYrAr4N7zOlo/p/fqS/nlQFJL+zNFPoaQuzAEzwyhWtvk1+zVU9Nv wv/zNiF/wm9FR8aX4QwT+e/+BQniEezMa53Cp/Uezl9tGJFBZ8P1F7ORDA4v+IfAnNeF aKP5jApzSgkx58ucMOlfK20ba0gY8voTufhp8ZRabHGb5je4pe2nX6ZmV6FQNS8BKMkf sU2QOD0Xdac/Fpc98ksGZK457oLxfTaEphHg38z6nDHDM25yT6Rv3dqFAnqs6wlyzkd7 ckGQ== X-Gm-Message-State: AAQBX9cLoivYYjzCFOqSC2irSMAVK1yLNdfxdbnaH+E9PBnSCc/OXtk/ VlsDsquz97BapNl3asV2Sk+riw== X-Google-Smtp-Source: AKy350ZoY2H2SnOdOaZYTVwaZkahpkh+gkfEbXyyG5J2J+U7DsiIeqMM9eJGMX83MPbIOjPSurGblA== X-Received: by 2002:ac8:5896:0:b0:3b9:b6e3:c78e with SMTP id t22-20020ac85896000000b003b9b6e3c78emr3050711qta.8.1681394706608; Thu, 13 Apr 2023 07:05:06 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215]) by smtp.gmail.com with ESMTPSA id h21-20020ac85695000000b003e3c23dd2cfsm500327qta.84.2023.04.13.07.05.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Apr 2023 07:05:05 -0700 (PDT) Date: Thu, 13 Apr 2023 10:05:04 -0400 From: Shawn Webb To: Cy Schubert Cc: Mateusz Guzik , Pawe? Jakub Dawidek , Mark Millard , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="of4regawd5rmtjji" Content-Disposition: inline In-Reply-To: <20230413135635.6B62F354@slippy.cwsent.com> X-Rspamd-Queue-Id: 4Py1Yc5XwDz4QMB X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --of4regawd5rmtjji Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2023 at 06:56:35AM -0700, Cy Schubert wrote: > In message om> > , Mateusz Guzik writes: > > On 4/13/23, Cy Schubert wrote: > > > On Thu, 13 Apr 2023 19:54:42 +0900 > > > Pawe=3DC5=3D82 Jakub Dawidek wrote: > > > > > >> On Apr 13, 2023, at 16:10, Cy Schubert w= rote=3D > > : > > >> > > > >> > =3DEF=3DBB=3DBFIn message <20230413070426.8A54F25A@slippy.cwsent.c= om>, Cy Sc=3D > > hubert > > >> > writes: > > >> > In message <20230413064252.1E5C1318@slippy.cwsent.com>, Cy Schubert > > >> > writes: > > >> >> In message , Mark > > >> >> Millard > > >> >>> write > > >> >>> s: > > >> >>> [This just puts my prior reply's material into Cy's > > >> >>>> adjusted resend of the original. The To/Cc should > > >> >>>> be coomplete this time.] > > >> >>>> > > >> >>>> On Apr 12, 2023, at 22:52, Cy Schubert =3D > > =3D3D > > >> >>>> wrote: > > >> >>>> > > >> >>>> In message , Ma= rk =3D > > =3D3D > > >> >>>>> Millard=3D3D20 > > >> >>>> write > > >> >>>>> s: > > >> >>>>> From: Charlie Li wrote on > > >> >>>>>> Date: Wed, 12 Apr 2023 20:11:16 UTC : > > >> >>>>>> =3D3D20 > > >> >>>>>> Charlie Li wrote: > > >> >>>>>>> Mateusz Guzik wrote: > > >> >>>>>>>> can you please test poudriere with > > >> >>>>>>>>> https://github.com/openzfs/zfs/pull/14739/files > > >> >>>>>>>>> =3D3D20 > > >> >>>>>>>>> After applying, on the md(4)-backed pool regardless of =3D= 3D3D > > >> >>>>>>>> block_cloning,=3D3D3D20 > > >> >>>>>> the cy@ `cp -R` test reports no differing (ie corrupted) file= s. =3D > > =3D3D > > >> >>>>>>>> Will=3D3D3D20=3D3D3D > > >> >>>> =3D3D20 > > >> >>>>>> report back on poudriere results (no block_cloning). > > >> >>>>>>>> =3D3D3D20 > > >> >>>>>>>> As for poudriere, build failures are still rolling in. Thes= e ar=3D > > e > > >> >>>>>>>> =3D3D > > >> >>>>>>> (and=3D3D3D20=3D3D3D > > >> >>>> =3D3D20 > > >> >>>>>> have been) entirely random on every run. Some examples from t= his =3D > > =3D3D > > >> >>>>>>> run: > > >> >>>> =3D3D3D20 > > >> >>>>>>> lang/php81: > > >> >>>>>>> - post-install: @${INSTALL_DATA} > > >> >>>>>>> ${WRKSRC}/php.ini-development=3D3D3D20 > > >> >>>>>>> ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf =3D3D3D > > >> >>>>>>> ${STAGEDIR}/${PREFIX}/etc > > >> >>>>>> - consumers fail to build due to corrupted php.conf packaged > > >> >>>>>>> =3D3D3D20 > > >> >>>>>>> devel/ninja: > > >> >>>>>>> - phase: stage > > >> >>>>>>> - install -s -m 555=3D3D3D20 > > >> >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=3D3D3= D20 > > >> >>>>>>> /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > > >> >>>>>>> - consumers fail to build due to corrupted bin/ninja packaged > > >> >>>>>>> =3D3D3D20 > > >> >>>>>>> devel/netsurf-buildsystem: > > >> >>>>>>> - phase: stage > > >> >>>>>>> - mkdir -p=3D3D3D20 > > >> >>>>>>> =3D3D3D > > >> >>>>>>> =3D3D > > >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/l= ocal=3D > > /share/n > > >> >>>> e=3D3D > > >> >> =3D3D3D > > >> >>>> tsurf-buildsystem/makefiles=3D3D3D20 > > >> >>>>>> =3D3D3D > > >> >>>>>>> =3D3D > > >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/l= ocal=3D > > /share/n > > >> >>>> e=3D3D > > >> >> =3D3D3D > > >> >>>> tsurf-buildsystem/testtools > > >> >>>>>> for M in Makefile.top Makefile.tools Makefile.subdir =3D3D3D > > >> >>>>>>> Makefile.pkgconfig=3D3D3D20 > > >> >>>>>> Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64= ; do > > >> >>>>>> \ > > >> >>>>>>> cp makefiles/$M=3D3D3D20 > > >> >>>>>>> =3D3D3D > > >> >>>>>>> =3D3D > > >> >>>>>> /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/l= ocal=3D > > /share/n > > >> >>>> e=3D3D > > >> >> =3D3D3D > > >> >>>> tsurf-buildsystem/makefiles/;=3D3D3D20 > > >> >>>>>> \ > > >> >>>>>>> done > > >> >>>>>>> - graphics/libnsgif fails to build due to NUL characters in= =3D3D3D=3D > > 20 > > >> >>>>>>> Makefile.{clang,subdir}, causing nothing to link > > >> >>>>>>> =3D3D20 > > >> >>>>>> Summary: I have problems building ports into packages > > >> >>>>>> via poudriere-devel use despite being fully updated/patched > > >> >>>>>> (as of when I started the experiment), never having enabled > > >> >>>>>> block_cloning ( still using openzfs-2.1-freebsd ). > > >> >>>>>> =3D3D20 > > >> >>>>>> In other words, I can confirm other reports that have > > >> >>>>>> been made. > > >> >>>>>> =3D3D20 > > >> >>>>>> The details follow. > > >> >>>>>> =3D3D20 > > >> >>>>>> =3D3D20 > > >> >>>>>> [Written as I was working on setting up for the experiments > > >> >>>>>> and then executing those experiments, adjusting as I went > > >> >>>>>> along.] > > >> >>>>>> =3D3D20 > > >> >>>>>> I've run my own tests in a context that has never had the > > >> >>>>>> zpool upgrade and that jump from before the openzfs import to > > >> >>>>>> after the existing commits for trying to fix openzfs on > > >> >>>>>> FreeBSD. I report on the sequence of activities getting to > > >> >>>>>> the point of testing as well. > > >> >>>>>> =3D3D20 > > >> >>>>>> By personal policy I keep my (non-temporary) pool's compatible > > >> >>>>>> with what the most recent ??.?-RELEASE supports, using > > >> >>>>>> openzfs-2.1-freebsd for now. The pools involved below have > > >> >>>>>> never had a zpool upgrade from where they started. (I've no > > >> >>>>>> pools that have ever had a zpool upgrade.) > > >> >>>>>> =3D3D20 > > >> >>>>>> (Temporary pools are rare for me, such as this investigation. > > >> >>>>>> But I'm not testing block_cloning or anything new this time.) > > >> >>>>>> =3D3D20 > > >> >>>>>> I'll note that I use zfs for bectl, not for redundancy. So > > >> >>>>>> my evidence is more limited in that respect. > > >> >>>>>> =3D3D20 > > >> >>>>>> The activities were done on a HoneyComb (16 Cortex-A72 cores). > > >> >>>>>> The system has and supports ECC RAM, 64 GiBytes of RAM are > > >> >>>>>> present. > > >> >>>>>> =3D3D20 > > >> >>>>>> I started by duplicating my normal zfs environment to an > > >> >>>>>> external USB3 NVMe drive and adjusting the host name and such > > >> >>>>>> to produce the below. (Non-debug, although I do not strip > > >> >>>>>> symbols.) : > > >> >>>>>> =3D3D20 > > >> >>>>>> # uname -apKU > > >> >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = =3D3D3D > > >> >>>>>> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 > > >> >>>>>> =3D3D3D > > >> >>>>>> =3D3D > > >> >>>>>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/= main=3D > > -src/arm > > >> >>>> 6=3D3D > > >> >> =3D3D3D > > >> >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 > > >> >>>>>> =3D3D20 > > >> >>>>>> I then did: git fetch, stash push ., merge --ff-only, stash a= pply=3D > > . > > >> >>>>>> : > > >> >>>>>> my normal procedure. I then also applied the patch from: > > >> >>>>>> =3D3D20 > > >> >>>>>> https://github.com/openzfs/zfs/pull/14739/files > > >> >>>>>> =3D3D20 > > >> >>>>>> Then I did: buildworld buildkernel, install them, and reboote= d. > > >> >>>>>> =3D3D20 > > >> >>>>>> The result was: > > >> >>>>>> =3D3D20 > > >> >>>>>> # uname -apKU > > >> >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 = =3D3D3D > > >> >>>>>> main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 > > >> >>>>>> =3D3D3D > > >> >>>>>> =3D3D > > >> >>>>>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/= main=3D > > -src/arm > > >> >>>> 6=3D3D > > >> >> =3D3D3D > > >> >>>> 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarc> >> >>>>>> =3D3D20 > > >> >>>>>> The later poudriere-devel based build of packages from ports = is > > >> >>>>>> based on: > > >> >>>>>> =3D3D20 > > >> >>>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports > > >> >>>>>> 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) =3D3D= 3D > > >> >>>>>> devel/freebsd-gcc12: Bump to 12.2.0. > > >> >>>>>> Author: John Baldwin > > >> >>>>>> Commit: John Baldwin > > >> >>>>>> CommitDate: 2023-03-25 00:06:40 +0000 > > >> >>>>>> branch: main > > >> >>>>>> merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 > > >> >>>>>> merge-base: CommitDate: 2023-03-25 00:06:40 +0000 > > >> >>>>>> n613214 (--first-parent --count for merge-base) > > >> >>>>>> =3D3D20 > > >> >>>>>> poudriere attempted to build 476 packages, starting > > >> >>>>>> with pkg (in order to build the 56 that I explicitly > > >> >>>>>> indicate that I want). It is my normal set of ports. > > >> >>>>>> The form of building is biased to allowing a high > > >> >>>>>> load average compared to the number of hardware > > >> >>>>>> threads (same as cores here): each builder is allowed > > >> >>>>>> to use the full count of hardware threads. The build > > >> >>>>>> =3DE2=3D82=3DAC=3DC3=3D8FL=3DE2=3D82=3DAC=3DE2=3D82=3DAC=3DE2= =3D82=3DAC=3DE2=3D82=3DAC=3DE2=3D80=3DB9 > =3D > > > >> used USE_TMPFS=3D3D3D3D"data" instead of the > > >> >>>>>> USE_TMPFS=3D3D3D3Dall I > > >> >> normally use on the build machine involved. > > >> >>>>>> =3D3D20 > > >> >>>>>> And it produced some random errors during the attempted > > >> >>>>>> builds. A type of example that is easy to interpret > > >> >>>>>> without further exploration is: > > >> >>>>>> =3D3D20 > > >> >>>>>> pkg_resources.extern.packaging.requirements.InvalidRequiremen= t: > > >> >>>>>> Parse > > >> >>>>>> =3D3D > > >> >> =3D3D3D > > >> >>>> error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected > > >> >>>> W:(0-9A-Za-z) > > >> >>>>>> 0 > > >> >> da0p8 ONLINE 0 0 0 > > >> >>>>>> =3D3D20 > > >> >>>>>> errors: No known data errors > > >> >>>>>> =3D3D20 > > >> >>>>>> =3D3D20 > > >> >>>>>> =3D3D3D3D=3D3D3D3D=3D3D3D3D > > >> >>>>>> Mark Millard > > >> >>>>>> marklmi at yahoo.com > > >> >>>>>> =3D3D20 > > >> >>>>> =3D3D20 > > >> >>>>> Let's try this again. Claws-mail didn't include the list addre= ss i=3D > > n > > >> >>>>> =3D3D > > >> >>>>> the=3D3D20 > > >> >>>> header. Trying to reply, again, using exmh instead. > > >> >>>>> =3D3D20 > > >> >>>>> =3D3D20 > > >> >>>>> Did your pools suffer the EXDEV problem? The EXDEV also corrup= ted =3D > > =3D3D > > >> >>>>> files. > > >> >>>> > > >> >>>> As I reported, this was a jump from before the import > > >> >>>> to as things are tonight (here). So: NO, unless the > > >> >>>> existing code as of tonight still has the EXDEV problem! > > >> >>>> > > >> >>>> Prior to this experiment I'd not progressed any media > > >> >>>> beyond: main-n261544-cee09bda03c8-dirty Wed Mar 15 20:25:49. > > >> >>>> > > >> >>>> I think, without sufficient investigation we risk jumping to > > >> >>>>> conclusions. I've taken an extremely cautious approach, rolling > > >> >>>>> back > > >> >>>>> snapshots (as much as possible, i.e. poudriere datasets) when = EXDE=3D > > V > > >> >>>>> corruption was encountered. > > >> >>>>> > > >> >>>> Again: nothing between main-n261544-cee09bda03c8-dirty and > > >> >>>> main-n262122-2ef2c26f3f13-dirty was involved at any stage. > > >> >>>> > > >> >>>> =3D3D20 > > >> >>>>> I did not rollback any snapshots in my MH mail directory. Roll= ing > > >> >>>>> back > > >> >>>>> snapshots of my MH maildir would result in loss of email. I ha= ve t=3D > > o > > >> >>>>> live with that corruption. Corrupted files in my outgoing sent > > >> >>>>> email > > >> >>>>> directory remain: > > >> >>>>> =3D3D20 > > >> >>>>> slippy$ ugrep -cPa '\x00' ~/.Mail/note | grep -c :1=3D3D20 > > >> >>>>> 53 > > >> >>>>> slippy$=3D3D20 > > >> >>>>> =3D3D20 > > >> >>>>> There are 53 corrupted files in my note log of 9913 emails. Th= ose =3D > > =3D3D > > >> >>>>> files > > >> >>>> will never be fixed. They were corrupted by the EXDEV bug. Any = new > > >> >>>> ZFS > > >> >>>>> or ZFS patches cannot retroactively remove the corruption from > > >> >>>>> those > > >> >>>>> files. > > >> >>>>> =3D3D20 > > >> >>>>> But my poudriere files, because the snapshots were rolled back, > > >> >>>>> were > > >> >>>>> "repaired" by the rolled back snapshots. > > >> >>>>> =3D3D20 > > >> >>>>> I'm not convinced that there is presently active corruption si= nce > > >> >>>>> the problem has been fixed. I am convinced that whatever corru= ptio=3D > > n > > >> >>>>> that was written at the time will remain forever or until those > > >> >>>>> files > > >> >>>>> are deleted or replaced -- just like my email files written to= dis=3D > > k > > >> >>>>> at > > >> >>>>> the time. > > >> >>>>> > > >> >>>> My test results and procedure just do not fit your conclusion > > >> >>>> that things are okay now if block_clonging is completely avoide= d. > > >> >>>> > > >> >>> Admitting I'm wrong: sending copies of my last reply to you back= to > > >> >>> myself, > > >> >>> > > >> >> again and again, three times, I've managed to reproduce the corru= ptio=3D > > n > > >> >> you > > >> >>> are talking about. > > >> >>> > > >> >> This email itself was also corrupted. Below is what was sent. Good > > >> >> thing > > >> >> multiple copies are saved by exmh. > > >> >> > > >> >> Admitting I'm wrong: sending copies of my last reply to you back = to > > >> >> myself, > > >> >> again and again, three times, I've managed to reproduce the corru= ptio=3D > > n > > >> >> you > > >> >> are talking about. > > >> >> > > >> > This email itself was also corrupted. Below is what was sent. Good > > >> > thing > > >> > multiple copies are saved by exmh. > > >> > > > >> > Admitting I'm wrong: sending copies of my last reply to you back to > > >> > myself, > > >> > again and again, three times, I've managed to reproduce the corrup= tion > > >> > you > > >> > are talking about. > > >> > > > >> > From my previous email to you. > > >> > > > >> > header. Trying to reply:::::::::, again, using exmh instead. > > >> > ^^^^^^^^^ > > >> > Here it is, nine additional bytes of garbage. I've replaced the ga= rbag=3D > > e > > >> > with colons because nulls mess up a lot of things, including cut&p= aste=3D > > . > > >> > > > >> > In another instance about 500 bytes were removed. I can reproduce = the > > >> > corruption at will now. > > >> > > > >> > The EXDEV patch is applied. Block_cloning is disabled. > > >> > > > >> > Somehow nulls and other garbage are inserted in the middle of emai= ls > > >> > after > > >> > the ZFS upgrade. > > >> > > > >> Can you please try this patch: > > >> > > >> github.com > > > > > > The patch was applied yesterday at noon (PDT). > > > > > >> > > >> > > >> > > >> Unfortunately I don=3DE2=3D80=3D99t see how this can happen with blo= ck cloning > > >> disabled. > > > > > > It does and it's reproducible. > > > > > > > There is corruption with the recent import, with the > > https://github.com/openzfs/zfs/pull/14739/files patch applied and > > block cloning disabled on the pool. >=20 > Same here. >=20 > > > > There is no corruption with top of main with zfs merge reverted altoget= her. >=20 > I'm in the process of building a branch reverting the merge altogether an= d=20 > will test it on my sandbox machine later today. >=20 > > > > Which commit results in said corruption remains to be seen, a variant > > of the tree with just block cloning support reverted just for testing > > purposes is about to be evaluated. I've learned over the years downstream that it's not really my place to tell upstream what to do or how to do it. However, I think given the seriousness of this, upstream might do well to revert the commit until a solid fix is in place. Upstream might want to consider the impacts this is having not just with downstream projects, but also regular users. Really bad timing to have a lot of new tax documentation that I really don't want to lose. I'd really like to have an up-to-date, security patched OS, but I guess I'll stay behind so that I don't risk losing critical financial documentation. Does the ZFS project have some sort of automated testing to catch data-gobbling, pool killing bugs? It seems like this would have been caught with some CI/CD stress testing automation scripts. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --of4regawd5rmtjji Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmQ4DAkACgkQ/y5nonf4 4fomgxAAn0eDUQVU6hZ4z9rC/NttvibQseTBVvr/0Re48+GLu+AFYz34BT10t/p/ vxINgpeoHMMEfC8k67dojIcElsDOUa9M2Y5XNnJI6rr1TjwIiIE3Hpn7etH59g8O +k9B715AkRwP+3o8N4xUPXIHnZ6c/auFdFZO3MUsYOhr1O0UrkYtH5IC1OjcapXl x2uENZj9FaEFsjgWpVyougkUsh04/9T+xbj7+s6J0npvDCVuXkqDKiyQEWfE/ntu b7LcU2c/fpLvwWdYNYBV6+vIGy99aRYdld9OW9IdkA0XZnkyurKXU9OPgmZgIBze f1dqkEZzGdM3K/6CqS9RuzHYIzMyFtt3ic+vZZB+VKOqP8O66chERGP+lZnG41Rz QESnEFn1H2QUBH6xTw+RKXHwL3Gsx/HUmQK0uQksqKY54AeTBMEKjlmsL05G1MGF 78vcaCcMlbHja7aHeAlaPpYfVchl6O+VRogz5FFoPF4xMldoKNYTOAv+qlCNE9qw y1qwDsg2f7vQCtrS0XbBZCQ28zF18v9DEzLxXF3xYfmE/lu0AqQgGICxwkOW4QZv Hw7kr2D5PdSLSzN4hlbsuGyvb4VVq7fGlw6JnVxLUIr41V5Y/XjY6uSysoQvZsdo 7zCHdyIMsbELZncZAzMXwhSUDpeArKQS0vS9WLZQHScsZEP3huQ= =mNE2 -----END PGP SIGNATURE----- --of4regawd5rmtjji-- From nobody Thu Apr 13 21:42:04 2023 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 4PyChz3Gy0z44hWl for ; Thu, 13 Apr 2023 21:42:11 +0000 (UTC) (envelope-from fluffy@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 4PyChz2kxJz3kyN for ; Thu, 13 Apr 2023 21:42:11 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681422131; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=hKVBELaok4jt+33aFXOTk9NB3u8kC63VWdq6WxgT4bw=; b=lcmiZaf5kI7PMXSRD/uxh0mESVugzRkA0X/B2lEoe8VnpTtgTTGdqqY9SsNprzrwEVlcE3 XfaD0V1U2WnKo7ujPCGn+9Sg9eJcskyYxSX3AChgef41Im4SApdeQoFlDjZXyhk5k1J/Qc UiCKCnhmf/O7bKGQgVnf3m5078yc1klnPSODEHs3lFxjtKdZKyY+8U4pDF7ibmVbmaFqQ3 4EsL4vcwEWQOYUb3AbQlLUce8TUl/zk774T3GrPwjsc0i8hy34xto/cG323ZXFbLkEkzFQ EA44RP1532Sbl/wxvgMh2rmAmv7NN+D6M9sG5DxrgTO5S3Y4XKO3U4Uadgekug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681422131; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=hKVBELaok4jt+33aFXOTk9NB3u8kC63VWdq6WxgT4bw=; b=KAOCmEpmK9rM/djucrpSKHUipTspGwD9XE+c9OkdkC8x95s1XJV8jFZXAGQgx6nTIvg0j1 7pTvQaUXlUDVh2E+lsSOXondkaRy20pmUxO9dhAegTc6CoD4WmNaH64ixrkz2SpTe1jhWV pvPx7WZdv8IXHMeoyq0unnrBy6RpC9eEoz8Oqe+QvObEv4zESUtisC6s3gqg2U/B4jKS2c EOtPLYqkm540y1h2gaYZ+fO2l8esRVyte8eC5WwUm63xHsVLBrKkG/kebtgSmdnNoksthz z7Y9GfZ139OS4XTVQU6TaQVrgpkBzpUIDoeuLaWSgvcEDpLr7oLMnpx04Ma4sw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681422131; a=rsa-sha256; cv=none; b=YPlsyBY9u80pvh2JccIanou2yUi/cQrxZ4Mbu72QdrjaOAxHZO2J9bYaOiSKfLfx+g40Sv dTi/DFyW5d05S9X/2eFNWkYUGxFkTVuHNy0fx6NZubIZ/Z5jGvRbFnDTncVyqrCvh9eEKy GOfcfcU/f3Ke+BQQ7PVXXIEcvjsCc8Cf04O97lrCXtkKOJFfH89bMAKzw8OWqLIffvxjAR Svi52qI0deW+ok2yv5Zeefr0R6PwF6KN8T8jZyZ3YaJjfIoA+fCDkciCgsIjr452HSYUkn w5rtD+lOPtesU0aQqLfwC2U04Y3u9e60gfzXJ3Lv61IiOMibMmT4yobmPh09xQ== Received: from [192.168.0.100] (unknown [88.201.168.234]) (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: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyChz0J1pzst3 for ; Thu, 13 Apr 2023 21:42:10 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Message-ID: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> Date: Fri, 14 Apr 2023 00:42:04 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: freebsd-current Content-Language: ru, en-GB, en-US From: Dima Panov Organization: FreeBSD.org Subject: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------3OuOdOmGHlkfMMPaDNaDKnRO" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3OuOdOmGHlkfMMPaDNaDKnRO Content-Type: multipart/mixed; boundary="------------qvy1NdwfQalaaF18RF7pc50D"; protected-headers="v1" From: Dima Panov To: freebsd-current Message-ID: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> Subject: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 --------------qvy1NdwfQalaaF18RF7pc50D Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TW9pbi1tb2luIQ0KDQpTb21ldGhpbmdzIGNoYW5nZWQgaW4gbWFpbiBicmFuY2ggYmV0d2Vl biBNYXIsIDI4IGFuZCBBcHIsIDggd2hpY2ggY2F1c2VzIHBlcm1hbmVudCBidWlsZCBlcnJv ciBmb3IgbGFuZy9nY2MxWzAxMl0gb24gYWFyY2g2NCAoZXhhY3RseSBWTVdhcmUgY29udGFp bmVyIG9uIE0xUHJvIG1hYykNCg0KZHVyaW5nIFJUTCBwYXNzOiBzY2hlZDENCmdpbXBsZS1t YXRjaC5jYzogSW4gZnVuY3Rpb24gJ2Jvb2wgZ2ltcGxlX25vcF9hdG9taWNfYml0X3Rlc3Rf YW5kX3AodHJlZSwgdHJlZV9ub2RlKiosIHRyZWVfbm9kZSogKCopKHRyZWUpKSc6DQpnaW1w bGUtbWF0Y2guY2M6MzkyMTU6MTogaW50ZXJuYWwgY29tcGlsZXIgZXJyb3I6IFNlZ21lbnRh dGlvbiBmYXVsdA0KMzkyMTUgfCB9DQogICAgICAgfCBeDQptbWFwOiBJbnZhbGlkIGFyZ3Vt ZW50DQpQbGVhc2Ugc3VibWl0IGEgZnVsbCBidWcgcmVwb3J0LCB3aXRoIHByZXByb2Nlc3Nl ZCBzb3VyY2UgKGJ5IHVzaW5nIC1mcmVwb3J0LWJ1ZykuDQpTZWUgPGh0dHBzOi8vZ2NjLmdu dS5vcmcvYnVncy8+IGZvciBpbnN0cnVjdGlvbnMuDQpnbWFrZVs0XTogKioqIFtNYWtlZmls ZToxMTQ1OiBnaW1wbGUtbWF0Y2gub10gRXJyb3IgMQ0KZ21ha2VbNF06ICoqKiBXYWl0aW5n IGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uDQpybSBnY2MucG9kIGdmb3J0cmFuLnBvZA0KDQoN Ci0tIA0KU2luY2VyZWx5LA0KRGltYSAoZmx1ZmZ5QEZyZWVCU0Qub3JnLCBodHRwczovL3Qu bWUvRmx1ZmZ5QlNEKQ0KKGRlc2t0b3AsIGtkZSwgeDExLCBvZmZpY2UsIHBvcnRzLXNlY3Rl YW0pQEZyZWVCU0QgdGVhbQ0K --------------qvy1NdwfQalaaF18RF7pc50D-- --------------3OuOdOmGHlkfMMPaDNaDKnRO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEELTAsy5mEEwxvh7r8+4ugndU5jykFAmQ4dywFAwAAAAAACgkQ+4ugndU5jynd LxAAmplKAXHdSjeDEQ6KqKVI8MQ9TkM3D4Gw1I+ei1JjvUK+qD9D9WqupHu38qrgzbD4ZHatbmwu 7ZFb6wyWof6JXgOvEBvrrPAVnf5VKHkdx4gggSRNNrPC910URDJv6uGBO6FPGIF6piquMpZqH7x5 /fFJG26b1t6bEcHmnjzj9M2UexkJ4oB+bMSKpydrPbsFGVkIjBVc5e/FjupmMSd0r2EIWSgL6i09 vd8Be5M9+yyaZ4zau/FW6xu0ZHbsn+ptMZPPvUUzw7uQjyMr5LOwOk28jDWQp25UcG+MNxhfTWah lWkAaqKiNfLjS/Fb5jT6dOz5zf41Fl0YtCvt9crqAsVzSkdopVmv5AJngrGoq+on90J8r7gOZSYh xQKCACKf/k10C1+ZclxTwyWwtSjXVD6h4QD3q0hYOjA8mQtqowiGVJoD1oKjZMMi2wmS29gb+/ig sVyqMcPqLT0TC4rWQZfWhDo3sQB1bosEruU3cdRi4KF/1ZpQrOWRHxIww/YCPEKxshpabV8Rk6oE X212ntorImVaLcwnwC6LQpnHWVE7YCIoOD6ZCS1fnwmIhLzlA8N1WOfVX3mS9fGsO3wEkf65/K/P xh+xSjFlv1vTujkaHtwhRWq+T8m1oh3ObPHO+jKCuPUIwGf4pwswWKu8Xq6ijrhV+7Be9gUkupXa rXs= =I0CT -----END PGP SIGNATURE----- --------------3OuOdOmGHlkfMMPaDNaDKnRO-- From nobody Thu Apr 13 22:13:20 2023 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 4PyDPH4S3Xz44l3R for ; Thu, 13 Apr 2023 22:13:39 +0000 (UTC) (envelope-from dim@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 4PyDPH3vvxz3NSy; Thu, 13 Apr 2023 22:13:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681424019; 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=t8syG6DYgtioGUSsJVlozltEHd/k3WlQEZL0lmhiLVU=; b=xpqTfvAMbOiv/ueuLIMsmBcqDBxA7HdLtMGC+VPIhFrQBL6Xm0W3OFDsPAoX4PGyEq5+Tp rQiQ68HEDp0s+NjDWDlFditUD4VQaQh2INlo/MJ2lLPY30FYMADd50/RXKneMEwjCCyd8h BvA8LaJnkW+ApqPuQjJA0nBIFf3xnFqBhnB+Sviml7LBHySmYrYNJUGa1nBitTQea4zyfg kbr0mzsDjStEKpUP2YKI+9+0uoNL/IzYGgUUQbZ6JjvV3t2FtSD2GyPvbcmY2jOfjqM6Vq RuPI12iFqXWnS9C9s97qxI/uA+CbQOOlmn54pb4kLeCOo5GajVO2+Jxi298u4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681424019; 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=t8syG6DYgtioGUSsJVlozltEHd/k3WlQEZL0lmhiLVU=; b=Z8uS3K5sXNARwu8P0zVRUD9/uA7YC/wMxD/95LYzfNGiLIc8IAcxb9XdNTeqqcvMmj4gqS JU1YN2lr7BcSO4leAJBdvO5KG5kqV3BGJ9iJO6e8p+QQjDMVYYpCl/JAh0+kUIg22sK5d5 aOTRCESvcYYnXe6OeK+zBVQk2LVz7HB3sDAA6JO/0zh5Ae+IYFPn47s0BJjk1ppVor02Jo mxLoSGhWVNGt1aYnqirI9a/IkY7GQd9jhGrlnfEm9Ip2qXs6qqPS5xmr8r9doBAUm1WFFU VNz9jvVExw89XFVcVkkpfGRMROsHqeDJ0+Nw6V0kYUdvhavgY3zX3svjRv3kYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681424019; a=rsa-sha256; cv=none; b=gNu9oYx/6MkqjA68d70mlAvnHB76SBVK5Q9Kwo8I/9PkhrTvplAwyp9VLSImByCD+54C7P OK0evTDx11ZpK2tw5T6lue4sODBRIzcJozVX739c0jJe1zbywlOySJQCQ0vWhoYVAmP1iT I0JvPWSB9biS96+hEEMwr3R6235OA0QXBgcEVkQQw8YpZlQGqF7X6WX3TxPZgULQT9e5EC ig7LowBOPkxwQfuM5j0wiqhDUrW30XZzKmHuO5zq3x7/ZUMcKqZxU8sTK/DIuB/ZHkyhmI maFDfmzzjkmTSwjYyAcUOfvub4M+i70vYeN3jt7gvRZuEbSjXKIQXFeX5QYbXw== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyDPH2JLwzt5r; Thu, 13 Apr 2023 22:13:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0772256EE2; Fri, 14 Apr 2023 00:13:38 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_96593F80-400D-407B-B49C-B4F8D9551AE3"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 From: Dimitry Andric In-Reply-To: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> Date: Fri, 14 Apr 2023 00:13:20 +0200 Cc: freebsd-current Message-Id: References: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> To: Dima Panov X-Mailer: Apple Mail (2.3731.500.231) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_96593F80-400D-407B-B49C-B4F8D9551AE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Apr 2023, at 23:42, Dima Panov wrote: > Somethings changed in main branch between Mar, 28 and Apr, 8 which = causes permanent build error for lang/gcc1[012] on aarch64 (exactly = VMWare container on M1Pro mac) >=20 > during RTL pass: sched1 > gimple-match.cc: In function 'bool = gimple_nop_atomic_bit_test_and_p(tree, tree_node**, tree_node* = (*)(tree))': > gimple-match.cc:39215:1: internal compiler error: Segmentation fault > 39215 | } > | ^ > mmap: Invalid argument > Please submit a full bug report, with preprocessed source (by using = -freport-bug). > See for instructions. > gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1 > gmake[4]: *** Waiting for unfinished jobs.... > rm gcc.pod gfortran.pod Are you running this build on zfs? There are apparently a bunch of filesystem corruption problems which have surfaced due to recent openzfs imports. -Dimitry --Apple-Mail=_96593F80-400D-407B-B49C-B4F8D9551AE3 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----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZDh+gAAKCRCwXqMKLiCW o8MmAJ0diVw+hWeokdXQlZB7Xom4usYEwwCggdmtbAa7v38tQYWzADTDWJPjBOw= =De1S -----END PGP SIGNATURE----- --Apple-Mail=_96593F80-400D-407B-B49C-B4F8D9551AE3-- From nobody Thu Apr 13 22:36:20 2023 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 4PyDvc4YVbz44n6F; Thu, 13 Apr 2023 22:36:28 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from mail.dawidek.net (mail.dawidek.net [94.130.64.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4PyDvc1qhwz4MyD; Thu, 13 Apr 2023 22:36:28 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.20.1.26] (211.188.237.160.cyberhome.jp [160.237.188.211]) by mail.dawidek.net (Postfix) with ESMTPSA id 1B4EF4F63E; Fri, 14 Apr 2023 00:36:23 +0200 (CEST) Message-ID: <060e8793-cca7-9301-57ac-9c73a187db3f@dawidek.net> Date: Fri, 14 Apr 2023 07:36:20 +0900 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: Shawn Webb , Cy Schubert Cc: Mateusz Guzik , Mark Millard , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> Content-Language: en-US From: Pawel Jakub Dawidek In-Reply-To: <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PyDvc1qhwz4MyD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/13/23 23:05, Shawn Webb wrote: > I've learned over the years downstream that it's not really my place > to tell upstream what to do or how to do it. However, I think given > the seriousness of this, upstream might do well to revert the commit > until a solid fix is in place. Upstream might want to consider the > impacts this is having not just with downstream projects, but also > regular users. > > Really bad timing to have a lot of new tax documentation that I really > don't want to lose. I'd really like to have an up-to-date, security > patched OS, but I guess I'll stay behind so that I don't risk losing > critical financial documentation. Shawn, I'm working on a patch to safely revert this that would also work for people who already upgraded their pools. I'm sorry for this mess. -- Pawel Jakub Dawidek From nobody Thu Apr 13 22:40:23 2023 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 4PyF0G5Rv4z44nCj; Thu, 13 Apr 2023 22:40:30 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from mail.dawidek.net (mail.dawidek.net [94.130.64.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4PyF0G47r4z4V7j; Thu, 13 Apr 2023 22:40:30 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.20.1.26] (211.188.237.160.cyberhome.jp [160.237.188.211]) by mail.dawidek.net (Postfix) with ESMTPSA id C64E34F3E1; Fri, 14 Apr 2023 00:40:27 +0200 (CEST) Message-ID: Date: Fri, 14 Apr 2023 07:40:23 +0900 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-US To: Cy Schubert , Mateusz Guzik Cc: Mark Millard , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> From: Pawel Jakub Dawidek In-Reply-To: <20230413135635.6B62F354@slippy.cwsent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PyF0G47r4z4V7j X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/13/23 22:56, Cy Schubert wrote: > I'm in the process of building a branch reverting the merge altogether and > will test it on my sandbox machine later today. Cy, thank you for your testing and patience so far. I'm working on a patch to revert block cloning without affecting people who already upgraded their pools. I'd also greatly appreciate if you could provide a procedure for me to reproduce the corruption, ideally without the internet access, as I'll be on the plane(s) for the next ~24h. -- Pawel Jakub Dawidek From nobody Thu Apr 13 22:48:14 2023 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 4PyF9D0fCTz44p5C; Thu, 13 Apr 2023 22:48:16 +0000 (UTC) (envelope-from vishwin@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 4PyF9D03W3z3G5N; Thu, 13 Apr 2023 22:48:16 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681426096; 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=AyRecSlrynly5UY8AB3MXZ70phnuDMsDaGVYr901OXU=; b=eGfwXOfqjdMiDQ01wx2EOfBRPYE8E7d+VJR4wuphHlCa7Xlbcv4/US+cZUPdJLD9C6nfCd T4+ztc/MuMbKRaIThDiNJEKbG9abm+qHz/3IgrLRJO5K8ykTEUdY7xNm3dYwRnAvZzv9vB v1W4qpwLry/cqMIk4GVbg67AJfZlL936ZbWudhHN7VQ6VDuhe2CzBXEM2Gex6RiH8u7Kdy QAW7qhAG9CWUGwVrCkoSJT/ThE0I4Jt/UXpLmwYeJ3/n6vOhbWZz2UUkfT6HBC4pNRHM+0 l4uKbGcKe7CatvfvP1SA9c1/v5R2lzEb6lPDxUFlPHDhP7xlfHdMEZ8Iy98Ulw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681426096; 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=AyRecSlrynly5UY8AB3MXZ70phnuDMsDaGVYr901OXU=; b=x6eIiOYwBLxJuWYrUWulE35ozAM/2xeVsV/VZHoi/IZYLErPsJbt1f5mmylnyjsMYIC9ge vZM3bqy2ydGF1+Ns1w7YzS2uVvvTdos7MnlpAsAbX1RPcb9KUtPYCelF49C8G3Gq2eazRh ESJQncWeaB97YEHQONVEZf/HOyM/yHxTYITaXGME1my3ZS4j7BvnvX7U2QSNv6X7OWFrz1 lhaOZ0b7nP+HE6Ub1GyjdS5IruEmUrE6M2kTe9EjRVdVtoCT8GuuPV/yApkGD2wMnNk+Xg YMWeRyxs/U8zC4KM3SRT2F9re1kqxce+6fmNppd8wDmIj10dHkmOuFeGfOf/XA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681426096; a=rsa-sha256; cv=none; b=V7+8qwOufR20iQK86DdHCwcRP+kNSjK4z4XZgbA+xkanyNWJB8GYoLG/zRVb34yp3cf1xq OtL/8DV40Fg9I1zdVReMi0iEtrskBiR60atkh/LncdHvzeTpz/p8REk9fOAYoa/u8qVpnv aKq1C0GRGXHTiCIHIp9UaJ542DziU0NMr7jIjPKITPAN2Hq8jM3WAR1uFSbL8Wa3gOT+tq hm3LyJ5e25E0iD+eSm+nrZ6U6SAVoL99vkSGWLdv1hEwiwwzG17oYyzCRqeVfmJ1VVx+rw jfDcKiQXHeElZyRmBl2D98A0GmpoMqFv7gcXyIa8eesijp6IdZWJ2pcLIfJqBw== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyF9C3bhCztV2; Thu, 13 Apr 2023 22:48:15 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: Date: Thu, 13 Apr 2023 18:48:14 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Shawn Webb , Cy Schubert Cc: Mateusz Guzik , Pawe? Jakub Dawidek , Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> From: Charlie Li Organization: FreeBSD Project In-Reply-To: <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vIbZwbLYufuViZicV4PBmRib" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vIbZwbLYufuViZicV4PBmRib Content-Type: multipart/mixed; boundary="------------0mG74PqwpjtYR4QsOFOb0YeH"; protected-headers="v1" From: Charlie Li To: Shawn Webb , Cy Schubert Cc: Mateusz Guzik , Pawe? Jakub Dawidek , Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> In-Reply-To: <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> --------------0mG74PqwpjtYR4QsOFOb0YeH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 U2hhd24gV2ViYiB3cm90ZToNCj4gRG9lcyB0aGUgWkZTIHByb2plY3QgaGF2ZSBzb21lIHNv cnQgb2YgYXV0b21hdGVkIHRlc3RpbmcgdG8gY2F0Y2gNCj4gZGF0YS1nb2JibGluZywgcG9v bCBraWxsaW5nIGJ1Z3M/IEl0IHNlZW1zIGxpa2UgdGhpcyB3b3VsZCBoYXZlIGJlZW4NCj4g Y2F1Z2h0IHdpdGggc29tZSBDSS9DRCBzdHJlc3MgdGVzdGluZyBhdXRvbWF0aW9uIHNjcmlw dHMuDQo+IA0KSSBjYW4ndCBzcGVhayBhYm91dCBob3cgdGhlIE9wZW5aRlMgcHJvamVjdCBk b2VzIHRoaW5ncywgYnV0IHRoaXMgDQpwYXJ0aWN1bGFyIGNvcnJ1cHRpb24gZG9lcyBub3Qg aGF2ZSBhbnkgZGV0ZXJtaW5pc3RpYyBjaGFyYWN0ZXJpc3RpY3MgDQpib3RoIHByZS0gYW5k IHBvc3QtY29uZGl0aW9uLCBzbyB3b3VsZCBiZSBoYXJkIHRvIGF1dG9tYXRlIHRlc3Rpbmcu DQoNCi0tIA0KQ2hhcmxpZSBMaQ0K4oCmbm9wZSwgc3RpbGwgZG9uJ3QgaGF2ZSBhbiBleGl0 IGxpbmUuDQoNCg== --------------0mG74PqwpjtYR4QsOFOb0YeH-- --------------vIbZwbLYufuViZicV4PBmRib Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ4hq4FAwAAAAAACgkQ/reFK+KbPod3 1BAApB80UWXBt2vO31qji6ybXhWSnHeUithzLV38j4lHDUZ0TWNgjEGRhNPHKbyr1lfszwrqpJlz wu3kth5ETvqudAD98rE2Wwx+xKYjeFGSHXhtsnJws1CNtoQf3AATkUcO5vhMARd7jD1jDelfk7wl wW9k2pTZQi2sODWOnIOPRLEb8+Wq8fhdWz4CLyUxnMRwwfobwsnPGMkbqlD0Brp2mNdRYKP6nrYe r8qeFktu89rYvC97c3PWRkU3tpWRc+r5RV8VZMZmFUcPzgOoMaPl8/Qb/RhhT78weapal1sKP5So ZpjaKHcMukXQlmF2XrJPfRiJljnGfkdd71xTEFb1EYMGccYnyTCahCdnCbGOjuC1ya1aDNh1RR+j RZvkdiKu9bOXA92VNv39o2pV+bWBv2EA9JAbSBWQhhwVKmVjJdHpj4t2KzqdRqT7Tjp7kDxoNzhj Q89IVfMMxTDLqhD5zzLHwhxiX2GtnrtwLcTvWGPu9cpfoU7sSLmLRqDtt3hrutgL2dm9xDWgWLuq avaKO01VgKsEI5kGimRjxeEV+N4c5Muhy+KOTqDujSgmemn4KkaIt5BEix45/U8PQSkPm5WKOPtp nAiaZPhXIi8RW22TGhU/W113QhiJP6p3dlo/a4Rzg820wYt4nZoYkjUgyIf27wW+jgo/bMQ5tvOg tA4= =FdTX -----END PGP SIGNATURE----- --------------vIbZwbLYufuViZicV4PBmRib-- From nobody Thu Apr 13 22:52:53 2023 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 4PyFGZ4D3Gz44pvC; Thu, 13 Apr 2023 22:52:54 +0000 (UTC) (envelope-from vishwin@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 4PyFGZ3N8Gz3PFB; Thu, 13 Apr 2023 22:52:54 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681426374; 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=97HL1qWd2574ZQYyYY+YFPK+5rusmR2U/fd3ycTakMU=; b=l2C32nS4XLg4Yrmy+uxwXBGz/IChciMQsJaYGK3lBUUbWAzm0fjf5x0tGG2O3gBmshGPyv lPY2t9Gmywnmwz4s1EPEHuZVavL/SbVcYzQwbD+kMUJtzR1Qp97Ao3Rj79OMlqmnKKnBXM GR/NtCj+9dd11zmQHyzUNSByfl2KoWIBVP96yHCtfh9TfAPpeXz2PIafbbGLMnX/Eo+nmi 35XukET+NXUJp71fX1Xq4SMVp6fRn2OI0s72vbv5Bo7VeYhOAwjg4Z9uI7HFndIG/566/i JLlFAR00NRsf+HgqdU0AOQHouyN4DkDsfRn2bxcYVDYqLmk66LprE1JG4gKg6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681426374; 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=97HL1qWd2574ZQYyYY+YFPK+5rusmR2U/fd3ycTakMU=; b=k6nQPfhRR0nx2jPze1FxyeKO7vOKlSFZp1yMIzmc1lRa8oknutbLMCam24CeChn8ZtsPuy nLRM4faDB1KJ3jjy26gWgld4UoV9gV7Tp4FgJBWPXARdJSYPP6lZU0GuFJdLJr4/cmmZeI iz3VXS/d/SwI5TIW8XZHvvW3DLlyRsOVX7DBW3e5ORQYVwVdptFV8xotylNxkfbRgkF8qG Pj7k4eawIkLxhZzZWDf5uJnegi37UpHLO6+a1AODRtWB3fzkjO6gsBGIOISoVHT3OczO8k 6LAURmsZSAYMKWSibwZkas6BBKzenTRD3WXXNo5JZhgywtveAizQHHlsXQmS5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681426374; a=rsa-sha256; cv=none; b=EkEf/EfKYNk9nT/o57dAaRWqtvkfALwbHg+9abP9k9rc5eUEUZJNZ2KtUOhM/YUH2f6k50 fCjnNYsdgLZXqHB5SCsCNPdApa0CnRKtTat4nS7nkH89dpKGquksGvJBlTf377JY4TC8kq zhv/Isku9wGpqYvTY2hG7i4i45XHIUw0kG2/Oc41F4T4PvGtlzKPf+Rkc5vLqpS/NtXBQv J26XDdU+ZxqjVtWZNOdCIcPBzhKjLBipKYt629Mr5juhCNRgg87sEu7nONDFbtwlsvR5DN m/vjiqLbUhkuTfcuVDTix2sptKtCkFGaV9cbDuGZuVaci9RhsBG1b1rZrvutCQ== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyFGZ0fv7zthd; Thu, 13 Apr 2023 22:52:54 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> Date: Thu, 13 Apr 2023 18:52:53 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik Cc: Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> From: Charlie Li Organization: FreeBSD Project In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FB7dp5piutxmv9bFc4NF1cTT" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FB7dp5piutxmv9bFc4NF1cTT Content-Type: multipart/mixed; boundary="------------9TaJHcWocJFugNSKOIX0ZY9d"; protected-headers="v1" From: Charlie Li To: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik Cc: Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD Message-ID: <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> In-Reply-To: --------------9TaJHcWocJFugNSKOIX0ZY9d Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGF3ZWwgSmFrdWIgRGF3aWRlayB3cm90ZToNCj4gdGhhbmsgeW91IGZvciB5b3VyIHRlc3Rp bmcgYW5kIHBhdGllbmNlIHNvIGZhci4gSSdtIHdvcmtpbmcgb24gYSBwYXRjaCANCj4gdG8g cmV2ZXJ0IGJsb2NrIGNsb25pbmcgd2l0aG91dCBhZmZlY3RpbmcgcGVvcGxlIHdobyBhbHJl YWR5IHVwZ3JhZGVkIA0KPiB0aGVpciBwb29scy4NCj4gDQpUZXN0aW5nIHdpdGggbWpnQCBl YXJsaWVyIHRvZGF5IHJldmVhbGVkIHRoYXQgYmxvY2tfY2xvbmluZyB3YXMgbm90IHRoZSAN CmNhdXNlIG9mIHBvdWRyaWVyZSBidWxrIGJ1aWxkIChhbmQgc2ltaWxhciBjcCgxKS9pbnN0 YWxsKDEpLWJhc2VkKSANCmNvcnJ1cHRpb24sIGFsdGhvdWdoIG1heSBoYXZlIGV4YWNlcmJh dGVkIGl0Lg0KPiBJJ2QgYWxzbyBncmVhdGx5IGFwcHJlY2lhdGUgaWYgeW91IGNvdWxkIHBy b3ZpZGUgYSBwcm9jZWR1cmUgZm9yIG1lIHRvIA0KPiByZXByb2R1Y2UgdGhlIGNvcnJ1cHRp b24sIGlkZWFsbHkgd2l0aG91dCB0aGUgaW50ZXJuZXQgYWNjZXNzLCBhcyBJJ2xsIA0KPiBi ZSBvbiB0aGUgcGxhbmUocykgZm9yIHRoZSBuZXh0IH4yNGguDQo+IA0KRHVlIHRvIG5vbi1k ZXRlcm1pbmlzdGljIGNvbmRpdGlvbnMsIHRoZXJlLi4ua2luZCBvZiBpc24ndCBvbmUuIEJl c3QgaXMgDQpwcm9iYWJseSBqdXN0IHBvdWRyaWVyZSBidWxrIGJ1aWxkcy4NCg0KLS0gDQpD aGFybGllIExpDQrigKZub3BlLCBzdGlsbCBkb24ndCBoYXZlIGFuIGV4aXQgbGluZS4NCg0K --------------9TaJHcWocJFugNSKOIX0ZY9d-- --------------FB7dp5piutxmv9bFc4NF1cTT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ4h8UFAwAAAAAACgkQ/reFK+KbPoe7 UQ//f7+9QEFICxxLCXJpCqRzDoEWeGvfo1omIkJLHMpyfG0nFFQl8NvNxvbw9ME/vZv+0cw/OuVu dFLn7F/SfQqQ633h91uaynrs8WASpvE/CkQRvxu/Td1V6Q0s9ePEJ/gSR/Ks/RxmJVHq7ks6kk1w 2xIBu80Ob0mkrYbe1aMSsh+jra8f7p0xzjXcFAQui2DrojVb0O5+tUwZxeEnpYi1GxKX2qvllLmK RYSbFPBa/GFl0Ayfh82G9ODWjp6MLHki7BPvXsOka+QUcBOLOFkC+N8932v9K8UbZ7/Q/NknAOxo hpr2zZG70cjZaGWk/eEVmGQ6p97WQ3cjQV3uQnxbo28zDx432V1XgclvY0bY6OQ5X0emLhFwGoO3 iTgvctIlwpFmLtEKDldO6dkZSnBpF6OymhanrVtCQEHcORk8WaOMFpNeNO5jm5zCQEo0NWqPAAkz ybCVw3JWgNnLc0oHmnjlJ5MYvpHQxslTfn/P0OyqaMfdqluNFPIfg/uZZqvvyL2a3qAP9XhVhO2F +K1jSrIR908zP4BzxdTVx3U7mfvQyEA7XUReFYycHLifIfOimE7x7j22ZspVt9lZwidaVgoZGndp zwIRpiLf3L6dn27IS8N35nZV8W3R1m3k7gjKMx5aGIxIY3XciD5amO7vRgd6hzX5u4/HxBsR9PtS TZY= =9o1L -----END PGP SIGNATURE----- --------------FB7dp5piutxmv9bFc4NF1cTT-- From nobody Thu Apr 13 23:42:47 2023 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 4PyGNJ3NcSz44tNv; Thu, 13 Apr 2023 23:42:56 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from mail.dawidek.net (mail.dawidek.net [94.130.64.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4PyGNH4hZQz421V; Thu, 13 Apr 2023 23:42:55 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 94.130.64.56 is neither permitted nor denied by domain of pjd@FreeBSD.org) smtp.mailfrom=pjd@FreeBSD.org; dmarc=none Received: from [10.20.1.26] (211.188.237.160.cyberhome.jp [160.237.188.211]) by mail.dawidek.net (Postfix) with ESMTPSA id BD6784F642; Fri, 14 Apr 2023 01:42:51 +0200 (CEST) Message-ID: <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> Date: Fri, 14 Apr 2023 08:42:47 +0900 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-US To: Cy Schubert Cc: Mark Millard , vishwin@freebsd.org, Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> From: Pawel Jakub Dawidek In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [0.54 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.96)[-0.959]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org,freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; FREEFALL_USER(0.00)[pjd]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,gmail.com] X-Rspamd-Queue-Id: 4PyGNH4hZQz421V X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On 4/14/23 07:40, Pawel Jakub Dawidek wrote: > On 4/13/23 22:56, Cy Schubert wrote: >> I'm in the process of building a branch reverting the merge altogether >> and >> will test it on my sandbox machine later today. > > Cy, > > thank you for your testing and patience so far. I'm working on a patch > to revert block cloning without affecting people who already upgraded > their pools. > > I'd also greatly appreciate if you could provide a procedure for me to > reproduce the corruption, ideally without the internet access, as I'll > be on the plane(s) for the next ~24h. Here is the change that reverts most of the modifications and disables cloning new blocks. It does retain ability to free existing cloned blocks and keeps block_cloning feature around, so upgraded pools can be imported and existing cloned blocks freed. It does not handle replaying ZIL with block-cloning logs, so make sure you import pools that were cleanly exported. I'd appreciate if someone who can reproduce those corruptions could try it. https://github.com/pjd/openzfs/commit/f2cfbcf76a733c44e25cba8c649162ef68047103 Thank you guys for your help! -- Pawel Jakub Dawidek From nobody Thu Apr 13 23:51:00 2023 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 4PyGYl28Rjz44vKH; Thu, 13 Apr 2023 23:51:07 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from mail.dawidek.net (mail.dawidek.net [94.130.64.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4PyGYl0xqPz4JHl; Thu, 13 Apr 2023 23:51:07 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.20.1.26] (211.188.237.160.cyberhome.jp [160.237.188.211]) by mail.dawidek.net (Postfix) with ESMTPSA id 1D5E74F3E8; Fri, 14 Apr 2023 01:51:03 +0200 (CEST) Message-ID: <3ac74c8b-db46-c4f5-cef2-9f09c32903c4@dawidek.net> Date: Fri, 14 Apr 2023 08:51:00 +0900 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-US To: Charlie Li , Cy Schubert , Mateusz Guzik Cc: Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> From: Pawel Jakub Dawidek In-Reply-To: <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PyGYl0xqPz4JHl X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/14/23 07:52, Charlie Li wrote: > Pawel Jakub Dawidek wrote: >> thank you for your testing and patience so far. I'm working on a patch >> to revert block cloning without affecting people who already upgraded >> their pools. >> > Testing with mjg@ earlier today revealed that block_cloning was not the > cause of poudriere bulk build (and similar cp(1)/install(1)-based) > corruption, although may have exacerbated it. Can you please elaborate how were you testing and what exactly did you exclude? Thanks. -- Pawel Jakub Dawidek From nobody Fri Apr 14 00:09:41 2023 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 4PyGzC6LtPz44wXv; Fri, 14 Apr 2023 00:09:43 +0000 (UTC) (envelope-from vishwin@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 4PyGzC5fQxz4lDN; Fri, 14 Apr 2023 00:09:43 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681430983; 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=rqouSAdksmjIDXq0A8r4ZzUsj+65vCJIjMyMxsu60+Q=; b=QJXBreq9TRXo2sMgpBjEUZMwcb6m/SWlzO6Koup+OdzNFmQsHRTKUuBqBLvyNWb92BYiWQ weuUU8yx/cbBoCypLb2kbkx8VGga8qypcrNW39uiBFbOqQJasuJcFOwaL86QOJSuTJE+lI EkqUyVgH72vO55zTj3YP0CMaFXnXa5kAakmB/p1gy9cmH4Bmu6iA2QgEhF/Ad9Nvln1o0n LFnMZa66QQN9P7k0bnAt+igXa1tkjZWJ5o8vkNkoRGz6RHQhyVBTVZCtUr1QmgngmPN5s4 Am7QboHUMFbepv1I/PjKVUzRTMm+7mZJ9Hv1ZIot8tF+cf/v9Q03fITI1nX02g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681430983; 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=rqouSAdksmjIDXq0A8r4ZzUsj+65vCJIjMyMxsu60+Q=; b=J4MIqcIO9bV0L9dE3/oAqw9sw2clkbIOrIywtJuu6i4medDB9TjA8lckOuZOrr6/2fGTU0 XcRtqnft8IK5NRUnbT4YafgkrsGdxivvu+zZ5ge1h2OD6CDYEQ33J6ZG9AiBYxTsYcWyku 6a1NCb/xL8TA/AWgBRE34xOH+KKgZ94qgDB4WdaLkQyay+e08pTph6ObnRfcwFOgYsK8MV jmSifWQBv9MLb4T1Ko6ryV5s+PVWiOHdKpdg+X6pjRwM9TE4cNMQ4H7O0zXcViLsil7Q6a nwK/ACDYtdH2wqTEyq9acFwgReKBURgsfC+gmViLWuZUX+xJbvHCb4pf5gQhEA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681430983; a=rsa-sha256; cv=none; b=VAN76z1XK+LyztyP7sqy37TTi7uatoJVywSkGUKrkroqBjvmiq89ln7017jXyFY6uLBeyl vHSuGDvEz+BYwv+MhsMx01A6AYqG+jvB6Ni/I2vNNwvLASeBAuCzHul99BlA+S1ZW/1Lpb 9Dw8Jsv++V8Y9B/eY2UuxxzOi+V8Bzaq8SAHt2e2YgwoTuKJCxVY8GR7uvOeJrKl2uVd0Z 5aFqJ61YXdhP3aNIrddaQKmdkQNLf0H5uWqut+7yuTen3IUQ4IwQJKKRUckX/3wxy6/Ew+ JaijDlfAKHrF4l0Hp/f0igfVFKom7RbknuBVArMhirzs4+x54pdiO+sj06TB7w== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyGzC2lgbzvmp; Fri, 14 Apr 2023 00:09:43 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: Date: Thu, 13 Apr 2023 20:09:41 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik Cc: Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> <3ac74c8b-db46-c4f5-cef2-9f09c32903c4@dawidek.net> From: Charlie Li Organization: FreeBSD Project In-Reply-To: <3ac74c8b-db46-c4f5-cef2-9f09c32903c4@dawidek.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------V2e7Walm9PMfeXnAkMmSi0Uh" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------V2e7Walm9PMfeXnAkMmSi0Uh Content-Type: multipart/mixed; boundary="------------9WuYTIou60N8rXF0KUhmos97"; protected-headers="v1" From: Charlie Li To: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik Cc: Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> <3ac74c8b-db46-c4f5-cef2-9f09c32903c4@dawidek.net> In-Reply-To: <3ac74c8b-db46-c4f5-cef2-9f09c32903c4@dawidek.net> --------------9WuYTIou60N8rXF0KUhmos97 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGF3ZWwgSmFrdWIgRGF3aWRlayB3cm90ZToNCj4gT24gNC8xNC8yMyAwNzo1MiwgQ2hhcmxp ZSBMaSB3cm90ZToNCj4+IFBhd2VsIEpha3ViIERhd2lkZWsgd3JvdGU6DQo+Pj4gdGhhbmsg eW91IGZvciB5b3VyIHRlc3RpbmcgYW5kIHBhdGllbmNlIHNvIGZhci4gSSdtIHdvcmtpbmcg b24gYSANCj4+PiBwYXRjaCB0byByZXZlcnQgYmxvY2sgY2xvbmluZyB3aXRob3V0IGFmZmVj dGluZyBwZW9wbGUgd2hvIGFscmVhZHkgDQo+Pj4gdXBncmFkZWQgdGhlaXIgcG9vbHMuDQo+ Pj4NCj4+IFRlc3Rpbmcgd2l0aCBtamdAIGVhcmxpZXIgdG9kYXkgcmV2ZWFsZWQgdGhhdCBi bG9ja19jbG9uaW5nIHdhcyBub3QgDQo+PiB0aGUgY2F1c2Ugb2YgcG91ZHJpZXJlIGJ1bGsg YnVpbGQgKGFuZCBzaW1pbGFyIGNwKDEpL2luc3RhbGwoMSktYmFzZWQpIA0KPj4gY29ycnVw dGlvbiwgYWx0aG91Z2ggbWF5IGhhdmUgZXhhY2VyYmF0ZWQgaXQuDQo+IA0KPiBDYW4geW91 IHBsZWFzZSBlbGFib3JhdGUgaG93IHdlcmUgeW91IHRlc3RpbmcgYW5kIHdoYXQgZXhhY3Rs eSBkaWQgeW91IA0KPiBleGNsdWRlPw0KPiANCm1qZ0AgcHJlcGFyZWQgDQpodHRwczovL2dp dGxhYi5jb20vdmlzaHdpbi9mcmVlYnNkLXNyYy8tL2NvbW1pdC9iNDFmMTg3YmEzMjk2MjFj ZGExZThlNjdhMDc4NmYwN2IxMjIxYTNjIA0Kd2hpY2ggb25seSByZW1vdmVzIGJsb2NrX2Ns b25pbmcsIHJlYnVpbGRpbmcga2VybmVsIG9ubHkgKGJ1aWxkd29ybGQgDQpmYWlscykgZm9y IG1lIHRvIHRlc3QgcG91ZHJpZXJlIGJ1bGsgLWMgYnVpbGRzIHdpdGguIEkgdXNlZCBhIHdv cmxkIGZyb20gDQpodHRwczovL2dpdGxhYi5jb20vdmlzaHdpbi9mcmVlYnNkLXNyYy8tL3Ry ZWUvemZzLXJldmVydCB3aGljaCBjb25zaXN0cyANCm9mIHJldmVydGluZyB0aGUgbWVyZ2Ug Y29tbWl0IHBsdXMgYSBmZXcgb3RoZXIgY29uZmxpY3RzLCBidXQga2VlcGluZyANCnZvcF9m cGxvb2t1cF92ZXhlYy4NCg0KLS0gDQpDaGFybGllIExpDQrigKZub3BlLCBzdGlsbCBkb24n dCBoYXZlIGFuIGV4aXQgbGluZS4NCg0K --------------9WuYTIou60N8rXF0KUhmos97-- --------------V2e7Walm9PMfeXnAkMmSi0Uh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ4mcUFAwAAAAAACgkQ/reFK+KbPocY Ng//d9Y6aqKfp+UnEyU3IP2IucZ1rF2GjLYDONBxD0B/ECt3wqbTIWi1OQX1vsfCnY7DF6Et2MdA EJKnVe4RYChczL/CC6VqWszP7OvuleUxMn4x1W59r9Lzo1VoudFjxtJomFd2ZAL7hQBEANf5zosN fM+2M8iE1wuQmzYwAXYPkRBoWr/w53v9NcL9faAwSotcG0y73PwjOThNgZhLp/uJ2qXt9/j/hWuw oMKgBbtElJl891FG0httbTWOB1wwGTCqAAbl9O/UC8HHL6Hy6xDor3k/slxfaJLGmOFnyxBVYpo6 Osa/6tb093Ivn4j0pE0N8vH+JCxIp15nFsHQf45P3LvseqSjKuEf4rUq+IX1ANKJROpcqx2O+8sH OodivbqQqmirooQksiUGaWyCvIgU9U1PwveICa80z2yduiTkvhWiXMSa7HoPzyD9g3cRXBHL6V+Q mNbJ7+k15b95jpFB4HuThqG9VOP6IsbMvmBOXlTJo0fn7IYjw/dGmR82G3KnPGLMIMYw33l6Bu3C K+gbUIVSpz/gr12q5YmrX7vJGb4VLzWzx19yyfpERCXJV42PvrwZ9PziF8n2zM/NkbAgg+IgXXEb GCcXwHYwgMiZqjKUxnz/tQP8hzYKde3F2XbMErWVLjwyewjBc00kzsJ4WOvajtC07NB25Ar4mgiq JGU= =5fvg -----END PGP SIGNATURE----- --------------V2e7Walm9PMfeXnAkMmSi0Uh-- From nobody Fri Apr 14 00:23:36 2023 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 4PyHHG5xB5z44y8j; Fri, 14 Apr 2023 00:23:38 +0000 (UTC) (envelope-from vishwin@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 4PyHHF2v1xz3h5S; Fri, 14 Apr 2023 00:23:37 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681431817; 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=ez6b2K0dEg9WRqp2XqL9F+khrWYckWZeccnvMMdfl74=; b=gxLneTNcPCIU/U7lLFCHpTjIK+8N7sr/jROwr7NRYZdnJVtURe0LG7XWxalmaxOy3VfuxE yRk3Akg4KXibF4hBqHegZ3ai5nHDmW8Cyahyxnw4idLZmcGPGxBT09+lBW2bi3m4Jl9EdF n7nZ0Zep5Qi+chC3vHiptnNi+eEL+Y6mlqzEllXLjoUN96QgpBk3scXoDX3L0x+LB4AcOl hUohw+vu7Tr4sXRb1UkEGgADEdhefACJtLYCtU+ezMuSCY/Ax+rHrdEbXi2gwbNUzY+SzX md+X1atXbR3z9prZCwz4gbc+5wG7d63Kgs/MaDQmOFzE7tS9Jeu/TmT/x/ixzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681431817; 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=ez6b2K0dEg9WRqp2XqL9F+khrWYckWZeccnvMMdfl74=; b=qvV6AZu0JpCz1y5Nr3LKfyiCWIarm44FEILuBUcLKjuV5+TUvb1hQmPJdMWFS3zZHjPoUr U8WYr9DockOSJHfFgjj0lTkzH4oXpW8m9REAEV04X2AuDLDolmq1W3nTLQ8L6H5KjKukae YpIqMGA3zYQNETntLzlr/lyMISEOBknUIwRCCyUK1QxuambYLMdy6qwHhbMTh0aoSDR9Lw epFXNEbt8S32TQ95LSwnPpKYieeBF3lnPIdQtmlNraUDb+UE+5WlEXpEsEY7yf0ONDu6Ds FU2sAnDYVpzMt7L2zaLM8OhJRDfGY79D1QuNBdwfRn+BexPAMPlcQWg2YYEEfA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681431817; a=rsa-sha256; cv=none; b=VwjTe1BInYv8gCnN6jzu4SW2pM7At4eu5cWHnC2Qb5eZuPoo6raFiOXtjbUTNAdHNSZdAd gXTPotBk8uAHeFoJihr0HcfrNBB7I5o/9MBbbQjLCcOs0/fJOrJGECyLsApNtFnzdBKurl kISDBeu4GHHhOg/JhNvVwTadnSbAbtf9QNRSFJAeHinI9KSSp9Gc+vm1fB+S+IArTejUmO eBV0zBQiBTSQE3ecZqkMjqqtdmemQKkBxy6Nk1J69qSZwFNe/SvyGID+LuRr4VRY0Qnlqo Hp1x8TwBwFIZasvC3n8yfdfIS6cu0VULwxln8NJ9dy+c/wU2R4J2y9Zi67kO5Q== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyHHD6p6Rzvy6; Fri, 14 Apr 2023 00:23:36 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: Date: Thu, 13 Apr 2023 20:23:36 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Pawel Jakub Dawidek , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> From: Charlie Li Organization: FreeBSD Project In-Reply-To: <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------CKkWOqTk6p0PIDBz0YM2LpDh" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------CKkWOqTk6p0PIDBz0YM2LpDh Content-Type: multipart/mixed; boundary="------------rI9RcAkHOI6aeiBCyNncbfSt"; protected-headers="v1" From: Charlie Li To: Pawel Jakub Dawidek , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> In-Reply-To: <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> --------------rI9RcAkHOI6aeiBCyNncbfSt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGF3ZWwgSmFrdWIgRGF3aWRlayB3cm90ZToNCj4gSGVyZSBpcyB0aGUgY2hhbmdlIHRoYXQg cmV2ZXJ0cyBtb3N0IG9mIHRoZSBtb2RpZmljYXRpb25zIGFuZCBkaXNhYmxlcyANCj4gY2xv bmluZyBuZXcgYmxvY2tzLiBJdCBkb2VzIHJldGFpbiBhYmlsaXR5IHRvIGZyZWUgZXhpc3Rp bmcgY2xvbmVkIA0KPiBibG9ja3MgYW5kIGtlZXBzIGJsb2NrX2Nsb25pbmcgZmVhdHVyZSBh cm91bmQsIHNvIHVwZ3JhZGVkIHBvb2xzIGNhbiBiZSANCj4gaW1wb3J0ZWQgYW5kIGV4aXN0 aW5nIGNsb25lZCBibG9ja3MgZnJlZWQuDQo+IA0KPiBJdCBkb2VzIG5vdCBoYW5kbGUgcmVw bGF5aW5nIFpJTCB3aXRoIGJsb2NrLWNsb25pbmcgbG9ncywgc28gbWFrZSBzdXJlIA0KPiB5 b3UgaW1wb3J0IHBvb2xzIHRoYXQgd2VyZSBjbGVhbmx5IGV4cG9ydGVkLg0KPiANCj4gSSdk IGFwcHJlY2lhdGUgaWYgc29tZW9uZSB3aG8gY2FuIHJlcHJvZHVjZSB0aG9zZSBjb3JydXB0 aW9ucyBjb3VsZCB0cnkgaXQuDQo+IA0KPiBodHRwczovL2dpdGh1Yi5jb20vcGpkL29wZW56 ZnMvY29tbWl0L2YyY2ZiY2Y3NmE3MzNjNDRlMjVjYmE4YzY0OTE2MmVmNjgwNDcxMDMNCj4g DQpEb2VzIG5vdCBhcHBseSB0byBzeXMvY29udHJpYi9vcGVuemZzIHRpcCwgY29uZmxpY3Rz IGluIA0KbW9kdWxlL29zL2ZyZWVic2QvemZzL3pmc192bm9wc19vcy5jIGFuZCBtb2R1bGUv emZzL2RtdS5jLg0KDQotLSANCkNoYXJsaWUgTGkNCuKApm5vcGUsIHN0aWxsIGRvbid0IGhh dmUgYW4gZXhpdCBsaW5lLg0KDQo= --------------rI9RcAkHOI6aeiBCyNncbfSt-- --------------CKkWOqTk6p0PIDBz0YM2LpDh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ4nQgFAwAAAAAACgkQ/reFK+KbPocA 2w/+ILDTKRE4x9ma2xshXSmhSX64Nq1C1i6QCUjMFgTAjrrc4eJzzBFi3mdqzfiXfqux51Q+Rbkv szqoM3+GQ1l1b6ksLC8X2gxyOiOGo3LVTkhF1jJL/1/v7UnxzVqfQD9qq1ALQhxWuUN3w4LO9Y7T hNNLUD30Km4eKOrb7CxLx4c/oWQlCHVx6UyJs5H9hhWcWILqiH8Lw6LYpahoCN8dO6tUITfFZo4+ LAAccrSKrO/URCTCCvh6wXjkPxrIl4xv7z6/zilI9qq6oIrFueeXKln/4SC7jhJPcRPGxjTIpPkX wI/cGwdf7G5qI31tQRiRBJI0tQ5wZDHSPCk+lyk39nE/wUWsfkfxfbPzLRraO2H/V/jHIPeH/cDB 0uzSDZC90E5DNOEdlSsEL5GQuLNNUMgo4FvbcN8DwNjYZaIrIe1V3blk31idocIw0/8U4J9kGlQf LfAmZXjhLVGfV9pnQDBAQhDAUGxwjn+lhK/TtT3QIoWXTIyX5gXBicmSmk4bpl1pnncoLBLNAbw/ Jm/akdBWaGCV/zKrr9Y18s/WFFF0aFSB2yNLQ4/pOv3SuGjNGvmIoT5055eduNdXBZmHEPUyVnCG kP/tIc0O5UhimOnxAYGTGRt1Y55k8obStLubWPAO1hsvBkQDZ3aIM28Ic+du6hVmwxL3BnXIpwj5 nsE= =gvkK -----END PGP SIGNATURE----- --------------CKkWOqTk6p0PIDBz0YM2LpDh-- From nobody Fri Apr 14 00:24:01 2023 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 4PyHHm1DkRz44y42; Fri, 14 Apr 2023 00:24:04 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) (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 4PyHHl6R45z3jcR; Fri, 14 Apr 2023 00:24:03 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-18782426c4bso6948140fac.9; Thu, 13 Apr 2023 17:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681431842; x=1684023842; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RyuexlV/yrBS+Yes7wNn0L+oR/KK+F72RG/pzN+BZaw=; b=icprlOPFyZuOL3mENbsVw5vYBJNZqw5NGkq4lYipXozRr+7kqwJrHE8xepOAJuTu6F f2VropqCtAdoX90Zku7wvpLt/zm9sC52wj/9HdGf9KvrgBwcCvPiz4E/4uOvDl49yrw3 ReCOK9Ujcv+a5kqfhZV1zSsQkgH7vkXt+uQetfRTaf65pcT+Br13uRO1DHrs6lsYQmMK 2jlesWwIpBDORS7c+xiOd0KONzfiM5iITvx4luXXxcqLzQAqhT4AsUhHKO6NSFwYZe1z x8a6LW2zoyY/2PH+qk8VFsQn2CTytEuBhSJnDgDWpwcQIhY4ZGY0Mm1kS25KIKTGwYXu dUaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681431842; x=1684023842; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RyuexlV/yrBS+Yes7wNn0L+oR/KK+F72RG/pzN+BZaw=; b=b/SzbxL6GgGbP37zAoGZPRN050AH0nBfTuqfv38yLwG60HLDWsXJ6fh3LF2pmLdzcd l0Lqqlri6EvR183NyHwWhp5N2rYWUFebRz9AlJiRTd2hW//0qFu/5MGx8abw3rXJwjkN XNvpac+elrz6q/c1Caw1SQHtYfa7HPKxgBF6gROnDTZAAuMdvcHX5uhCBLzfkt2rH4Gw u6ECx4VDjacD7kUAWRNAZfb5QcIwSmTVZ6fWAi27gcyQ1fCGaAgG00wPhdvlotZ0oCh7 hUiSvi8dZ7AYqhGycZzMoN56mfVsWML9L2IIH6kA54kPfp12uPNOiy3rpckz5YQg1NoS N5FA== X-Gm-Message-State: AAQBX9c/8yP7o2Q7f3uxoC9uRiz8ijoaV0DMl8mVT85NiN7S9DSQGyUk /u0QKjBTEauftO9YbetfZndsXH6UGpTjs3o3J/1ZjtL6 X-Google-Smtp-Source: AKy350aVezNXQiPTTKo316DZht3Y4OwAimUnG5FnerfIwip3sw+sDi3WabSmYkVmAH2bo1hpDnl1hrtR3xoejvQvj2E= X-Received: by 2002:a05:6870:b510:b0:177:ca1c:2cd5 with SMTP id v16-20020a056870b51000b00177ca1c2cd5mr2094490oap.4.1681431842389; Thu, 13 Apr 2023 17:24:02 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:74cf:0:b0:49c:b071:b1e3 with HTTP; Thu, 13 Apr 2023 17:24:01 -0700 (PDT) In-Reply-To: References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <6696e95c-0879-dc68-2839-06f77eb7c0e4@freebsd.org> <3ac74c8b-db46-c4f5-cef2-9f09c32903c4@dawidek.net> From: Mateusz Guzik Date: Fri, 14 Apr 2023 02:24:01 +0200 Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: Charlie Li Cc: Pawel Jakub Dawidek , Cy Schubert , Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4PyHHl6R45z3jcR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/14/23, Charlie Li wrote: > Pawel Jakub Dawidek wrote: >> On 4/14/23 07:52, Charlie Li wrote: >>> Pawel Jakub Dawidek wrote: >>>> thank you for your testing and patience so far. I'm working on a >>>> patch to revert block cloning without affecting people who already >>>> upgraded their pools. >>>> >>> Testing with mjg@ earlier today revealed that block_cloning was not >>> the cause of poudriere bulk build (and similar cp(1)/install(1)-based) >>> corruption, although may have exacerbated it. >> >> Can you please elaborate how were you testing and what exactly did you >> exclude? >> > mjg@ prepared > https://gitlab.com/vishwin/freebsd-src/-/commit/b41f187ba329621cda1e8e67a0786f07b1221a3c > > which only removes block_cloning, rebuilding kernel only (buildworld > fails) for me to test poudriere bulk -c builds with. I used a world from > https://gitlab.com/vishwin/freebsd-src/-/tree/zfs-revert which consists > of reverting the merge commit plus a few other conflicts, but keeping > vop_fplookup_vexec. > I'm going to narrow down the non-blockcopy corruption after my testjig gets off the ground. Basically I expect to have it sorted out on Friday. -- Mateusz Guzik From nobody Fri Apr 14 02:05:57 2023 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 4PyKYV17Zwz458Lj; Fri, 14 Apr 2023 02:06:06 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from mail.dawidek.net (mail.dawidek.net [94.130.64.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4PyKYT67Qqz4JX0; Fri, 14 Apr 2023 02:06:05 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from [172.20.5.159] (p7123-ipngnfx01osakakita.osaka.ocn.ne.jp [114.160.237.123]) by mail.dawidek.net (Postfix) with ESMTPSA id E627B4F567; Fri, 14 Apr 2023 04:06:01 +0200 (CEST) Message-ID: <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> Date: Fri, 14 Apr 2023 11:05:57 +0900 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: Charlie Li , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> Content-Language: en-US From: Pawel Jakub Dawidek In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PyKYT67Qqz4JX0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/14/23 09:23, Charlie Li wrote: > Pawel Jakub Dawidek wrote: >> Here is the change that reverts most of the modifications and disables >> cloning new blocks. It does retain ability to free existing cloned >> blocks and keeps block_cloning feature around, so upgraded pools can >> be imported and existing cloned blocks freed. >> >> It does not handle replaying ZIL with block-cloning logs, so make sure >> you import pools that were cleanly exported. >> >> I'd appreciate if someone who can reproduce those corruptions could >> try it. >> >> https://github.com/pjd/openzfs/commit/f2cfbcf76a733c44e25cba8c649162ef68047103 >> > Does not apply to sys/contrib/openzfs tip, conflicts in > module/os/freebsd/zfs/zfs_vnops_os.c and module/zfs/dmu.c. This should work: https://people.freebsd.org/~pjd/patches/brt_revert.patch -- Pawel Jakub Dawidek From nobody Fri Apr 14 04:27:07 2023 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 4PyNhJ1TBFz45LxF; Fri, 14 Apr 2023 04:27:12 +0000 (UTC) (envelope-from vishwin@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 4PyNhH3Zl8z4WnZ; Fri, 14 Apr 2023 04:27:11 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681446431; 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=mLH8yCIwm8TRja0NfbwmxzGG16rzVjdBoP8wvRkaJ4I=; b=jMv0gP8KW7LGebWWH3FUqutNSPBxMS5q9FWZCi8OYW4twP2hnqUicg0N8b9mIif1UyJ6Th EW+B6B+P1vUQ+dixo0+92UPYWivAa42GwZ2mTO+YNiuC48+XRhDUJQ7+dTHG7jyRvOsZfV VOQbbMiUQQ5hsYj3fhTysOY5R+xZGwwwozAH0xDHQl1cwrum6PZ2Ux+MvPSS2DitpFx6mY BNxoRHEeJhYqUq6c/i5IC3UK2kmzpo6OJPLHgkYdpAXC1N+OJkP8RP71FVJab/eGYguUJW +l0lmAsXf2ZIqJ7wYVRY+ABTV0WXcUliDX13hMXjTAa4UwylxP3E8WjcXcCewg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681446431; 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=mLH8yCIwm8TRja0NfbwmxzGG16rzVjdBoP8wvRkaJ4I=; b=UlStWPh+G7rh2osxd9knKxh4Mbdc2q6DeB7uq+ZGtNIbSZP4zb7tNkQGV71KZXkFaiIY0v weJwlpr2ZGB9k/Xpdb95ueVsQI5yMCEhfqRQl3wHbPzrx6ReW66VpGDvnbCnVB6IwzGuIp F6mo6CHL/NYgcwgALHI8P6+rcGrwK/PYlQ8MK48RirdtJFnEbBZ3XDCn7tNzgBrSrqtJHm cplSzNeOuT51cafzrDuqWXaTrSs/9bP+G9Hds+JiT8aH+kwFFewBmxZGk5tIO9B8N7zgcE jD/1AtAOtf5DkUTyOdoCTFv18PRRsZ6TrWc5gIn1Jcd33F0SCDwAO+7mhsJyag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681446431; a=rsa-sha256; cv=none; b=kjKxcrOD6hIB1mxtMQrLz/g3YE6fruJm+ecp4Qj7FGMETilzeoY7MtYVYUs+237W2fPQEz wuqr29U/6A46tUxf+YBTXErh0eHGphmtXDqUpVKUHQt9srS0VDS44J/HkvW7ilYJhUF/ZF yKxWhXsarv2/43vBq8G2wn3xtixRwbT/OH5HpnT3TnMCJO9bvJ+48q3rxxmcIKvG37dDZI +Szwh92orXk3EIlHCqKwNtliWOj79RZJ7IieTRfdAijoYZBozuV1TEwYudk2Il72EmIw6y tMNPBtbJxWiaAg3b9akePuc0S2ePFZegWR19luF63F5Ibf5oCgAtOuqSAfFoxA== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyNhG5LWNz10qD; Fri, 14 Apr 2023 04:27:10 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> Date: Fri, 14 Apr 2023 00:27:07 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Pawel Jakub Dawidek , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> From: Charlie Li Organization: FreeBSD Project In-Reply-To: <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------F9eTSOcYS7Wjt0wuTvJoGuDO" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------F9eTSOcYS7Wjt0wuTvJoGuDO Content-Type: multipart/mixed; boundary="------------6VyQYLkGjCMzbRUMAkjPjxZH"; protected-headers="v1" From: Charlie Li To: Pawel Jakub Dawidek , Cy Schubert Cc: Mark Millard , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Message-ID: <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> In-Reply-To: <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> --------------6VyQYLkGjCMzbRUMAkjPjxZH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGF3ZWwgSmFrdWIgRGF3aWRlayB3cm90ZToNCj4gT24gNC8xNC8yMyAwOToyMywgQ2hhcmxp ZSBMaSB3cm90ZToNCj4+IFBhd2VsIEpha3ViIERhd2lkZWsgd3JvdGU6DQo+Pj4gSGVyZSBp cyB0aGUgY2hhbmdlIHRoYXQgcmV2ZXJ0cyBtb3N0IG9mIHRoZSBtb2RpZmljYXRpb25zIGFu ZCANCj4+PiBkaXNhYmxlcyBjbG9uaW5nIG5ldyBibG9ja3MuIEl0IGRvZXMgcmV0YWluIGFi aWxpdHkgdG8gZnJlZSBleGlzdGluZyANCj4+PiBjbG9uZWQgYmxvY2tzIGFuZCBrZWVwcyBi bG9ja19jbG9uaW5nIGZlYXR1cmUgYXJvdW5kLCBzbyB1cGdyYWRlZCANCj4+PiBwb29scyBj YW4gYmUgaW1wb3J0ZWQgYW5kIGV4aXN0aW5nIGNsb25lZCBibG9ja3MgZnJlZWQuDQo+Pj4N Cj4+PiBJdCBkb2VzIG5vdCBoYW5kbGUgcmVwbGF5aW5nIFpJTCB3aXRoIGJsb2NrLWNsb25p bmcgbG9ncywgc28gbWFrZSANCj4+PiBzdXJlIHlvdSBpbXBvcnQgcG9vbHMgdGhhdCB3ZXJl IGNsZWFubHkgZXhwb3J0ZWQuDQo+Pj4NCj4+PiBJJ2QgYXBwcmVjaWF0ZSBpZiBzb21lb25l IHdobyBjYW4gcmVwcm9kdWNlIHRob3NlIGNvcnJ1cHRpb25zIGNvdWxkIA0KPj4+IHRyeSBp dC4NCj4+Pg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9wamQvb3Blbnpmcy9jb21taXQvZjJj ZmJjZjc2YTczM2M0NGUyNWNiYThjNjQ5MTYyZWY2ODA0NzEwMw0KPj4+DQo+PiBEb2VzIG5v dCBhcHBseSB0byBzeXMvY29udHJpYi9vcGVuemZzIHRpcCwgY29uZmxpY3RzIGluIA0KPj4g bW9kdWxlL29zL2ZyZWVic2QvemZzL3pmc192bm9wc19vcy5jIGFuZCBtb2R1bGUvemZzL2Rt dS5jLg0KPiANCj4gVGhpcyBzaG91bGQgd29yazoNCj4gDQo+IGh0dHBzOi8vcGVvcGxlLmZy ZWVic2Qub3JnL35wamQvcGF0Y2hlcy9icnRfcmV2ZXJ0LnBhdGNoDQo+IA0KVGhpcyByZXN1 bHRzIGluIG1pc3NpbmcgZmlsZXMgcmF0aGVyIHRoYW4gY29ycnVwdGlvbi4NCg0KLS0gDQpD aGFybGllIExpDQrigKZub3BlLCBzdGlsbCBkb24ndCBoYXZlIGFuIGV4aXQgbGluZS4NCg0K --------------6VyQYLkGjCMzbRUMAkjPjxZH-- --------------F9eTSOcYS7Wjt0wuTvJoGuDO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ41hsFAwAAAAAACgkQ/reFK+KbPocN Rg//daBAayFMuQzL49ZCSn9brNqmZmZhyoqJsEc+5rBwwyS9soLy7GbEVD+6MhGJ4eaniYaNOJAG DFxBgzl8YHblpFTJwoHY6tZt7GP/teBQx5DedF4DAe5e4/c5igtBfIvC+aGd5JQeUzeGWWMELn0Z dZwZLoxucpebjS/YWB3s2xRfdcFE/Up4kqBW1Sq11v8uoH5EkEh0KiJ02FFqQGSeJ1WLD5GYVk5D PCW770DfGcazDU/p3mysVNKmgv1OTr90sI/DdvhN0OarIPLmA5Zwf8jA8tHLsjVpIqV6ShZPgQRY pbY1Fu1lOayFvOWMJReRDNN66lYgNzBImffPhtYEt3r0xtrij8awlg8R4BudsrrDyk6tii6XjbXL jXolWzkikfy291+ssVlCK9tqkU1tvT/jXl89bWzRDCoq3DAT4mZMBxT5mAHQwNrnt80aJO9Mc2ZC 9KbeBfvRlxKOV0SvbFHOuudp3YZMMtlVPV5zfwaueIrVF82R6M/aMpgc+lXXy4nX0/YWy+oDPuDM ARr1go+gcoFs+0Gf8r9/1QIkQMJIaFEhK498l3udd34cLklf+k7qLIu6d3jksywrWLlVNyfMWANd 3o1FEffv/9YKWp2eTuWFpXZUhxetxcge6sSuIt0joY+Q61im5zyVUCSAE10yakt6+19Dpv02OQi2 Tj4= =iAPk -----END PGP SIGNATURE----- --------------F9eTSOcYS7Wjt0wuTvJoGuDO-- From nobody Fri Apr 14 04:39:29 2023 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 4PyNyq0nxxz45Myd for ; Fri, 14 Apr 2023 04:39:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4PyNyp25ctz3KcV for ; Fri, 14 Apr 2023 04:39:46 +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=1681447184; bh=qLb6C5wf1sfaU+vK5XRO0Wkqy7nDPZ8gJDhNpgp0XXQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cD1vl7Q61XBxhDb/uJbe/pKYuy3wuzw5Bt5T3G8FjNpt4qGL6X1SE6zM0rmDgb2JBg9Typ7/sjFh7djtD2UBe7VufoMzhoLtWf3ATtw1Zl3y0Ua8f3qRoW7A17dikedLUqP5Eswnk5wPW/1p4uint+PQM+gGt0jHyK8OIf6H3YuBY6oNkU+kKOFoms0bc7eIj5T0ofoU1waLyw7+jP7fnm/UME6IBo3yReswsGnPSDGppKsnJH4Ext9laPvNE8CwpTZS738gDz6VxfuaaqthduT5I9wUC+Juh4y4XdG4jwlZLRzTInxdJHciJyTjFP4FAr5F2Cj7xIGFj1bqMjxmxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681447184; bh=CGM3pJy48LezBw+Z6gAze3pZQfOq/xXkA1s02GA3oNz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KvGWN2zoTvtjsIGrkSCckOoDAUQYf7Ud7fFoDEEt/q0rA3VKaiM55gS7W/W+ugF2A64U4mww9Wo9kgOUe5SMBxR1EctUfx4A6Gmp1l9P3euP+LXcwrf0pyaCpn6dO89JObUAH8EKkUAeoiyUWn5G3Ncpjrh5jUxBcb2rtRVYFrLKaomQtOImuUtrUORJzUUEboo0mdsVJ6Z1xITckX5xua6cTzgQtHBOMpbgQyO3nIDlhH2ruCihwYOQrpTER1c8q2eGX3tqdgn/lxPv6i71YpnrbTCz2UMkov+PZ1zuitTWMsGmfIZOK1I7xzlgzt+EYsEbqSA4a9zutY0xhgD2jQ== X-YMail-OSG: jzZh44cVM1lgr.ym2YExJc6STphNciotXXGnNPxVXu1o0U_MjjX0IwRDA841j21 GWYR1LhpxXGSP2Na.OCXuOaKbOf49tUlj1MNtZ_Od9ZFOZ.i1hVXjdHK4aFT7PlvLIYvyWlkD37_ _btIoiZY3Kv.SduRW5MWXW9dhhgBroSk4XjtJ32vMWK49m62XLa94mL8BkAU64o_VMsw7_fD45Ju Rs9dVs.KAFzzKusa9YqyFv9EGRd34cH2iCZRflpCICbc7.aeDsIKoJzhnwaRbAN.KCD4cKIBOwkv 5HgVeUnx86Ogm07GIVj9VMa8LhcRCfRvKBE_WdUny.d_v90Cd.IshHUXUd6KGsrxiSjl76BxpXU. Cg0Dd_fjOqZUu1OTWZ89rjw1pWdbsaVRnGxrMNbE4K4KGs1__nVnR5UdcE0cWCkBW3NsEz5pDRBs mfhFcakw17hELJB0kg9aBC83p1I87jDq2NWsG.DW2LC5N0ddOH6VZOs2AsFuYgyzI4e7h0169B4U xRvHCAksdNtG3IRNbsSmQNoofZP16sBJq1FOdv9AsRYCZ5sGEtdUnbysub4enQruOoc3q4VK6WHp 24nmofYE3B_pT4hPgnxEIYYHjB27y.4tLftaU3XbYnL3AyukNQkQ_mMgM2U1uRzAiuG6GqPYZTSK 0QCLzoc06gnd18Idi9UjEyIibNpXgNcGnqltEGCu.1WSUhBnF.JPVq4.Gp.apcvjRRm_xJgVKmZb 5yF6MvPGnrjBwlBYZfUJCAJIrVzHqyz0ZNkqyNQ.L0UO2ry6YcRhQqzT6uYY5r3mWbuSdjS_jMF. CeBzcNpO4gAL07ejuLtBEASy1T4gFbl9AsQJL4dYV0MJn57g8q6LsZvQ2fyBkNp7mKeItsjoDKqD .QdmVQlb1qN7e9rxuH.utgdpkk.vTcq6cqHKZL3haWKl61H5BTE9IJyZfFU488LNVQaVLJQ1PHrD fneyolFcmhWe.JmcMLJ.OFlYpTt_cFmJgsqA54dhIAycHN3pBwEC7s_4JuxFJoVf_1YTZOzJiBF8 U_SyN7bRyU8YwZWzH_H9XUTwHXm6jlbXwCXLeK4KiiV9SFmMh4qPYLBDlsLt2Mas7FiWRxcYxkGj hGyjlpOc4ahnjgZjcpTD4l6oBVIRSbfCxjVcAUZhm06D_aSKKDRrcrLVOZkT_Y6XTcx20Prc61j4 al5pKIVoBWw.UIQ1XFCkP2WOzjWNmAbipNNGrb5cxu9M6_R0qKFIIEaaKckKnl8nOwZpoF9qPB3N 86p7d2j6aqB_HRJnkJcysKIGukkqsy5i0qF0lEM_st4_qfGA3IsY0ikTfnSpTYgDMJqr5NulVL0_ z9yTN_A00FY2ExI6K0Y_MVDRgZ54Rd7A5cAxEV3jXl4gozDQBjGHBeTYLxmV3yRy4WTynT1Va6_3 WxdAlD553vAa5i6RRdr_BVztoheVIjGgHhEgB2ACqwd1K4gHo71H.HCkTTgnngCOpNeCO_kKEHis bLghdvf9wg9G1oGUe_KB72CZDuRcHVKo6pB0cRrDikbvRHFP8jWLagRoBvLNMdk6Ad_QxME3c6dv XqtOwDXW1YBgj8IbZUYFJa0DmDTa2rxLvdth1uq0NMKnVOMKljj7lwqH8bE9uGPuro5qGjN5jbv7 11kFD82f.GroMdrEadlJF51xQC_Mo9wNWnD4ihcOp3cvap47Cc2W0_caKY.OUSmuRNVPjEPeCgc8 92AKWSE3lS_ybbkwk85ktPzHf7CMo0FLZ2bv4EVrG7QYJTpiPAh2nB47jaIud8zm1nH3JMhvP2.b MJi.RU5oPM52_.0tltIq9KCHESUEh8Yqw29ldKoInLMMdhnpm00anlMfXOKsUR5u0RE6R1PSnITQ 7ES.TIhWpu2RDMh1bjB_cgNQQtOKELSlYmjlopS_aRt23bLQ297.n5WyFoEdyrje16cOup5Tbtiw w2xnycDsTosJtlaS1gX0ZNSPxPIPglhXABdjnk6pBR0Q8wxrjVGDv8sYII2polAlsgq5oDHNmTq0 aosnpYxtXMBtxeMdhtRW4r0KNRKUNJLIb7.CmtxyIe.HX9s3Zti9zTh00vkFsHeI5d0UsWVwiglP k9Hlz9ZgkJmG7ANFgkLH6G6K7SKMy8YOFnQ4WUMrlq2fUiNIVxzulOr1Oi0PZjZKVBJDgTcCQ6gQ gXu.D00poGzVj63LclCQ9.hvxGOHAnyf8gKBK5ho87pkfMXK55XlTfVZIZ_kVxjcgjHJhcTXLh_O MpnUDTH3JGshFz9oXrrGUfLmxZCGszvE0JPasQMnpd.keyLulbKqxSa_LQfqC0QGySu0wQDzhXvi Q X-Sonic-MF: X-Sonic-ID: 893398a3-e78f-45ca-9925-7e16de6c4638 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Apr 2023 04:39:44 +0000 Received: by hermes--production-ne1-7dbd98dd99-zgnmj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a8740944bb247395853dd8ed0631549c; Fri, 14 Apr 2023 04:39:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> Date: Thu, 13 Apr 2023 21:39:29 -0700 Cc: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> To: Charlie Li X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PyNyp25ctz3KcV X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 13, 2023, at 21:27, Charlie Li wrote: >=20 > Pawel Jakub Dawidek wrote: >> On 4/14/23 09:23, Charlie Li wrote: >>> Pawel Jakub Dawidek wrote: >>>> Here is the change that reverts most of the modifications and = disables cloning new blocks. It does retain ability to free existing = cloned blocks and keeps block_cloning feature around, so upgraded pools = can be imported and existing cloned blocks freed. >>>>=20 >>>> It does not handle replaying ZIL with block-cloning logs, so make = sure you import pools that were cleanly exported. >>>>=20 >>>> I'd appreciate if someone who can reproduce those corruptions could = try it. >>>>=20 >>>> = https://github.com/pjd/openzfs/commit/f2cfbcf76a733c44e25cba8c649162ef6804= 7103 >>>>=20 >>> Does not apply to sys/contrib/openzfs tip, conflicts in = module/os/freebsd/zfs/zfs_vnops_os.c and module/zfs/dmu.c. >> This should work: >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > This results in missing files rather than corruption. FYI: in my original report for a context that has never had block_cloning enabled, I reported BOTH missing files and file content corruption in the poudriere-devel bulk build testing. This predates: https://people.freebsd.org/~pjd/patches/brt_revert.patch but had the changes from: https://github.com/openzfs/zfs/pull/14739/files The files were missing from packages installed to be used during a port's build. No other types of examples of missing files happened. (But only 11 ports failed.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 14 04:44:52 2023 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 4PyP4l03Jdz45NRM; Fri, 14 Apr 2023 04:44:55 +0000 (UTC) (envelope-from vishwin@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 4PyP4k3mftz3hGl; Fri, 14 Apr 2023 04:44:54 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681447494; 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=FHjMxtu801teBV7tBfFkBI3elMTnj+L+NWw+rA//u1w=; b=Z3iA5jasYchVYAjQcuIjHC0ff5oz0ZJVy1qiqm78Sll3pPNkLpRLhAciFzlhcVJk+QmwuD l+9bBxYarvg5JG4IxCdEWczLJWz0Ojw7/8zaX2U0nEDRu96nZB1L6KNCPitXHwFjperspD NW6Gl85FqXWpnMB/ysUPTukeZ2zE9Q9u5Hfllu89S7UF3suJ6GoemBzzue6ltmcxspTwDz DgDkMOUZtMsRGOwr/EoIfDYqDJtFtg4hSXyskmbbEevJwejCI03iDyjXyhmQ+ctVGuY586 watN4PYsPCdRJW39Z3tA28nzwdY9hACzZL6gZtDzqL9GDdOokDUKDNPYqfbbPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681447494; 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=FHjMxtu801teBV7tBfFkBI3elMTnj+L+NWw+rA//u1w=; b=lypZEHYeZurk8kQ5pBsdOM8PoUqtm9BOiGOZWWV5+4AtsYyNSkKLaWbJi8Mz6pLroejHDi L5x3q7NPII6/CYw5iQv6dgG3CwXrUx1LStzFLgjpN/93AtUlDDILDHNflTI5g8qh2Nojwl If3mwSdkkN7f0PxTJI/rKWFl6eVfdUKE9v5Ww3siMSQY/MHvkku3OvLLOkN4THXZAiR4vz u6Zt4B/jxct1BX1TZWl4mfl/dR7Fnb03cnWRr0Rm1yP7NT5zUCJj1GsR+CN0MRMTxjZvXv fb2m2zn200UXqgPhOLNgx+0INY2L+0v+rY4k8216i1XqTHD7xLWM2vwbj6dPcA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681447494; a=rsa-sha256; cv=none; b=c9EbO0ve78BZzDOkZ7Ij8WxLiQ3kdbA4Yi5xXmgAf+9uGF/CsneyuCjul9QdUVrwRsPOPJ HvBP6uKlB6Y8tSHansZygbVMD8EVU40Ru1fIQ+WUSP6HClBl5kC8oVviHOgW4yCEvJ1WDD s811tjANWE1it5ZCGv44ILZ85vSMJ0NAFHj9totMNI7rvl3SB/ruRshhhidH+QN+/1U78i 4HbcXp334qjUacLZFvGAM8FwjZamWYtDrGnVDA65FM3KpYlhuLZKDunPGHp536mYO+GyOC zZqfK04PLTaauxKX83Ng90i/HeS7P3RYfMRyZ/K4EaWJP/aApj1kPSWgO79XNA== Received: from [IPV6:2601:98a:602:da0:1fa8:be6c:38d1:bd] (unknown [IPv6:2601:98a:602:da0:1fa8:be6c:38d1:bd]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyP4k0Khwz1160; Fri, 14 Apr 2023 04:44:53 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> Date: Fri, 14 Apr 2023 00:44:52 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-GB To: Mark Millard Cc: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> From: Charlie Li Organization: FreeBSD Project In-Reply-To: <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------QI2eF8dJ2urjgRjWgoORwkvO" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QI2eF8dJ2urjgRjWgoORwkvO Content-Type: multipart/mixed; boundary="------------0MPUJqCt5SiXutVNb8M0v6Oa"; protected-headers="v1" From: Charlie Li To: Mark Millard Cc: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Message-ID: <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> In-Reply-To: <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> --------------0MPUJqCt5SiXutVNb8M0v6Oa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TWFyayBNaWxsYXJkIHdyb3RlOg0KPiBGWUk6IGluIG15IG9yaWdpbmFsIHJlcG9ydCBmb3Ig YSBjb250ZXh0IHRoYXQgaGFzIG5ldmVyIGhhZA0KPiBibG9ja19jbG9uaW5nIGVuYWJsZWQs IEkgcmVwb3J0ZWQgQk9USCBtaXNzaW5nIGZpbGVzIGFuZA0KPiBmaWxlIGNvbnRlbnQgY29y cnVwdGlvbiBpbiB0aGUgcG91ZHJpZXJlLWRldmVsIGJ1bGsgYnVpbGQNCj4gdGVzdGluZy4g VGhpcyBwcmVkYXRlczoNCj4gDQo+IGh0dHBzOi8vcGVvcGxlLmZyZWVic2Qub3JnL35wamQv cGF0Y2hlcy9icnRfcmV2ZXJ0LnBhdGNoDQo+IA0KPiBidXQgaGFkIHRoZSBjaGFuZ2VzIGZy b206DQo+IA0KPiBodHRwczovL2dpdGh1Yi5jb20vb3Blbnpmcy96ZnMvcHVsbC8xNDczOS9m aWxlcw0KPiANCj4gVGhlIGZpbGVzIHdlcmUgbWlzc2luZyBmcm9tIHBhY2thZ2VzIGluc3Rh bGxlZCB0byBiZSB1c2VkDQo+IGR1cmluZyBhIHBvcnQncyBidWlsZC4gTm8gb3RoZXIgdHlw ZXMgb2YgZXhhbXBsZXMgb2YgbWlzc2luZw0KPiBmaWxlcyBoYXBwZW5lZC4gKEJ1dCBvbmx5 IDExIHBvcnRzIGZhaWxlZC4pDQo+IA0KSSBhbHNvIGRvbid0IGhhdmUgYmxvY2tfY2xvbmlu ZyBlbmFibGVkLiAiTWlzc2luZyBmaWxlcyIgcHJpb3IgdG8gDQpicnRfcmV2ZXJ0IG1heSBh Y3R1YWxseSBiZSBwcmVzZW50LCBidXQgYXMgdGhlIGNvcnJ1cHRpb24gYWxzbyBtZXNzZXMg DQp3aXRoIHRoZSBmaWxlKDEpIHNpZ25hdHVyZSwgc29tZSB0b29scyBsaWtlIGxkY29uZmln IHJlcG9ydCB0aGVtIGFzIG1pc3NpbmcuDQoNCi0tIA0KQ2hhcmxpZSBMaQ0K4oCmbm9wZSwg c3RpbGwgZG9uJ3QgaGF2ZSBhbiBleGl0IGxpbmUuDQoNCg== --------------0MPUJqCt5SiXutVNb8M0v6Oa-- --------------QI2eF8dJ2urjgRjWgoORwkvO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmQ42kQFAwAAAAAACgkQ/reFK+KbPofj XBAAqNDMrHSX84pWYWNzsyzXk8flGy6hkIm/HxKIu0+n8QyGBJsclQVL24uaUrHz6Jic/LndGU+H kX8aZDzDlBZczBzfBGnKS0zVmfsuSrnfGQGMhqclRcO/1VccUTZCbuvEV9RCmvW1TC8Pf3SsAzSG SEmNgY3m4DMV9BtSPu91YxXcQnLXWLOw01KqjEN2qALm3mi7dtAlNrpiK3SIImecOCV96+rWBTC3 tiOaOK/1luHpqR8WRg87z2HGY6p7unVdB/2UZht26LDgbNejIlEjNUwwOX9fN2k+f8atoVfeF4sh tpOhmEDeC1ZXJCY7lP1NmffvNTvS68oG6zIfW/HOJm3k2+wvMI2jl5bUOngqQTJw86Qrjo7BRTeK zPGy9DQmPgplqn4eecBbcca952DbRWrf+DcF0xkfl4QBtJ4DLQV8LQ0MKmLvSg+XY5BrvHgTooaJ Y8WIHRjDcuLLDdHyLusmpHy/rH85IJCvT97bXMH7lry5kVVFhhhE991k4gQTyXdq8XpDVpBuBISg bUEys2eW6vaQLEMu8DUS3HqiGY5P+BSU5e/wDCCOk7/MaBZPgnDr15qXGwG+Q5QqVt47iRYbt9Wb ThyCmV2SovIFvKpW6QrgWgSJ8KWYv5QgHhEx1cQP+oDPGUE67pO0RXuQckAagicpIDJHvQmy/VZa KzY= =Y5xh -----END PGP SIGNATURE----- --------------QI2eF8dJ2urjgRjWgoORwkvO-- From nobody Fri Apr 14 05:18:04 2023 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 4PyPqM3ztfz45QxL for ; Fri, 14 Apr 2023 05:18:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4PyPqM1bF8z3K3D for ; Fri, 14 Apr 2023 05:18:22 +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=1681449500; bh=0z6TPNvBeY6oLN/7UdG8fizR800pXgeuzm5Ch8U5FLk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bIcc1YcTVnXjj1fbLoK56bB6Huxndl9tNLkJl/c2cm4DAFQQv3OMzjcuPNJ7fnCaZcSmCmpWA5exfFPkmxMLVwr5y7HncjwJ5Qa/0JxNLqOE3Usfr+M5A/RZREqCrjaO8WsvazwSuK4ecBWiCTn+jYLDrq/ZGHMsMYXMfCBpITRjRBZw6xA0LA8aw+42haxq/RQVmNH4lni8P7xkdACg9Vn/pXr1/8/Ptrb+xXrfaTAN+THE80PbBXgmKmRAUf4VjYU8v3oFgCOjLQ39ghy1DuCrFnbYOVdY2TQkMNtTbGk2JKsmLwgp4umLujI6C930qcV6ui6QTzSeonZT3y5GqA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681449500; bh=ioFIV656JzI+wK8ZWQO0VYtAgpwUNULk+oAVUk6JfDI=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eP9JG5YAHgTcCut1oVW/g5YjXBIpQ3OwJ/lylvzmobiyxcewJkPVFwvgXjm5eEFYQQA1xILseyBQJXA6JFfxumzLVfIsjxP9B2VzwEfGGQLlNpu8ZKJ1CcCU05jw/OQCVm1JY/NEBQGEHkjN4qK8twhogyfIHEFOWrcpypIMzdxFTgz0SM1vE7CK9vIEhhGMBXybl/4jpHGxJsgSjQL/84bXsTXT5I+875JiE92ce4BIBRYdfC1mBQFIOqtk1sJUDeXagHHBHA2E0zYWtS3eNT3miBNFHLtOvy4VBQ5zkI/XrHK8zT6io85CV/+jvV8VaO1Tt1WekS62Iy9r5NdTYA== X-YMail-OSG: YLSilpIVM1l7LEZXS9h5qA.qBnEtZgRsKHJEkLVUtDaRXJuq3z.CXjZ7ySxm0BM FVooBTp0sEG1EgijcSiIx7wOxHCktKb6ZMasgHJVJqBjiyQ3lIbFPG9Nt.4mDILW5PDLoE7clYen _stal7R2jfBIQSsOyyIDfldzrELtrjLNkrSyuGgbqBfEbEQ3MJWYmzgLT6YPOqJfyWo7JuInn.tu h1lLTFNH2smGpnyBCboutjZinhVC9RtZM5rUBWGuYcpUv76zOt5EUM9itv4.5grsOmiOSmDeKXX_ oT5CoudtfBjRud_ZewK_sjj01M7fNncQJhWmZHZOjBoJDvfiNKhMFx9erRWvn0muYk_uI8TkShX9 TdXCFa1Oany5I4e2zfYLr3ptB_0W5MYw94xasBllF8y8UWY8aNtPDkWlo073eecSHxKjca.sdw4U qmbRxHRuz4oayg2iXpjZkSWIjarKva.WTYmUUHOBO07bsR0D4EwYEJIzBbBoHDv2g4Jrir_Fgf8z ZX45iGn.3Q9yw9HQITdxiFBx6R5O2JRiXDaqw8.7X6SuxteU9RBT2CNMUXu2cHF1eLWFq1OhKZwn tfZ.xaeUGn3ymRlGkXO.fXoU_O8lj_GsRG9KJ4RM9_Vmusvn8suLAx4G1lZorBbksNYa7HB5eawz oZCX2pAfk2HvJQ5CWGw6XH5IRXkJmaVSNKrnCSClk49f_jX8fB5LTK7LVOqFOa..DbAV8EeaAUI_ vNNLR04q1HnDpk7RBdtEZmNEYZ4b52km8jHjgFHIst4LCMp1sEN5NA4y.uqmcDS8yA4LbOtk5RPA dPHfDWHFiI9QJug6.X6XYH1aFAtR4h2Xfdx3d6LeD5fnKQlNXf2B2yRdlzZxZ9WtwyOUQ6XzZ1C2 rlSC_dffL4PSe_Zy3bMSqeWbmJPqaEFI2rT.Fk2VQlM57Oe9nMBFAmnfmJSjdutI13dxJUofe3sc xX7.5AQLss8eRpmtNVBy8qcEqtDPyQ6Pu8thBQqxG5MAsx_3t4Kq9pI8NzdIEDko8I92pB0Z2J2X U9wEZhfCyNUT4M0oMrzdvEgK78pOKcHMdhS6Db2sNyD2O65zxV.nfqASnJawt4tiUdAN8SJcBJGl 92BYU8i557WsBKKpYjwvs9jXH4rLJY5GW9nD2DNITwaWoRfFG9Dk39uPQPwEyat92yZ5MrN0QheD 9TGs4.AA3x4ycIQG_ZO0DmiI4Y3OVArP8b6I.uZ2Eeo4uDKNF8MWmzal8j7toZG_qUz3aCSk7BW8 jJ3hMgvIc81KnDUz0Dgz1Ci1ZWLSqudhhFDQNtaHlqyiMC6AD15Z4HP8FmUc4F1Oa6HI3C1qsDEw 0nzE32450pBHeYjmp_x9U0r5uyPHF5.hh8RoVvsp7pLBnOkOyMZViwvRWhNyAxTxCiP_emnk_rIQ xPZozQfZI6xA3xyJtZ56Lt7CionkSaQamL.TibqzrsTjrxpjvqMVpk_DkO2vcQ7B3R1KRxo2JKhD A_1Uxw_Ax8DZTTHTqkNXLxhcAcq10JTjjZDJaX3aUMNWuo2Ke_BDjc10G3KpQ2qdCNHrv9Bmd5jP jRaH.LmrOYaQnZMfJJI97DVNAIthPWeDEmbnhGrZk3DWaPAucpPd0nuLSxtuvGfjhqenArCymigJ 3zIvcMCjLy0vRbxGcwci9qvLdjY1B.37fXvO3ucxUPg5H4SLdW3vy4yygYMF75FezOQU2WzygLtB AHb011hrldP4fcVUxNmlPp.9VTZsPTCye7VybiJBrPFyh3Q45V8ltZwKNG3.SnlbLKWpavqcpzwZ vpigcQ6xcB8T6amhT2VtpL7sHRBmvl2O3pZrJ3QtSHF.XNiEQN4oyXY57eYm7kUX1bFibmYr00lk zVKk9lWiB91kjjlV188.hiO0yTwz7kL6Az9wPimGVp0xn_saIxmJXq7VwXalvC8wlNDRS8Q4iW4g 75o8zfrw_njh.hFRcHD6YOUr70boBv53gCByZQsujV0vKhkf7NPwbVA6GpUmzTTNCN1iRqRrXMbQ TjysEkSwJ24_dN8miVoPQ4g2wxBwr2nGrXKFSkvCJbmP27iPzdFo0FnucNi5uS1AKnPPlSNH32sf 9Pjn0PTz1xEPWYhCJ4MhknmgC2jSscyah7xF8A5D0j5BjGd3P94v7rGCwxeS1VkAO5hRHOSICQYp .djfc3EbGwjRxhIISfhlxV06gJWRQzEz6uaZrVLRVylvY7z_idtZPFGIyn8Y.RHTaPkpPjjV60H6 RPaRInv4wKra7NaYm2lfpoFlHUORw3Tk5BnevWcwmjQxphYCurcIvR16W8uxljAdwnZqjDWE0d8c hdZdQYa8- X-Sonic-MF: X-Sonic-ID: 1b698032-5a24-4500-ba52-f26474126bed Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Apr 2023 05:18:20 +0000 Received: by hermes--production-bf1-5f9df5c5c4-fgkgh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID adb7ed4b25f564d34aaeb70265d06145; Fri, 14 Apr 2023 05:18:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> Date: Thu, 13 Apr 2023 22:18:04 -0700 Cc: Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> To: Charlie Li X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PyPqM1bF8z3K3D X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 13, 2023, at 21:44, Charlie Li wrote: > Mark Millard wrote: >> FYI: in my original report for a context that has never had >> block_cloning enabled, I reported BOTH missing files and >> file content corruption in the poudriere-devel bulk build >> testing. This predates: >> https://people.freebsd.org/~pjd/patches/brt_revert.patch >> but had the changes from: >> https://github.com/openzfs/zfs/pull/14739/files >> The files were missing from packages installed to be used >> during a port's build. No other types of examples of missing >> files happened. (But only 11 ports failed.) > I also don't have block_cloning enabled. "Missing files" prior to = brt_revert may actually be present, but as the corruption also messes = with the file(1) signature, some tools like ldconfig report them as = missing. For reference, the specific messages that were not explicit null-byte complaints were (some shown with a little context): =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so - not = found =3D=3D=3D> Installing existing package = /packages/All/libxml2-2.10.3_1.pkg [CA72_ZFS] Installing libxml2-2.10.3_1... [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so - = found (/usr/local/lib/libxml2.so) . . . [CA72_ZFS] Extracting libxslt-1.1.37: .......... done =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxslt.so - = found (/usr/local/lib/libxslt.so) =3D=3D=3D> Returning to build of py39-lxml-4.9.2 . . . =3D=3D=3D> Configuring for py39-lxml-4.9.2 Building lxml version 4.9.2. Building with Cython 0.29.33. Error: Please make sure the libxml2 and libxslt development packages are = installed. [CA72_ZFS] Extracting libunistring-1.1: .......... done =3D=3D=3D> libidn2-2.3.4 depends on shared library: libunistring.so - = not found [CA72_ZFS] Extracting gmp-6.2.1: .......... done =3D=3D=3D> mpfr-4.2.0,1 depends on shared library: libgmp.so - not = found =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - not = found =3D=3D=3D> Installing existing package /packages/All/gmp-6.2.1.pkg [CA72_ZFS] Installing gmp-6.2.1... the most recent version of gmp-6.2.1 is already installed =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - not = found *** Error code 1 autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 checking for GNU=20 M4 that supports accurate traces... configure: error: no acceptable m4 = could be found in $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. GNU M4 1.4.15 uses a buggy replacement strstr on some systems. Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. ld: error: /usr/local/lib/libblkid.a: unknown file type =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 14 06:55:29 2023 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 4PyRzX0WKWz44cQM for ; Fri, 14 Apr 2023 06:55:36 +0000 (UTC) (envelope-from fluffy@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 4PyRzW619yz46GW; Fri, 14 Apr 2023 06:55:35 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681455335; 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=S+LrD+H1K7VcUhBs1W9GPuASRj5QQPcjxnuz/vfLqS0=; b=Dj1sOKrapnoQXD8YFTsVkm8W7Djska0hscKIo6QJHKkAkv+OQtNkwc5UKR/+KfXHQ4OGeR eXgxw16bLhq3+KKTorW3vN1vY6Sv8fAXTcp9OCR9UlwNTEL3P+Sh0qmNNWGjWNUaOqzI1O RcfIF6uR1u84DM3LiimqoVVFOvBpSLCSeRfOTGW+AKZMB90KizNB2k6QwhhoManfVPMYBA /wJg3IeFdOJUHwhZfX7QJc6Bbh6KieYhGUpCh4EqDPyeuqnT4+6VPBf3QznXz7BOQ9YqtH 08LdFc1GmKJsu5b08242Dies8G6Bc/nbabAAgkZ3DgGdatxJrRr9q1HJCkVdkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681455335; 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=S+LrD+H1K7VcUhBs1W9GPuASRj5QQPcjxnuz/vfLqS0=; b=OpENnmecSt+IPSntmFGAiycC0lbJKrG5WJQfqj86UKbVwVP/elSsm7D6Iwpg6cI+bcoicy aKfhNm088m2wQ6Fd2xu3AiOeqdvEyjONg3tJK357lOiYMWzIsgGp3j6xX9SipGaNPGHCn/ hraHAwPvMWencqTQ4kTq1l1HkKK8k3UXDsRQrTUbIFdorPOxubSHJwX3lPgtPq7mc9Faig 0joHWPc1X/msPGhdMGr6iLbTkRLBeWIcgco2WCl0KdaUjfRAO/jFyfXC4x2LiHJrI1Z9cN nV3fcmVjn8F2DBNPanfK4jComTLp62BVlzyHhO4MOSTjkS6s/abWQ10w9f1RPw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681455335; a=rsa-sha256; cv=none; b=c2eExstwfH9RwLHY/SO6xOkLNtRwdsD2sCgmUuksIXGydo7sZEXhfL2C5Y8dhG1bC7MS8A LuH5KBSqD/gXowmDjh4GKHXCCXY41rKxWNU05DtTgCLjAKp70HvjqYeNxQglLoUJfrm4QW J+7e8uVgDhlNd5xjYsLYbZ75IrwKIwWpKShEKRKT5dqLuq49P/mgPDHVZqb72bio8cD99O lijIQ9611oKo9n7CPkwbe9JAsR/IXljRoqzTdeVTWJuQeLuENgCqOeesb1BQBHEWeMM1Vm JY6V/oZBtbpF2UgBemcvBPiCXzol45n9STQXyE4W9xKuIYrbNjAopjE8n6osIg== Received: from [192.168.0.100] (unknown [88.201.168.234]) (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: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyRzW1bgVz139Z; Fri, 14 Apr 2023 06:55:35 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Message-ID: Date: Fri, 14 Apr 2023 09:55:29 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: ru, en-GB, en-US To: Dimitry Andric Cc: freebsd-current References: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> From: Dima Panov Organization: FreeBSD.org Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------I08sxqjqS6C8ZLvD8YVPb0Gs" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------I08sxqjqS6C8ZLvD8YVPb0Gs Content-Type: multipart/mixed; boundary="------------4JRxqsmxjoTRiU59OgASijvR"; protected-headers="v1" From: Dima Panov To: Dimitry Andric Cc: freebsd-current Message-ID: Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 References: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> In-Reply-To: --------------4JRxqsmxjoTRiU59OgASijvR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TW9pbi1tb2luIQ0KDQpPbiAxNC4wNC4yMDIzIDAxOjEzLCBEaW1pdHJ5IEFuZHJpYyB3cm90 ZToNCj4gT24gMTMgQXByIDIwMjMsIGF0IDIzOjQyLCBEaW1hIFBhbm92IDxmbHVmZnlAZnJl ZWJzZC5vcmc+IHdyb3RlOg0KPj4gU29tZXRoaW5ncyBjaGFuZ2VkIGluIG1haW4gYnJhbmNo IGJldHdlZW4gTWFyLCAyOCBhbmQgQXByLCA4IHdoaWNoIGNhdXNlcyBwZXJtYW5lbnQgYnVp bGQgZXJyb3IgZm9yIGxhbmcvZ2NjMVswMTJdIG9uIGFhcmNoNjQgKGV4YWN0bHkgVk1XYXJl IGNvbnRhaW5lciBvbiBNMVBybyBtYWMpDQo+Pg0KPj4gZHVyaW5nIFJUTCBwYXNzOiBzY2hl ZDENCj4+IGdpbXBsZS1tYXRjaC5jYzogSW4gZnVuY3Rpb24gJ2Jvb2wgZ2ltcGxlX25vcF9h dG9taWNfYml0X3Rlc3RfYW5kX3AodHJlZSwgdHJlZV9ub2RlKiosIHRyZWVfbm9kZSogKCop KHRyZWUpKSc6DQo+PiBnaW1wbGUtbWF0Y2guY2M6MzkyMTU6MTogaW50ZXJuYWwgY29tcGls ZXIgZXJyb3I6IFNlZ21lbnRhdGlvbiBmYXVsdA0KPj4gMzkyMTUgfCB9DQo+PiAgICAgICB8 IF4NCj4+IG1tYXA6IEludmFsaWQgYXJndW1lbnQNCj4+IFBsZWFzZSBzdWJtaXQgYSBmdWxs IGJ1ZyByZXBvcnQsIHdpdGggcHJlcHJvY2Vzc2VkIHNvdXJjZSAoYnkgdXNpbmcgLWZyZXBv cnQtYnVnKS4NCj4+IFNlZSA8aHR0cHM6Ly9nY2MuZ251Lm9yZy9idWdzLz4gZm9yIGluc3Ry dWN0aW9ucy4NCj4+IGdtYWtlWzRdOiAqKiogW01ha2VmaWxlOjExNDU6IGdpbXBsZS1tYXRj aC5vXSBFcnJvciAxDQo+PiBnbWFrZVs0XTogKioqIFdhaXRpbmcgZm9yIHVuZmluaXNoZWQg am9icy4uLi4NCj4+IHJtIGdjYy5wb2QgZ2ZvcnRyYW4ucG9kDQo+IA0KPiBBcmUgeW91IHJ1 bm5pbmcgdGhpcyBidWlsZCBvbiB6ZnM/IFRoZXJlIGFyZSBhcHBhcmVudGx5IGEgYnVuY2gg b2YNCj4gZmlsZXN5c3RlbSBjb3JydXB0aW9uIHByb2JsZW1zIHdoaWNoIGhhdmUgc3VyZmFj ZWQgZHVlIHRvIHJlY2VudCBvcGVuemZzDQo+IGltcG9ydHMuDQo+IA0KDQoNCll1cCwgcHVy ZSB6ZnMgaW5zdGFsbC4NCkRpc2N1c3Npb24gcmVmZXJzIHRvIGJsb2NrX2Nsb25pbmcgYnV0 IGl0IGRpc2FibGVkIG9uIG15IHBvb2wNCg0KREFUQSAgZmVhdHVyZUBibG9ja19jbG9uaW5n ICAgICAgICAgIGRpc2FibGVkICAgICAgICAgICAgICAgICAgICAgICBsb2NhbA0KDQoNCg0K LS0gDQpTaW5jZXJlbHksDQpEaW1hIChmbHVmZnlARnJlZUJTRC5vcmcsIGh0dHBzOi8vdC5t ZS9GbHVmZnlCU0QpDQooZGVza3RvcCwga2RlLCB4MTEsIG9mZmljZSwgcG9ydHMtc2VjdGVh bSlARnJlZUJTRCB0ZWFtDQo= --------------4JRxqsmxjoTRiU59OgASijvR-- --------------I08sxqjqS6C8ZLvD8YVPb0Gs Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEELTAsy5mEEwxvh7r8+4ugndU5jykFAmQ4+OEFAwAAAAAACgkQ+4ugndU5jyn3 dg/7BhhRw8aXX/nIjKzyrJ/Vm3qgGz2E+YU/EhCkXu3+xxd19ZVF+bkybMV6bUQTp8+D/PHjEYZh eD+1UFBUVLXFCzvsWfgpKyM+vYfifaBPC4EflyojteTUaoZTudYTwHsB6cI19yW7hL2UaGeyjp2s FTYSD88Ua6b5DXE1/3BafWCN1gnkYHtxABHVDvuK0TZa3m+7YAw99nUFa6iBGwipy7a2Ab1adrE3 CkhcsXXxDYjLPTjnl+yiQdl9vNlHtT5GB1B/5YD3yXY1pOOJAzDLAF7lOoorSU+ZlUrlEMLGJRdL XHPftYv/C25II5fd387g0ZRXdOtgvfKnNHi9DQb/gsYVMhX9L1QQGdv5nL8bg7Q1xPvp8EoMkSWz RChK+3gFg4uN7tWkkGjQDLSvw5UOkL9YF4U1t/RCRu3GO3NwDotI2nmvX5sVNxfyOedc2EyihOHX Cgbgv7oYCC/cBg254IF38DN2NCvvKULPhZYbRyCQTRdaVPXlJ4UjwANNR47ykjDhPx4slvk0urEK Vpgx1mXznna1vp5pBC1lh3bVwFPSG41BIf5X2cZOW2EIsnkcHIbvJpU9D0I42XRMZLgmYjY7ZZOW GHNZg9D0tY3SZJddGRWUe/eWU56wFNzct2jS8f1somjHYRVa8h++AheZZA3cO5h+NGmCDcJo3OCj Ck0= =H7a6 -----END PGP SIGNATURE----- --------------I08sxqjqS6C8ZLvD8YVPb0Gs-- From nobody Fri Apr 14 10:58:14 2023 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 4PyYMs2bLDz4519R for ; Fri, 14 Apr 2023 10:58:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (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 4PyYMq4T6Bz4MfB for ; Fri, 14 Apr 2023 10:58:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=S5jkrll4; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681469909; bh=csi399k91c36KNG0XUpZoZL7NP4b5AK7ts3pnjbfyfE=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=S5jkrll40D6gPpqRaqFZhR5xH1vw/i/vCENHj5kCqXzyPMDOjYxBRI+jAMv+ciyKOkrfT+gjZ7gHg0ZU8Gb1kb+9t8tUMkNSN3bzlHnJBO1y7+Cd41afhOH15gvvD3tUUddI+rrXky9mYAdPYJmWh90fsiW1TtZ2gFMKrgFOcWHH/KH4Ju4wy2JwA6GmhusonE+KLCzOyH0PqvlZznnyG9EbTRZ3mKwtkij7uy24HHJ+wi/I0DuoNxIR46WWNyLUvx8aKouhasK/rgAhVPbf5ULriCgNEBnLNwgxSZBuoP4gC39NaQFrcxfxZg0CAwxOosy2O10izEQOZQb9OWG/og== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681469909; bh=yHxDbLR3uap9eA3NgBUi6AkuDE5IU4DTLT8S8EXQdZC=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TC+MqZYS6QQsY5XnJ6psmnkknKqTl+Bvewk2h3wjcqGNlkp5FCud5A8QPLg1+czrtTTh3KbSLolNybGwQQscHpr7UXcccsOWDj7JAhB3IwMXLSy7shYRR0eF9Ns/wfL86Fj+Cjm5EC4hf4UZlFM7w1VAF6QBbeQ9OYFjJgbo2JZs0nQd5doKwlpK/4VnrHtLeh42qb2Dz4mGlJhiS3IhAeHe6qnbhM7c542UJTvvuNznAL6elV+MbTfpnXmNy/UOVxlWmeo0qG03Rpe08PnPHsIu3tADD0OlpE+TK2MzjtIPNFp1bsuDm8XT3pAAeo7EAR51srP3QeYhQkf6dtCMLA== X-YMail-OSG: D4PLIQUVM1khtG_uAancjzhup0VkM5ebIXpd8mQb2XMqdhzf.VdP6_vf6yHoFzS qw8cBJJ7IsiSAyfX9mr5ISnvgJctmFyuHjzOKm6_ppfiMNU02XoTcMj9JUhf9SqJanqVw9qEvuBo goJoL4kID102g082WeE4r0Nwca.h1zBgevDhoKf2L1Qy4XORbSLgPPmI_8yg0jGhquRwKq1XS1yk jbiSKHyA95.jnCoFGJb8weIGSIAVfPcbh6VxHfHMTYgxKSI0F1h55pHqyPWyzib92LfuUUWCyoaL Ft8aiAhJEl9WzW9RCsFp0uQkA1Gc2YgaU2hBb_oqtWh5kgXx8Xtv4ESDiFomX8uxpfZe8xnbbjlo m5UjOcw1xRVerRH1awrgooRbhrMG.vN.b72y3DeDFjDws3SBmcTzqnNH7nWQKOKgkK50D0nL_fCl iL.9aXlxMSE7WGHXvJgu0Cazkxrr5WWkW_GG1w0MOlamCtTvCsUNcZEIN2cIqRl5oJY03bBr5GCi 82YUqHLepQPYtFKftvvwCY8PDz4V7hnacLl2xYf3sOGI1OqDq7i9OeRFu9x.X93bIwstrwd7yKxW 3aBjPAvwwF3JWwl.3ThgsjPCINplPK0cNS9nvKVdfTX3RKaedTD4VS6gzLEo_yzY_b54nZEQ4Ymp 2ek2tAsOevERoL8A041UVffqwBpWnZfAJC.nL4rO9AEiWdBk673mNTR7SolkGsC_IyIEFcygoXin lRp.OginQMvttDrq_aDVmAwcSZxLL_ui4KH4UsSrAg1GMyEyZ1SGnCqjazEBnMeG6ji7J4e5ZkxQ HmC0yxTKlKByULEiofgf80WYZKs01z_Jt1eoF7fWfhOVWM7BlVVi07eJk5Gx7.dgp_wHyTm70sBM puBVV9WvoYWqDCuaZixgk.u27N7b_UQgQsc3wtQgghqOGjdp0oYGSBRNayIxYFrae83O3nxc_BeG WAkTwz4DseGK1pOsa5PcSDW2PsHMQ_JOJxRnvE8Z4wFwHPuEQrzPhL0NZnM6oBHWptNE1_0X5l5p .gnqSfhdAM7cgDzMNEEJfFpET2_QpuCWRrXFspi6MTp8FMy96LXqQc6RM4xUa1g5sR18etqyWOe. yXNqVBradOx2ZBMUo8Aw_yNR6Dee2LIusoyGbRNeAq7C.TvOdF6CkfhHQHYPACRY6VhR7i6Pp.G7 E9oYBjFMpIVfbSIFLYqkgeQMxV6HTdHcJSMTUxyQWkTMa.Xyr73LbUQVOtTcsvPOHr0_iVWtXiGT q8PUfzYJiTAk8a62WYJ5wV4VAqo9vseZmPf.KFIY9WLyElnSE9Ze4127dl1Ad582z5ye4XAk0dgl SLz5izb0N2eco0LUMGSiuEpSzxdZg1_n.2JqCgpU7HFejW4mvFNPJXtdXyD3ftyXxQEAJdPJ3RD5 2DzEtfvSCv7OPPr1bA4t8zm2.ECtd.HivoeeCBzYOEBoikYEAm4uS09dn5Jw1xtIkMIy.HOrZlCr z.o9UEKwX7fWxxitsfJppbwEGT76CnVw7NXEdPdBxyx2QAuCMiWTRfrbtFtb.HJAJUxqpv7JRwXM 3d5uYF6UvPB._Pug.sJZjsSQv5lNKzV5XB7KKmcHDFtj2a2cJONvojzqGR1HvdVnUQpSzcj3IUMk 4CcEET_YM54lpnPpXctJf4uAeLDaDeucsWtO6.TUzG8q51kHRadlFxpcvxNtFjV_nHZckjUScmc0 HjY8znnrPz3uGkhVm7rm6FyxsXBOI_5UvGvYiRO6n06ywC8bbNq16EIAoOmvrSCeG6cHvY0CGd4v NofuAk3cRtfUW4EuQXR6HHF88w6_ruVbTpH67hNS25QqMeAxZ0FXo8BOKBPdq8w1YF96qbT7d6MK ufV1bIYFoU6zvBFKXcjKBDLK.PDMHgoAbT0tb7m6TRRzBANkLUAhUMZEqykdmdvW.wetvImgyNGr sUU3DWYOiW9mHQ.zMfrFTQf9l_JseOFaBobZPkjAZ_3TAO0tHtI8Kl92J.timbKEdWwK9jyCQq82 NBCay9FrxoaVyvJ7Rg19LDNnhrhDRjEZ6yaW2My6rpcJrZIcJCPSKydNx6ZvYz_AWojVLhjj6QHq plImk9vcvZW0QyeG_3rKEkhfuyt4Zyi7TYzz5CTNMQod1Gwg8XzwfQqBF1.3n_3RUo8IW.9hEAPC YFg7nC3gjtyMR2l1eMvx6Wl.K0ob0uWhWbk7i.1bT4tKfTyc1qlKVGqjhUv2DS8bWdx_sQrCCuSh ijkJQOAjVwUrlxbFVo9vALEnRbmR645C7lJ6uiraIDfShK9OZN.yqiWYtymWNyKw2ufL8XfUYxNr ad3QcAstoKg-- X-Sonic-MF: X-Sonic-ID: 146e486b-d4b7-41f5-9155-65643d859b2a Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Apr 2023 10:58:29 +0000 Received: by hermes--production-gq1-546798879c-fmv8c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ed2088f2c8003fc624c8c595b1af4ad; Fri, 14 Apr 2023 10:58:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!] Message-Id: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> Date: Fri, 14 Apr 2023 03:58:14 -0700 Cc: Dimitry Andric To: "fluffy@freebsd.org" , Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> 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)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; SUBJECT_HAS_EXCLAIM(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4PyYMq4T6Bz4MfB X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N From: Dima Panov wrote on Date: Fri, 14 Apr 2023 06:55:29 UTC : > On 14.04.2023 01:13, Dimitry Andric wrote: > > On 13 Apr 2023, at 23:42, Dima Panov wrote: > >> Somethings changed in main branch between Mar, 28 and Apr, 8 which = causes permanent build error for lang/gcc1[012] on aarch64 (exactly = VMWare container on M1Pro mac) > >> > >> during RTL pass: sched1 > >> gimple-match.cc: In function 'bool = gimple_nop_atomic_bit_test_and_p(tree, tree_node**, tree_node* = (*)(tree))': > >> gimple-match.cc:39215:1: internal compiler error: Segmentation = fault > >> 39215 | } > >> | ^ > >> mmap: Invalid argument > >> Please submit a full bug report, with preprocessed source (by using = -freport-bug). > >> See for instructions. > >> gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1 > >> gmake[4]: *** Waiting for unfinished jobs.... > >> rm gcc.pod gfortran.pod > >=20 > > Are you running this build on zfs? There are apparently a bunch of > > filesystem corruption problems which have surfaced due to recent = openzfs > > imports. > >=20 >=20 >=20 > Yup, pure zfs install. > Discussion refers to block_cloning but it disabled on my pool It is not true that it is limited to block_cloning. zfs after the import corrupts data even without block_cloning having ever been in use, even as the code currently is. More problems are to be found and fixed yet, despite the several fixes now in place. See for example (much of the reporting is on both freebsd-current and dev-commits-src-main but some is only in one place or the other): = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014397.= html = https://lists.freebsd.org/archives/freebsd-current/2023-April/003446.html = https://lists.freebsd.org/archives/freebsd-current/2023-April/003449.html = https://lists.freebsd.org/archives/freebsd-current/2023-April/003459.html = https://lists.freebsd.org/archives/freebsd-current/2023-April/003460.html > DATA feature@block_cloning disabled local You will still get corruptions but they will not be as fundamental to problems restoring the pool to a good state. [There is work in progress to try to have block_cloning being enabled recoverable but effectively disabled other than cleaning itself up. But this will not fix the other cause(s) of corruption, which are still being worked on as well.] =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 14 14:28:42 2023 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 4Pyf2P5rZ8z45Lq0 for ; Fri, 14 Apr 2023 14:28:45 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 4Pyf2P2CPRz4MNx for ; Fri, 14 Apr 2023 14:28:45 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82e.google.com with SMTP id ej15so7067615qtb.7 for ; Fri, 14 Apr 2023 07:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1681482524; x=1684074524; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=XkyIxHetDhhiwCQGwKFA7ybmK+IKvlrPEvTT3V81Nc0=; b=R4peEwTNrbd8WWA54RNjQzjMSSzwTuB1DyUQd1+X7DPqxK/GMM097u8XIIl6yDQJez QpR19YTjOWZJZbWP5Mf0qPNIAM/OuDtuM9Zkms1SnWp24NZsD+bMs/ZmA1uNRRenG7jA PRE7hfIHU9cqwXjiGL710FjBKod1amIgW8IB8daMqSJpa0wp/yV5MDdpqWXaKhAEZDMu Mm/vG1bu9+uRQlTypiY5MVzwSGW7yE4Hv+SFrdanwIyyex8aHKJws2Zv2FPC2vDJ8iW/ hSkBTTqc9OZpRf1nQMvhFHQm5OnXroIXyQXgvSMbMSzvaDmMT6g4YXoVA8MlWN/tr1zV 86yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681482524; x=1684074524; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XkyIxHetDhhiwCQGwKFA7ybmK+IKvlrPEvTT3V81Nc0=; b=MzipM6Zb3vBY/Z/CPHZiO/WkZTMvFNo9wpV40b0FHy9KVfjhGUowitzi5lKjKmRvnf XBreYtu69jTgpyDKAxjjNLINE7SqnvMe9yFCCY0LB1hvjyGKaTaZV0qlTMQa9lYKccpL htO1vAlS8yAMJiDMFb763qem99zqW8ggERFeh113gAsGYOgVI0A2jOLa79ovRW6Coo40 leDSF4peR4EwJTsQm+kSOOiit3zQ1GzCIQ9LzLGf19jsx3vVvgIkfxC4JpRCjV7CO8W0 ZpYFnEXDBRhqtvO67BU6iz4UZygil0LyGBITQF+O/lwjm3tgFmywRwbxXSN3fJmMbg12 ZK5Q== X-Gm-Message-State: AAQBX9dq9IwK98skD4LBzNjHEhxdyt1UYQ/sog2wBHCXM9AWjaIM1vNK M70tYOYuKBDl4TAppwq6psq5hlbqIub953SIQ0IoRg== X-Google-Smtp-Source: AKy350akg3c07tz5BVyDAYiXXu9wiQsao9p9I7LIsWEKx3nwTDW2IvhVVH6kn4Hpa3I0rfxNVzf+BQ== X-Received: by 2002:a05:622a:1811:b0:3d0:7bdf:42c4 with SMTP id t17-20020a05622a181100b003d07bdf42c4mr8922345qtc.59.1681482524343; Fri, 14 Apr 2023 07:28:44 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215]) by smtp.gmail.com with ESMTPSA id a24-20020ac84358000000b003e64303bd2dsm1246579qtn.63.2023.04.14.07.28.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Apr 2023 07:28:43 -0700 (PDT) Date: Fri, 14 Apr 2023 10:28:42 -0400 From: Shawn Webb To: Charlie Li Cc: Cy Schubert , Mateusz Guzik , Pawe? Jakub Dawidek , Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD , pjd@freebsd.org Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <20230414142842.sgeikpg4r5xunqye@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <20230413140504.nnm23cjjv65mwzjr@mutt-hbsd> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rmiz7lrozzjjacb7" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Pyf2P2CPRz4MNx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --rmiz7lrozzjjacb7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2023 at 06:48:14PM -0400, Charlie Li wrote: > Shawn Webb wrote: > > Does the ZFS project have some sort of automated testing to catch > > data-gobbling, pool killing bugs? It seems like this would have been > > caught with some CI/CD stress testing automation scripts. > >=20 > I can't speak about how the OpenZFS project does things, but this particu= lar > corruption does not have any deterministic characteristics both pre- and > post-condition, so would be hard to automate testing. My approach would be to have a policy by which any new feature scheduled to land in the main branch must also not show any regressions when running `poudriere bulk -ac`. Such a policy could be enforced via server-side git commit hook. One problem, though, is that implementing that policy isn't just a matter of code, but also infrastructure, so there's a tangible monetary cost. I should mention that I appreciate the selfless hard work of those involved in the FreeBSD and OpenZFS projects. I hope for continued incremental improvements. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --rmiz7lrozzjjacb7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmQ5YxMACgkQ/y5nonf4 4fqB3Q//bNZCvDRWBsHONFrv+YamUmRi09dIEtZX9Cx+OprGvN+S4Rbq2lDhrpyW Wg5BWdj4mvJKEHU5RNjjWfJqWRulBwE0RDSPTo8ub2w3kr0+hKPF1lzZ7AC29uPU K0WYCz1p8mfwu+LhfgCEMOJsCErWeCRUejQijVLScGbkxnKufHu18Ske4KgJBgOd iab3gMZ+gE9jX4XMB623QaZkmmDnsBvaCCAmchx4vX7xVU8mNRvYfARTCQUx/pvS 2wFm67bDS+JULf7kfLwnv01DCJqNgdB3j4fSUSib0thYoJHSNC4Q91dl+dQSNsv8 c0aetNqGkeDGiRjRuSLige/tSGx+HRVA8womssUVBduLGIF8dMKqjQIrNXRmhnBH DcldNuHBVfzq9GWlfjZcBLRzWxXVqDxllvNIUznF2K9DmNLBKn0LB/mN1jD9TIcp R4GG6g6zbV7Uv/alb9+KOZwYOL7ZLYMfHcxI0SKfzQ+HWTfIdqCsVaydkR2NAdPs hxQkQjMup6t1xU8Q1sfmNujnXvy1QpaadVJYP27r7r5umJ1Szyjai3VeI6AD4l/G uZ/k3MOdSnzQFygWe1UVjzBEMTXxBZoUYbsHS8sQhUCJhEhubBh1c18USEgmKeVV MI4RdOkMmebhiN/uPQOW0fHSKq0M2p/WalTSFDZDxL+D/L3mDMk= =MCrJ -----END PGP SIGNATURE----- --rmiz7lrozzjjacb7-- From nobody Sat Apr 15 08:56:34 2023 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 4Pz6cn4bH8z44w0s for ; Sat, 15 Apr 2023 08:56:41 +0000 (UTC) (envelope-from grahamperrin@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 4Pz6cn2Gh2z3rF7; Sat, 15 Apr 2023 08:56:41 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681549001; 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=9De/a0H8B2X5yf4NM5JsNuN2YxRhOuP8WSelaC8EZkA=; b=CjdgRHkI9ieO2j8mwSQ+3c4x+Lla0Mshjx7Nuuw8b3kLOD4CxeL9tPerBVfDLelgKdbmPQ 61GWU+7o66lCWaK4S6AoeCoE9mCr2FI2ac/sYaWVfGTFy6MxrJfIUVeclJ0ulAJSzm5GtL zO/vAa8FiXlFAtp39rjN2wcxxR+AyjQ81X8+necfRSDsO89WqjSyOJ/Lc/r0Z/SN1Rq6Kn Cb5N5m/ggGhYyFSRWgJsGpSnX0PDdV1ngPpSIyvrDNgQ9HhtC3tyDCYpTgDsHMIwdSooHP t7dLdwtJvNGCu0lckOo9UXE3DPmdxTX5Zbq5D2WIEH6DWFpcsP35iH5X17ZJmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681549001; 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=9De/a0H8B2X5yf4NM5JsNuN2YxRhOuP8WSelaC8EZkA=; b=y16sibL5BRuHsAS+0oNBY5xnqPkB4dpt0t/dsJZwPAtbvKk8WqyuOoJw38IvhXsC9zflp6 H5AhF8HNrrWrnsWWuksbULOLdXl5Te4ZUg2H1hh0jLl/GbVXdIUhYaQqra1LdFwLiKqgJJ 0xwgcFq5Rhfppv5MW0Sk1K4qIaXCvY4Xnn983zDPXSQ0OA2u4ow3bqYhr+UVpVTctAUirX L9zINqfIfqcIcslNmoB90ThSX+A53qUrS9ei0qSkRicJMiASqxc0yhzfe3ZdMr0+ZOFFSf smeVRY60vXMee3KAB3dYX8z+w5aVcanINv6BRPuJCbrk70ZAifY7pIssSc55mA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681549001; a=rsa-sha256; cv=none; b=cw6TcwQC/X9LDG/I1V9Yh1Cb19q2t5iOUz1AEBDFjLELxgjUkweio4F6ljqEf74hLsLYi+ Lg/Xd74YZfJdr1irPUD/KEGkOkoN5wkXrIJpi11UwT0PWTsz6csGF60/k2GUiaZgMT68Pj xVKd13qK2ZsMsZAt5VbmCvgSyE3AOlQPa3jSTEM7w55FicZBcUozJs8qpkrgFnGlc3BsDv mBsjXlB+5/nlB37Ngx5VeTp8W9/pqFVyrGV0xRlcwkWo38P779V4oP8LixZvn0Nk5p42Mc vkGdrdKm/EkcMNW5iQyKTASZ5p+xPC2LcD4BxYzhiDnsPAFzpv/to7njBdBrvw== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (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: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pz6cm4JMLzXrS; Sat, 15 Apr 2023 08:56:40 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> Date: Sat, 15 Apr 2023 09:56:34 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: OpenZFS recently (was aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!]) Content-Language: en-US To: Warner Losh Cc: Dimitry Andric , Mark Millard , "fluffy@freebsd.org" , FreeBSD CURRENT References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> From: Graham Perrin Organization: FreeBSD In-Reply-To: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------CcNMsJ1eO5CzjuU0GYPLTmZJ" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------CcNMsJ1eO5CzjuU0GYPLTmZJ Content-Type: multipart/mixed; boundary="------------rzWuTT3ZFE78FhKylVx7jfGD"; protected-headers="v1" From: Graham Perrin To: Warner Losh Cc: Dimitry Andric , Mark Millard , "fluffy@freebsd.org" , FreeBSD CURRENT Message-ID: <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> Subject: OpenZFS recently (was aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!]) References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> In-Reply-To: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> --------------rzWuTT3ZFE78FhKylVx7jfGD Content-Type: multipart/alternative; boundary="------------mCPJ04lcMv0oAXxnc6FfYUSl" --------------mCPJ04lcMv0oAXxnc6FfYUSl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQvMDQvMjAyMyAxMTo1OCwgTWFyayBNaWxsYXJkIHdyb3RlOg0KPiDigKYgemZzIGFm dGVyIHRoZSBpbXBvcnQgY29ycnVwdHMgZGF0YSBldmVuIHdpdGhvdXQgYmxvY2tfY2xvbmlu ZyBoYXZpbmcgZXZlciBiZWVuIGluIHVzZSwgZXZlbiBhcyB0aGUgY29kZSBjdXJyZW50bHkg aXMuIE1vcmUgcHJvYmxlbXMgYXJlIHRvIGJlIGZvdW5kIGFuZCBmaXhlZCB5ZXQsIGRlc3Bp dGUgdGhlIHNldmVyYWwgZml4ZXMgbm93IGluIHBsYWNlLg0KPg0KPiBTZWUgZm9yIGV4YW1w bGUg4oCmDQoNCg0KSXMgdGhlIHJlY2VudCBzaXR1YXRpb24gdW51c3VhbCBlbm91Z2ggdG8g d2FycmFudCBhbiBlbnRyeSBpbiBVUERBVElORz8NCg0K --------------mCPJ04lcMv0oAXxnc6FfYUSl Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 14/04/2023 11:58, Mark Millard wrote:
=E2=80=A6 zfs after the impo=
rt corrupts data even without block_cloning having ever been in use, even=
 as the code currently is. More problems are to be found and fixed yet, d=
espite the several fixes now in place.

See for example =E2=80=A6


Is the recent situation unusual enough to warrant an entry in UPDATING?

--------------mCPJ04lcMv0oAXxnc6FfYUSl-- --------------rzWuTT3ZFE78FhKylVx7jfGD-- --------------CcNMsJ1eO5CzjuU0GYPLTmZJ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmQ6ZsIFAwAAAAAACgkQt2dIb0oY1AsB JQ//WbMnsvjIZQT+uzRSOB2+XlxI5ucYS53iMlLeJYeFwKDAeC03BmDoN6P5svV+LxNCjmno8ePh M3a2mN85UXHYOzEFGsCCFtxNdRL+9SFNGoVbW/IZ04dbqrfRR51hsdy6YTM48S3Qjp3S2dGN+5Fj v9bNyi8KYHPKoODv9xyaDxvXBprC9K3j3K3/mm5Jk5fzSMu8K7+nB93y5fxrEfYd9JSEnkEYIVL1 xi6oz6WXQGkDNlE8Yal5EhJAeg80Yp/nAFHWEKU79z5gkdW4c6h3e56RkfbbWiqMGSqAj1V5hCK0 5XJlAPEkokVj+xNOuNB8+WO4ea/Wc5wThIRY9gNZ5KCpxpB7P/RdcNGDE1zJH5+vPd+wUX5/JJnD hXRz8Ng8Y72jsgS1rAEzw4nhWuEyKFrfhzJ6SNG8PsUxoXu50RYfuFoy67Vai/nfMj0z8bGzkPPS MwPQ2QOc6FZskukQQLUBACHa3wAd9umk4hyqodHmaW3CZzQ3sXZbux35O1hY1oJrr6e4eEAs0Vuw 8GD+v9rm6TkzHcb+jyynviC2EWUrZ2K4ufYaFk5VL3nkZ+rUqYOGqRC8w5UdA8VjmH2mamFlY6du iFpONXWDm8lrRq1zghdEoF7bnDFP/78/mGk7t2TqfaeRBfVXMPgaZszVxoT6dBSoJiTpRaAmHSMo AU8= =DYOS -----END PGP SIGNATURE----- --------------CcNMsJ1eO5CzjuU0GYPLTmZJ-- From nobody Sat Apr 15 09:54:25 2023 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 4Pz7wB5yFLz451nr; Sat, 15 Apr 2023 09:55:06 +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 4Pz7w91Pfqz3Jrq; Sat, 15 Apr 2023 09:55:04 +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="raU/61px"; 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; dmarc=none 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 0086710A1E9D; Sat, 15 Apr 2023 11:54:56 +0200 (CEST) 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 3AB1310A1EBD; Sat, 15 Apr 2023 11:54:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1681552494; 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=/SKma2CDm4Tq3PyBxolimAVWhIgMjFYov+oBA8rjk/Y=; b=raU/61pxch6QZvzICiBxAfXgLWv6NAuKXMHUfOzpZj/IKBeFloHqZvmUoiqhlJbR2mFvi2 3WwrYLAYqXgAhvczBEvDpAnUZJBQBvy9DdogvdZJpx61sur7JJUt5x4pi9GXVGr4a3XKn9 reMfVeKXyg223Yb+c+Rh6Y0w+CcdqwkktunGkwFybRnWsoSw8zYKeNXThRuGaGe4RNznV2 v7NiTgcFnPGUU1yRdUkObThMoC5dOczCKXC+3rZXSBioCuPiR0NyndbUWYhzY0pyJFh3Ox ako56tPzMhSSiY9WOC1GLMgbOmHDW0eMZPIMQunZWMJJ0Tb/x51wj9gcUJUtEw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-013-073-163.77.13.pool.telefonica.de [77.13.73.163]) (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) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id A5FBD10A32E6; Sat, 15 Apr 2023 11:54:53 +0200 (CEST) Date: Sat, 15 Apr 2023 11:54:25 +0200 From: FreeBSD User To: Mark Millard Cc: Charlie Li , Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 439d1d X-Rspamd-UID: 853c3a X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org,freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,FreeBSD.org,cschubert.com,gmail.com]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[walstatt-de.de]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Pz7w91Pfqz3Jrq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Am Thu, 13 Apr 2023 22:18:04 -0700 Mark Millard schrieb: > On Apr 13, 2023, at 21:44, Charlie Li wrote: > > > Mark Millard wrote: > >> FYI: in my original report for a context that has never had > >> block_cloning enabled, I reported BOTH missing files and > >> file content corruption in the poudriere-devel bulk build > >> testing. This predates: > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > >> but had the changes from: > >> https://github.com/openzfs/zfs/pull/14739/files > >> The files were missing from packages installed to be used > >> during a port's build. No other types of examples of missing > >> files happened. (But only 11 ports failed.) > > I also don't have block_cloning enabled. "Missing files" prior to brt_revert may actually > > be present, but as the corruption also messes with the file(1) signature, some tools like > > ldconfig report them as missing. > > For reference, the specific messages that were not explicit > null-byte complaints were (some shown with a little context): > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not found > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg > [CA72_ZFS] Installing libxml2-2.10.3_1... > [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found > (/usr/local/lib/libxml2.so) . . . > [CA72_ZFS] Extracting libxslt-1.1.37: .......... done > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found > (/usr/local/lib/libxslt.so) ===> Returning to build of py39-lxml-4.9.2 > . . . > ===> Configuring for py39-lxml-4.9.2 > Building lxml version 4.9.2. > Building with Cython 0.29.33. > Error: Please make sure the libxml2 and libxslt development packages are installed. > > > [CA72_ZFS] Extracting libunistring-1.1: .......... done > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not found > > > [CA72_ZFS] Extracting gmp-6.2.1: .......... done > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > ===> Installing existing package /packages/All/gmp-6.2.1.pkg > [CA72_ZFS] Installing gmp-6.2.1... > the most recent version of gmp-6.2.1 is already installed > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > *** Error code 1 > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > > > checking for GNU > M4 that supports accurate traces... configure: error: no acceptable m4 could be found in > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > > === > Mark Millard > marklmi at yahoo.com > > Hello whar is the recent status of fixing/mitigate this desatrous bug? Especially for those with the new option enabled on ZFS pools. Any advice? In an act of precausion (or call it panic) I shutdown several servers to prevent irreversible damages to databases and data storages. We face on one host with /usr/ports residing on ZFS always errors on the same files created while staging (using portmaster, leaves the system with noninstalled software, i.e. www/apache24 in our case). Deleting the work folder doesn't seem to change anything, even when starting a scrubbing of the entire pool (RAIDZ1 pool) - cause unknown, why it affects always the same files to be corrupted. Same with deve/ruby-gems. Poudriere has been shutdown for the time being to avoid further issues. Are there any advies to proceed apart from conserving the boxes via shutdown? Thank you ;-) oh -- O. Hartmann From nobody Sat Apr 15 13:41:21 2023 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 4PzDxM16Wnz45LsS for ; Sat, 15 Apr 2023 13:41:27 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.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 4PzDxL0PLFz47rQ for ; Sat, 15 Apr 2023 13:41:26 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=jrkPOZq2; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=DiGZU3nG; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.24 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AC863320094A for ; Sat, 15 Apr 2023 09:41:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 15 Apr 2023 09:41:24 -0400 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:sender :subject:subject:to:to; s=fm3; t=1681566084; x=1681652484; bh=CC s87/xhOo63VZe4odhxOWNizi6xYn5PZcEuGOmxJCM=; b=jrkPOZq2iydqcdTlcn N2CMGDoNjmVTV/4MpWMpV5OLyqIfR6T/adDwv4VptN6DCuJo/Ew49G+pKlU862K7 8CVvkI6RQ/dbcTWQtKHejvXFzLNe7t9pT9Ev6XRD7Hn3l/Kqi8mmKX1gguWi8V9C XiVDZpv4QyuDXOHhu+/detKLvDGosUL/Iu8hDjeNJQO1rk7DFt9RIfoZH5ncvPUt 8FpozFIjjM5wm6CQ9eanzoUJiSj7HnXDatN6Y4zM/J8sJ3Kun/xXj7IilDuvc5h8 8GsNF5ekVi+OgRyJi5cVFb/zS98kT8UQDMmqBtETNVwCxtoYycKrohbK/LZobK8g wuAw== 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:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1681566084; x=1681652484; bh=CCs87/xhOo63V Ze4odhxOWNizi6xYn5PZcEuGOmxJCM=; b=DiGZU3nGUHidIzQcVSrmn5wFWGHnl WFGAMXmNf7sp35j7wJL/6q8ChavWIJYFwcTPsFTDwULhHHfRpg/Q+urwNa5VNmNY Gly/vYGBwYUr1keZ96Msd0G2ml4RKevCKJG6B5okkoZlLCsTedMzrmrcm9rEjAvL InmiCiY+9MoJ/njDuXPvIl2vE80Vpfw6rXkuMywisqaqNdTQOaouJIkJHzTRPJYb BXNC/+k9nC8NDK6XUM9Y9P3zYRUTGTKKtwSLXYGsSAwfPTTW3M5nHVeOeH3MoNB7 K4BHbBj/w2A0D4AK1fWLm31nNCDSXQJex8iqQF2tz2VTECf7ZzkNvG5JA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdelvddgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 15 Apr 2023 09:41:23 -0400 (EDT) Date: Sat, 15 Apr 2023 14:41:21 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: OpenZFS recently (was aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!]) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> X-Spamd-Result: default: False [-4.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-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]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]; SUBJECT_HAS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PzDxL0PLFz47rQ X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote: > >Is the recent situation unusual enough to warrant an entry in UPDATING? > yeah I'd say so. Also does this affect 13-stable and the recent 13.2-RELEASE or just -current? -- From nobody Sat Apr 15 14:36:25 2023 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 4PzG8s5Hj0z45RJx; Sat, 15 Apr 2023 14:36:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PzG8s3JFXz3CRn; Sat, 15 Apr 2023 14:36:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id nezCpDQRvjvm1nh0upINE6; Sat, 15 Apr 2023 14:36:28 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id nh0spyKNyyAOenh0tpiHoL; Sat, 15 Apr 2023 14:36:28 +0000 X-Authority-Analysis: v=2.4 cv=e5oV9Il/ c=1 sm=1 tr=0 ts=643ab66c a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=CjxXgO3LAAAA:8 a=6I5d2MoRAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=2iz5XMn2izFUwJidrLYA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id D86219FC; Sat, 15 Apr 2023 07:36:25 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 99388387; Sat, 15 Apr 2023 07:36:25 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: FreeBSD User cc: Mark Millard , Charlie Li , Pawel Jakub Dawidek , Cy Schubert , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> Comments: In-reply-to FreeBSD User message dated "Sat, 15 Apr 2023 11:54:25 +0200." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Apr 2023 07:36:25 -0700 Message-Id: <20230415143625.99388387@slippy.cwsent.com> X-CMAE-Envelope: MS4xfBC5KK+FGweuTH2Bwo9Fgf2E1NVmkxk65aZu3jql7QWlfdUg1ENrNMGw9W3tgL/GUyC/Jxt1LOXwkv3E1rGXb4Io5cACxlu9Fflm/TtpyUGqb/9AlIej gsw5JXntb7xu5FFJkBc5WmEVMnu1E0RndsKKXJ1ZRDFMZVMwht8SglG5uq+DGi3lpyBwT1f2yhvAuu70OobSKqprpKCL58kTcx4MDsWyRIj7hGg8qHH9FOsz NuqgKrU8ybYumtoifv66hL4kGBmP/xzVnchNamJf/KuRBGfLpTXp4NQNMCm+EZwXvbVZCA0AsYdnNCEtVGdCMuTbsWDEsFlRuBhD5ccXR8Eu5pyJey/8BJoP euTru4iUP/pANRevPFWG+wh7uOY0XDeedx7jfr03LJ0sWU8WYAA= X-Rspamd-Queue-Id: 4PzG8s3JFXz3CRn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>, FreeBSD Us er writes: > Am Thu, 13 Apr 2023 22:18:04 -0700 > Mark Millard schrieb: > > > On Apr 13, 2023, at 21:44, Charlie Li wrote: > > > > > Mark Millard wrote: > > >> FYI: in my original report for a context that has never had > > >> block_cloning enabled, I reported BOTH missing files and > > >> file content corruption in the poudriere-devel bulk build > > >> testing. This predates: > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > > >> but had the changes from: > > >> https://github.com/openzfs/zfs/pull/14739/files > > >> The files were missing from packages installed to be used > > >> during a port's build. No other types of examples of missing > > >> files happened. (But only 11 ports failed.) > > > I also don't have block_cloning enabled. "Missing files" prior to brt_rev > ert may actually > > > be present, but as the corruption also messes with the file(1) signature, > some tools like > > > ldconfig report them as missing. > > > > For reference, the specific messages that were not explicit > > null-byte complaints were (some shown with a little context): > > > > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not found > > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg > > [CA72_ZFS] Installing libxml2-2.10.3_1... > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found > > (/usr/local/lib/libxml2.so) . . . > > [CA72_ZFS] Extracting libxslt-1.1.37: .......... done > > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found > > (/usr/local/lib/libxslt.so) ===> Returning to build of py39-lxml-4.9.2 > > . . . > > ===> Configuring for py39-lxml-4.9.2 > > Building lxml version 4.9.2. > > Building with Cython 0.29.33. > > Error: Please make sure the libxml2 and libxslt development packages are in > stalled. > > > > > > [CA72_ZFS] Extracting libunistring-1.1: .......... done > > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not found > > > > > > > [CA72_ZFS] Extracting gmp-6.2.1: .......... done > > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found > > > > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > ===> Installing existing package /packages/All/gmp-6.2.1.pkg > > [CA72_ZFS] Installing gmp-6.2.1... > > the most recent version of gmp-6.2.1 is already installed > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > *** Error code 1 > > > > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > > > > > > checking for GNU > > M4 that supports accurate traces... configure: error: no acceptable m4 coul > d be found in > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > > > > > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > > > > > Hello > > whar is the recent status of fixing/mitigate this desatrous bug? Especially f > or those with the > new option enabled on ZFS pools. Any advice? > > In an act of precausion (or call it panic) I shutdown several servers to prev > ent irreversible > damages to databases and data storages. We face on one host with /usr/ports r > esiding on ZFS > always errors on the same files created while staging (using portmaster, leav > es the system > with noninstalled software, i.e. www/apache24 in our case). Deleting the work > folder doesn't > seem to change anything, even when starting a scrubbing of the entire pool (R > AIDZ1 pool) - > cause unknown, why it affects always the same files to be corrupted. Same wit > h deve/ruby-gems. > > Poudriere has been shutdown for the time being to avoid further issues. > > Are there any advies to proceed apart from conserving the boxes via shutdown? > > Thank you ;-) > oh > > > > -- > O. Hartmann With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded blocks. #14739" patch I didn't have any issues, except for email messages with corruption in my sent directory, nowhere else. I'm still investigating the email messages issue. IMO one is generally safe to run poudriere on the latest ZFS with the additional patch. My tests of the additional patch concluded that it resolved my last problems, except for the sent email problem I'm still investigating. I'm sure there's a simple explanation for it, i.e. the email thread was corrupted by the EXDEV regression which cannot be fixed by anything, even reverting to the previous ZFS -- the data in those files will remain damaged regardless. I cannot speak to the others who have had poudriere and other issues. I never had any problems with poudriere on top of the new ZFS. WRT reverting block_cloning pools to without, your only option is to backup your pool and recreate it without block_cloning. Then restore your data. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Apr 15 15:16:54 2023 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 4PzH3h5cHTz45VHh for ; Sat, 15 Apr 2023 15:17:04 +0000 (UTC) (envelope-from alexey@hotmail.fi) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04olkn2028.outbound.protection.outlook.com [40.92.74.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PzH3d71BQz3LvT for ; Sat, 15 Apr 2023 15:17:01 +0000 (UTC) (envelope-from alexey@hotmail.fi) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of alexey@hotmail.fi designates 40.92.74.28 as permitted sender) smtp.mailfrom=alexey@hotmail.fi; dmarc=none; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YeNm/tm0M2KAkGid6VfRdHM4srXkS4SIrWujKXd7go4nOTggUAIZs04P5BGRaSTG0zbAC7V38zFzA1qyQpPTN7gu7PKI8C8F0Zq81d5VsG4Db+dCx9WgHf/X7a+jMyf1n0+HfmHNlL0UCckqeIHnHYDUtYW3ezYJ1fwiSgOko5tyXp0UKwLHrw5nYTbnCbpXnV68MMK2r0NRPNisBwU2f0ljTBCMZLkPhSUgf24zIyfbqZkHvRil5yYSy4UqwG6+/vjmiCnhqzOu0Jx/52vGUSDO/CjRwVBUpFelbcccEMhBrH7rHvfIPG+u7SDJM4ig60wqEY0BkNb2mx3RBKBqwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OpNMJihVJ1svCMIQUs4Y4HvIY0SJ/GO3QdfehPwdUf4=; b=T5Hz0H8d1BAEO1NC7efmLTvlJNLvkb/SiIdGRMH1Lq7ZuZoesyrVa1VWKAQ57APfdbGT9RILyEXvwumHd21wy/RQYM7poreNmEnb0SO+FXIGBXWQB+zoSWOOD7gr3fDzQNSX/27aQJ6T2m5dWsxfRfWX92rvY3N+CfTETFMLOymej03k+XrJoa78BeJb0EiyiTXHh/m35Mk5keM52sbKT4Zg0CdRj+hH2ojzXHuthoHQ9ZnKeWg+9FYRpbojV9zeF7UdEkMbpSG1/DfEsxykQNx7u4hAzWqKHIVHv73lrWufJ+CIbfqAapqi+EwRhlXfJtCKAlOT7M+hAowI+qO9/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from PAVPR08MB9506.eurprd08.prod.outlook.com (2603:10a6:102:314::13) by AS8PR08MB9503.eurprd08.prod.outlook.com (2603:10a6:20b:61d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6277.47; Sat, 15 Apr 2023 15:17:00 +0000 Received: from PAVPR08MB9506.eurprd08.prod.outlook.com ([fe80::3fdc:97c7:cb93:c72b]) by PAVPR08MB9506.eurprd08.prod.outlook.com ([fe80::3fdc:97c7:cb93:c72b%7]) with mapi id 15.20.6277.048; Sat, 15 Apr 2023 15:17:00 +0000 Date: Sat, 15 Apr 2023 18:16:54 +0300 From: Alexey Vyskubov To: freebsd-current@freebsd.org Subject: Re: Status of Alder and Raptor lake on FreeBSD Current Message-ID: References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TMN: [Iokryd1T3YxQ6mz0Hf4DRK6D78G32M51WApsqZY4yzk=] X-ClientProxiedBy: OS6P279CA0165.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:39::18) To PAVPR08MB9506.eurprd08.prod.outlook.com (2603:10a6:102:314::13) X-Microsoft-Original-Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 2 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PAVPR08MB9506:EE_|AS8PR08MB9503:EE_ X-MS-Office365-Filtering-Correlation-Id: c87bb5f3-568e-45ff-4d56-08db3dc47584 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LXKa5LThW53w4gzwjZ10msLPH16GURWWeTa4IHpMi5PddHTNwazWBqqXPObYcgmSzcoPLU975DVRxeKPTkpuNtN+PE8hK+WLC4Ztb3GjMbaKcwQe/TRw2glVa9xrUw97lFh9LNZPUkmQYpUt9gFLv4Pq7ZiOXXYcxF+2ChHAQj5qcXE2D1zatxfqgw/CHkBS+deM8WonCY6bxgy6as/fXjdt7bV9EbMDqMKXnwNweT/LR0z8pblCusr5lCk2IWhR/Cyb9Sne5GWXBq8YcjbC6ez2cd2OEKg74gjvhGDrOKbChfFGwsBKOBlHb459EWxXBnoKsn2zkZfqjK01w/SqU9qHwoBkoelccpnFrXXownmJN3OzGuBcVFg/zuBkZiTI9JLtsmEYInCdvQJpeTIoVNeeR3DDnxWTpYduQXs/XoBuakkwUNJa7NFLpr/DLtitIihmnmHAPJGhBhpMqGuMcIblDUc5nbgaNdzQ6nnQL/F5yJQOo1gWnKpgnHqfEWDdwqcLINzRGlvisWedG0mZas5kPAphikva7XyF2ue3gtUCFHuvgg6oD3gK6zyjSSoYrH1O6rMl5QK9/xT37xXt1T5vguzKC/uZIvZQFQN+li4= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Uzq7BP8ZTXIlqQPeIYxSOLomp6Vp6+34GA/cg3TNGLgOs05Ax/eET4m6VAmI?= =?us-ascii?Q?xjWca9DgVabRTPm1dOEbHPz2L2eHB4yzR+teV0X9Hj2r/nHD7LGQ/2ihzXDE?= =?us-ascii?Q?FGvRMzsEP18e4cREvtKHTUB7A9ftT6rEIKfvcg6+vJPeGKuqjDULTnjRPQd1?= =?us-ascii?Q?POY/qOZnc6tIdimrHVjMKsu4dta07KJWaEBNNRHhUt+Bls8orJan55xsOKV8?= =?us-ascii?Q?uPqryEgov2NI4mA5DOrGX3Nfuk/Q+KpAaL4+qx2v25Dmq7iMZ4YRiHxpGX9h?= =?us-ascii?Q?ShSnaqW6pocLpDDJEb9CZtWOeUYFrczReyd9EKU2Q9FqjlsxsJI5W/KuDT+q?= =?us-ascii?Q?51pIdf55sk2Nfc+l9hZ/AHS+5M+eVQtke+/brKDFNmatgzczgzYB1IH+hUfM?= =?us-ascii?Q?Ll97aaRAD/oBBHF0BZSikE2v/U5t/Bz5oA7MH9X3VHdZk8lGLrdk2hYTbBp3?= =?us-ascii?Q?8QMZ/1q6Oee5uF+/6ihtnxpZBf+GvjqLy8izTzdumlAWjwQX5/q3EcgOy/WG?= =?us-ascii?Q?J9qIuIorbNxOSjg1sm+0PZOtDRiQLpMTLYYkKAWwaO5gNioOeBkPapba3ohF?= =?us-ascii?Q?fH7RGTrAhm1YyPtyEO/PuXnbxXSo6rhcKSZIejxYAvzhRX37s/5Bc8rysmAH?= =?us-ascii?Q?UIZ1fxA7x5j8jc3zH1ZL/1/MPrh51i2hbf5eJ0wbE56L911D2A/QxRyddxM1?= =?us-ascii?Q?V4v1hnVd+woKfphWGl3QVriEqUsE5nP3ATgodccKsxS+ATASp575DZ+YSvPr?= =?us-ascii?Q?5yM78U+U5DDGVcoH5jwq/4kxQFF+iWLpzyZcxYo9gWzye0VFCGDKasw0PjfO?= =?us-ascii?Q?8Hdi5M+cvIK9rrzGeEm4PbD4FufSk4P2DQIWi8K+JXVL1zCZQ6gUIAusNtGG?= =?us-ascii?Q?3T+oEPSB2fgGTgzF6CmOuCtFDjjoUtD2TFw5PZTPTfbnzhx9ZZTHtRU7zpPZ?= =?us-ascii?Q?KecD8I8kZo66jcDalid6WYWn7xW3zHTNyQL8V7G0iho2NxpWP85ywQOBZdTH?= =?us-ascii?Q?IiiS45nHEmh9LEeSIrJFrY/2xqB6YRX0OczQnVy1px5hdNqVzTAQRW+98Zmp?= =?us-ascii?Q?5+5UFa3bAaFgzo1MY9xrlvGr2WUZ30WoOLUE7Q2Fn6g8gmPcGf1/ZHcBvp35?= =?us-ascii?Q?pjsm7t/xoWPHoF6k8qiZH28cmfMMwQkR2itU7tquzFh0XTXAKf2MwD1mceFd?= =?us-ascii?Q?u/vJWJ0tbUwp63zLXsBZ4gCZufqTLC0GbQANm46C30WUMFpq5CFfX4xAgpA?= =?us-ascii?Q?=3D?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-83b42.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: c87bb5f3-568e-45ff-4d56-08db3dc47584 X-MS-Exchange-CrossTenant-AuthSource: PAVPR08MB9506.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2023 15:17:00.0079 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9503 X-Spamd-Result: default: False [0.39 / 15.00]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_SPAM_LONG(0.51)[0.506]; NEURAL_SPAM_SHORT(0.45)[0.446]; NEURAL_SPAM_MEDIUM(0.43)[0.434]; FORGED_SENDER(0.30)[alexey@pentode.fi,alexey@hotmail.fi]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.74.28:from]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; RCVD_IN_DNSWL_NONE(0.00)[40.92.74.28:from]; BLOCKLISTDE_FAIL(0.00)[40.92.74.28:server fail,2603:10a6:102:314::13:server fail]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[pentode.fi]; TO_DN_NONE(0.00)[]; FREEFALL_USER(0.00)[alexey]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[alexey@pentode.fi,alexey@hotmail.fi]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4PzH3d71BQz3LvT X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N > I was wondering what the status of Alder/Raptor lake support is on FreeBSD? > Does it boot? I am writing this message from 13.2 machine with i3-12100F (must be an Alder Lake; no integrated graphics in this one, though) in B660 motherboard. Previously the same machine was running 13.1. If it matters, I have multiple ZFS pools, including root on ZFS mirror. According to powermon(8) my package normally consumes less than 10W. I do not think that the support for an Alder Lake got worse in -CURRENT. -- Alexey I cannot receive HTML mail at this account. Hi, I am a signature virus. Add me to your signature to help me spread. From nobody Sat Apr 15 15:51:51 2023 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 4PzHrY3d2Qz45YRP; Sat, 15 Apr 2023 15:52:29 +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 4PzHrY1Szzz3Nmk; Sat, 15 Apr 2023 15:52:29 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (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 2B68510A1E8E; Sat, 15 Apr 2023 17:52:21 +0200 (CEST) Received: from hub1.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 hub1.goneo.de (Postfix) with ESMTPS id 4B57110A32F4; Sat, 15 Apr 2023 17:52:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1681573939; 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=uQ5Y1tWOxt2kTlzDq2zDNlVZOkYI/NI/BsFrnymjmwY=; b=Xel4bsbEYNEJMJMioBJ054+n2DZw5bYIt9pEcAFTK8lP4vhDAoqRPfwhCnf6LH84+3yxyp Eb0UVrgX8QM/PrSosoIz0wIcQOKaPhe7oUd8IcmO9Ppovrysyhw2Fg33nOlShsHLcSWmD8 2bPS73BKIusgZH/s7c2/wLGNalTwCN7rSe6QvdnT6mahjOwP9lml4/iaCdPptPfgGWOGGH kJujjvXwbMAo38mtD5AlO62VplFaVn8JFRBrCL9O4QxC0c2dacWHEP5Ve7WE2tyRy4KNSv PzRt3VY3ggfwUuAOcgZBg44a/u6RUKjw48bou3TmqcwZxW7+w9EkwluakYhKCQ== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-013-073-163.77.13.pool.telefonica.de [77.13.73.163]) (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) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id DB4B110A32E3; Sat, 15 Apr 2023 17:52:18 +0200 (CEST) Date: Sat, 15 Apr 2023 17:51:51 +0200 From: FreeBSD User To: Cy Schubert Cc: Mark Millard , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20230415143625.99388387@slippy.cwsent.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: ccd090 X-Rspamd-UID: dbcd85 X-Rspamd-Queue-Id: 4PzHrY1Szzz3Nmk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Am Sat, 15 Apr 2023 07:36:25 -0700 Cy Schubert schrieb: > In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>, > FreeBSD Us > er writes: > > Am Thu, 13 Apr 2023 22:18:04 -0700 > > Mark Millard schrieb: > > > > > On Apr 13, 2023, at 21:44, Charlie Li wrote: > > > > > > > Mark Millard wrote: > > > >> FYI: in my original report for a context that has never had > > > >> block_cloning enabled, I reported BOTH missing files and > > > >> file content corruption in the poudriere-devel bulk build > > > >> testing. This predates: > > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > > > >> but had the changes from: > > > >> https://github.com/openzfs/zfs/pull/14739/files > > > >> The files were missing from packages installed to be used > > > >> during a port's build. No other types of examples of missing > > > >> files happened. (But only 11 ports failed.) > > > > I also don't have block_cloning enabled. "Missing files" prior to brt_rev > > ert may actually > > > > be present, but as the corruption also messes with the file(1) signature, > > some tools like > > > > ldconfig report them as missing. > > > > > > For reference, the specific messages that were not explicit > > > null-byte complaints were (some shown with a little context): > > > > > > > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not found > > > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg > > > [CA72_ZFS] Installing libxml2-2.10.3_1... > > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found > > > (/usr/local/lib/libxml2.so) . . . > > > [CA72_ZFS] Extracting libxslt-1.1.37: .......... done > > > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found > > > (/usr/local/lib/libxslt.so) ===> Returning to build of py39-lxml-4.9.2 > > > . . . > > > ===> Configuring for py39-lxml-4.9.2 > > > Building lxml version 4.9.2. > > > Building with Cython 0.29.33. > > > Error: Please make sure the libxml2 and libxslt development packages are in > > stalled. > > > > > > > > > [CA72_ZFS] Extracting libunistring-1.1: .......... done > > > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not found > > > > > > > > > > > [CA72_ZFS] Extracting gmp-6.2.1: .......... done > > > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found > > > > > > > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > > ===> Installing existing package /packages/All/gmp-6.2.1.pkg > > > [CA72_ZFS] Installing gmp-6.2.1... > > > the most recent version of gmp-6.2.1 is already installed > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > > *** Error code 1 > > > > > > > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > > > > > > > > > checking for GNU > > > M4 that supports accurate traces... configure: error: no acceptable m4 coul > > d be found in > > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. > > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > > > > > > > > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > > > > > > > > === > > > Mark Millard > > > marklmi at yahoo.com > > > > > > > > > > Hello > > > > whar is the recent status of fixing/mitigate this desatrous bug? Especially f > > or those with the > > new option enabled on ZFS pools. Any advice? > > > > In an act of precausion (or call it panic) I shutdown several servers to prev > > ent irreversible > > damages to databases and data storages. We face on one host with /usr/ports r > > esiding on ZFS > > always errors on the same files created while staging (using portmaster, leav > > es the system > > with noninstalled software, i.e. www/apache24 in our case). Deleting the work > > folder doesn't > > seem to change anything, even when starting a scrubbing of the entire pool (R > > AIDZ1 pool) - > > cause unknown, why it affects always the same files to be corrupted. Same wit > > h deve/ruby-gems. > > > > Poudriere has been shutdown for the time being to avoid further issues. > > > > Are there any advies to proceed apart from conserving the boxes via shutdown? > > > > Thank you ;-) > > oh > > > > > > > > -- > > O. Hartmann > > With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded > blocks. #14739" patch I didn't have any issues, except for email messages > with corruption in my sent directory, nowhere else. I'm still investigating > the email messages issue. IMO one is generally safe to run poudriere on the > latest ZFS with the additional patch. > > My tests of the additional patch concluded that it resolved my last > problems, except for the sent email problem I'm still investigating. I'm > sure there's a simple explanation for it, i.e. the email thread was > corrupted by the EXDEV regression which cannot be fixed by anything, even > reverting to the previous ZFS -- the data in those files will remain > damaged regardless. > > I cannot speak to the others who have had poudriere and other issues. I > never had any problems with poudriere on top of the new ZFS. > > WRT reverting block_cloning pools to without, your only option is to backup > your pool and recreate it without block_cloning. Then restore your data. > > All right, I interpret the answer that way, that I need a most recent source tree (and accordingly built and installed OS) AND a patch that isn't officially commited? On a box I'm with: FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST 2023 amd64 The box is crashing while trying to update ports with the well known issue: Panic String: VERIFY(!zil_replaying(zilog, tx)) failed At the moment all alarm bells are ringing and I lost track about what has been patched and already commited and what is still as patch available but in the phase of evaluation or inofficially emmited here. According to the EXDEV issue: in cases of poudriere or ports trees on ZFS, what do I have to do to ensure that those datasets are clean? The OS should detect file corruption but in my case the box is crashing :-( I did several times scrubbing, but this seems to be the action of a helpless and desperate man ... ;-/ Greetings Oliver -- O. Hartmann From nobody Sat Apr 15 16:07:34 2023 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 4PzJB94pd4z45ZVq; Sat, 15 Apr 2023 16:07:45 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [88.99.165.53]) (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 4PzJB91qCjz40LX; Sat, 15 Apr 2023 16:07:45 +0000 (UTC) (envelope-from flo@smeets.xyz) Authentication-Results: mx1.freebsd.org; none Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id 3DB5A1DD7FA; Sat, 15 Apr 2023 18:07:37 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 355B5675D; Sat, 15 Apr 2023 18:07:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id Zor0VW2wTrRJ; Sat, 15 Apr 2023 18:07:37 +0200 (CEST) Received: from [IPV6:2a01:4f8:10a:fd43::666] (unknown [IPv6:2a01:4f8:10a:fd43::666]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id 00FDD6858; Sat, 15 Apr 2023 18:07:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1681574856; 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:autocrypt:autocrypt; bh=cf7gcAbp7coGQ1urueINcwVqbdBfJ9gamF+1kbK3Cw8=; b=bRQse3vHIcAIjz2n4UW6xbwFirzNK/bTih/3UhFSphG+A3a5ZGaWZMgcuQo4DtMMQNZ8md 1t9ZFAV9oiYX1zB3C4znUPuilcnzgbnMHsCDroszYTD/krk2uP3qNieHLg7sSdnmq4mHZj 1NY5ET7RFOYY6bbhwzMXvYs+WYASq+IX8Qgq/na03Wg2OCt29FK+Y50Qb1/a6szGR2lm3j OQ4sukpvNvGSxV4BnUmQK/u3J4CHBqSe5f/UVfxSPFDmOoAQKpXV5n+PH2WhGBAc4JzDc7 HekXXht/PfIgItPaoj7Jj5q9/RxIJRqF/JxTb0gxuCQCWRWjC46W1M4y+R7grA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1681574856; 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:autocrypt:autocrypt; bh=cf7gcAbp7coGQ1urueINcwVqbdBfJ9gamF+1kbK3Cw8=; b=+wRBy/3MaoD9JFHCe5ABlrz+0QfmovEDXd19l4kr+5w+AwOa60CyMV+tQOp7WE5+InR6Og TUcZ03XRUzo3HGAA== Message-ID: <6792aded-6e2e-a118-259d-0df0f80c361c@smeets.xyz> Date: Sat, 15 Apr 2023 18:07:34 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Content-Language: en-US To: FreeBSD User , Cy Schubert Cc: Mark Millard , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> From: Florian Smeets Autocrypt: addr=flo@smeets.xyz; keydata= xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNET22HsHdQ doagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnBtiy3awKJ5uGCNO2E zJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupmEpSvFxRzAZTQuKyX4+xl+dYI d24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRtiTwaQMwAOww8r/26YM6/SgcgFuLH2E/CV plY0sDvfoISlAj8agxdomNXfPjCMQ6w5yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScP osCb/dsOg0S74zCClsIU3gdUGh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujg r1cqbUD6lUWikUv2IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgj cDk20fOgPPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAWzFn73CaV 5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQABzR9GbG9yaWFuIFNt ZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMBCgBBAhsDBQsJCAcDBRUKCQgLBRYDAgEAAh4B AheAAhkBFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmHwU9QFCQtIlt8ACgkQ71uk3NWp88D6 dA//YNhcYVDRSpLDNMLE9rqJ0DHJFaIRafpExGxQhHHiQKoeXwj87VCKRP++sbewS43g0hw6 3Nh/v/L2WbAwF4QvF3MOAhoiiGaNZoHpPK2XwaWcqa8nh2QK28G51PzLooAx78tagIBYyP3Z oRlhu22Ye3tNnN0f1ckEJMRoJAPO7hDGzFE03kcaFvOu9AOOJNuaZxdVspni6s8B4n9xrHVX NOIlwMoq2UT8irtMJb+ZWsBb/Oj/ZU0+oni8VWJMEMWwVgEOlwweAw8PK+C24F2vAj+tY3DU Q9ZQB6nX4PZesRnah95IKrDFJjOGhmdSls0uGRQkmY/U3ESuD+3AkRGXnXZ7kz6BrTVqoneg mGzG6If3BulvLqv/bdwE32JOe8UIY6cLNhgoRfMlx58Po9DZCnG4uwPr5zVpuRO4SvOC3Rz1 Q9tUV1rbrWa/QWsDlDbwzIX92eXeVs1nrQokO9VE5Fg3279ktyVJGdcSd53h5xXCvO0SKVIk fvNtTOxodhhFzhgfBgDa4eYpJfSlgSMEDOab/vRgjAjqWFbqjY+fa2OAvGXuPhCO8aofKtgn QxCK9yASayptn+3KKNy005/Q5Kuh1C89csjRxhZSw6dB+gLdyZggtD8mv12+aaFIep3FITOK KmA4H/CUcKGDozXVvhL0r90o+BfzjopmIHn6V7LOwU0EWnIHCwEQANHrOm5vydK/ij1zkDyL Zzbogk5zjMh6oAr3cH4oGbJHPLlyFZTCVBYUwD4kh6NV1sKuZOeX/aygyVg1RyLulnzsc6Yj XOIxlqhqQwGI8k8ssAIpMSf029781CNF2HC42CrJeHtXNONDNOjsMuoxzga9zLQCh4jLTlE/ TUJo6KVABWBVRtTVh2Z77pKtN7j2NPFBHvp7K0WHfV+TYnlsgjhUA0ACZnUdHS2YRzBhCzzQ eludxBz54S9xbUq1mfZfVx8AbAGXF2zxo68nvvAAJn48HiBS3dMhCGYJDdZdja6QdUFPiemi nOxwkUzCqmKxm+Aj7USue1SbZZqJxmMI1eF4Ork/BJJI74Z/FnJgYR4UkEiD3J/KUocQCIH3 daB1+/CXlh99Ib7AP+QGuKk3vnNHh7VBq3E+VAiM5LU0BmgW+cdRPHkiwM7sDa2VnV3VqvV7 QmoMKnHFzUB6Nn8uE+iakp5J81Pr68kDOq7kLW3UnGmg1PUqbsnCaTimJb3JAYWzOW/9CYcP lbAdIqi+wH7MOoeL+PA99A3kW/881rGmeOYFzzrsNVLtea+AJfXtp4LN5gOVIPIpovCNSVXX EKgl7a4vjUGzVBzrH7PzT+k4XUEQwNCACfGZxEExtny19bjvumZ0rv+AEAHvsWSKXHUVJzIN jqd9UioaEbKGAPlPABEBAAHCwXwEGAEKACYCGwwWIQTss2i4eQi/tpFNcmnvW6Tc1anzwAUC YfBT/gUJC0iW4AAKCRDvW6Tc1anzwHKpD/9znRaNN0u5+TwJxSD3baeA2OqeebO6gjpscfoT 1z1LOTJiG/pPMz7TB5K2bo+0JwzRV29nfiSeNGQqBx1THZ3Y0ph5tFB8rfF4aEddjhtwxP80 Q4SzxToSZAGMBkndNXlEpMeyHoVpcGoR7qkKAtrr7M9g9ocf8kTO3hzvDzASVIwiASVwl4QB GAv4slShbxJ86DbhtUgvv+6kSe1qm62hMTri8cD/0mVBAEwmAf6k4l9pwYW2oAdl0vjS5sz0 0uqB8nuT22NuiB3XBjSB5CFbeKhy3EZkcpG1taMmuXtwhAgQTmmknruMv9OvP8joSK1nrSyR BwzcMbYW4PS5px4c/RSsdVIcyhQLQ084c1ak9cDImiyU9pZhHnvNIdp84qfEWXOrXtWSUfUy Ej0npK9vAjKH4Vrfakw+WtRrleFC/muTSu1FfskeBphts9gk0fox1VZ+pWMLsxwsKlpgCqhC FzpN5ey+hsawjbOA8X2KJjl2Lr7fYuvmxu/FOgRxPhiO08UMkFAIlHWn+sXivGTbxZxagGos zOr6MZmKT31IcU1WqY3EIjA/ZodDkBz/cT8se4hvh5whroRuGUGfcp5KmVUJhkCvSxnVwMYz 4uDpr8I+TYWU+LnJbIBZcHs8wvNuaSMLd9CLS/4Mi2bJDRvAdmReOwiIxzzxdirXq7KkaA== In-Reply-To: <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZtsMrSGEuxkWLArxNyW80EFQ" X-Rspamd-Queue-Id: 4PzJB91qCjz40LX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZtsMrSGEuxkWLArxNyW80EFQ Content-Type: multipart/mixed; boundary="------------k9EyQdLWX0g08eualvhqQ70P"; protected-headers="v1" From: Florian Smeets To: FreeBSD User , Cy Schubert Cc: Mark Millard , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Message-ID: <6792aded-6e2e-a118-259d-0df0f80c361c@smeets.xyz> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> --------------k9EyQdLWX0g08eualvhqQ70P Content-Type: multipart/mixed; boundary="------------stAJM5daP76iyIEBXMKjSENZ" --------------stAJM5daP76iyIEBXMKjSENZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTUuMDQuMjMgMTc6NTEsIEZyZWVCU0QgVXNlciB3cm90ZToNCj4gQW0gU2F0LCAxNSBB cHIgMjAyMyAwNzozNjoyNSAtMDcwMA0KPiBDeSBTY2h1YmVydCA8Q3kuU2NodWJlcnRAY3Nj aHViZXJ0LmNvbT4gc2NocmllYjoNCj4+DQo+PiBXaXRoIGFuIHVwLXRvLWRhdGUgdHJlZSAr IHBqZEAncyAiRml4IGRhdGEgY29ycnVwdGlvbiB3aGVuIGNsb25pbmcgZW1iZWRkZWQNCj4+ IGJsb2Nrcy4gIzE0NzM5IiBwYXRjaCBJIGRpZG4ndCBoYXZlIGFueSBpc3N1ZXMsIGV4Y2Vw dCBmb3IgZW1haWwgbWVzc2FnZXMNCj4+IHdpdGggY29ycnVwdGlvbiBpbiBteSBzZW50IGRp cmVjdG9yeSwgbm93aGVyZSBlbHNlLiBJJ20gc3RpbGwgaW52ZXN0aWdhdGluZw0KPj4gdGhl IGVtYWlsIG1lc3NhZ2VzIGlzc3VlLiBJTU8gb25lIGlzIGdlbmVyYWxseSBzYWZlIHRvIHJ1 biBwb3VkcmllcmUgb24gdGhlDQo+PiBsYXRlc3QgWkZTIHdpdGggdGhlIGFkZGl0aW9uYWwg cGF0Y2guDQoNClRoaXMgaXMgYWxzbyBteSBjdXJyZW50IG9ic2VydmF0aW9uLiBJIGhhdmUg MiBob3N0cyB3aGVyZSBJIHdhcyANCnVuZm9ydHVuYXRlIGVub3VnaCB0byB1cGRhdGUgYXQg dGhlIHdyb25nIHRpbWUuIEkgY3VycmVudGx5ICp0aGluayogdGhhdCANCkknbSAqbm90KiBz ZWVpbmcgZGF0YSBjb3JydXB0aW9uIHdpdGggaGVhZCBmcm9tIEFwcmlsIDEydGggYW5kIHRo aXMgDQpwYXRjaCANCmh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuemZzL3pmcy9jb21taXQvZDNh NmU1Y2EzYjJmNjg0MTMyMjM4Y2E5NjhiZjBiOTZmMTdlYzdlMS5kaWZmIA0KYXBwbGllZC4N Cg0KT25lIHBvb2wgaGFzIGJlZW4gdXBncmFkZWQgd2l0aCBmZWF0dXJlQGJsb2NrX2Nsb25p bmcgYW5kIHRoZSBvdGhlciBoYXNuJ3QuDQo+IA0KPiBGcmVlQlNEIDE0LjAtQ1VSUkVOVCAj OCBtYWluLW4yNjIxNzUtNWVlMWM5MGU1MGNlOiBTYXQgQXByIDE1IDA3OjU3OjE2IENFU1Qg MjAyMyBhbWQ2NA0KPiANCj4gVGhlIGJveCBpcyBjcmFzaGluZyB3aGlsZSB0cnlpbmcgdG8g dXBkYXRlIHBvcnRzIHdpdGggdGhlIHdlbGwga25vd24gaXNzdWU6DQo+IA0KPiBQYW5pYyBT dHJpbmc6IFZFUklGWSghemlsX3JlcGxheWluZyh6aWxvZywgdHgpKSBmYWlsZWQNCj4gDQpP biB0aGUgcG9vbCB0aGF0IGhhcyBibG9ja19jbG9uaW5nIGVuYWJsZWQgSSBzZWUgdGhlIGFi b3ZlIGluc3RhIHBhbmljIA0Kd2hlbiBwb3VkcmllcmUgc3RhcnRzIGJ1aWxkaW5nLiBJIGZv dW5kIGEgd29ya2Fyb3VuZCB0aG91Z2g6DQoNCi0tLSAvdXNyL2xvY2FsL3NoYXJlL3BvdWRy aWVyZS9pbmNsdWRlL2ZzLnNoLm9yaWcJMjAyMy0wNC0xNSANCjE4OjAzOjUwLjA5MDgyMzAw MCArMDIwMA0KKysrIC91c3IvbG9jYWwvc2hhcmUvcG91ZHJpZXJlL2luY2x1ZGUvZnMuc2gJ MjAyMy0wNC0xNSANCjE4OjA0OjA0LjE0NDczNjAwMCArMDIwMA0KQEAgLTI5NSw3ICsyOTUs NiBAQA0KICAJCWZpDQoNCiAgCQl6ZnMgY2xvbmUgLW8gbW91bnRwb2ludD0ke21udH0gXA0K LQkJCS1vIHN5bmM9ZGlzYWJsZWQgXA0KICAJCQktbyBhdGltZT1vZmYgXA0KICAJCQktbyBj b21wcmVzc2lvbj1vZmYgXA0KICAJCQkke2ZzfUAke3NuYXB9IFwNCg0KV2l0aCB0aGlzIHdv cmthcm91bmQgSSB3YXMgYWJsZSB0byBidWlsZCB0aG91c2FuZHMgb2YgcGFja2FnZXMgd2l0 aG91dCANCnBhbmljcyBvciBmYWlsdXJlcyBkdWUgdG8gZGF0YSBjb3JydXB0aW9uLg0KDQpG bG9yaWFuDQo= --------------stAJM5daP76iyIEBXMKjSENZ Content-Type: application/pgp-keys; name="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Disposition: attachment; filename="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNE T22HsHdQdoagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnB tiy3awKJ5uGCNO2EzJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupm EpSvFxRzAZTQuKyX4+xl+dYId24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRti TwaQMwAOww8r/26YM6/SgcgFuLH2E/CVplY0sDvfoISlAj8agxdomNXfPjCMQ6w5 yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScPosCb/dsOg0S74zCClsIU3gdU Gh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujgr1cqbUD6lUWikUv2 IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgjcDk20fOg PPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAW zFn73CaV5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQAB zR9GbG9yaWFuIFNtZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMBCgBBAhsDBQsJ CAcDBRUKCQgLBRYDAgEAAh4BAheAAhkBFiEE7LNouHkIv7aRTXJp71uk3NWp88AF AmHwU9QFCQtIlt8ACgkQ71uk3NWp88D6dA//YNhcYVDRSpLDNMLE9rqJ0DHJFaIR afpExGxQhHHiQKoeXwj87VCKRP++sbewS43g0hw63Nh/v/L2WbAwF4QvF3MOAhoi iGaNZoHpPK2XwaWcqa8nh2QK28G51PzLooAx78tagIBYyP3ZoRlhu22Ye3tNnN0f 1ckEJMRoJAPO7hDGzFE03kcaFvOu9AOOJNuaZxdVspni6s8B4n9xrHVXNOIlwMoq 2UT8irtMJb+ZWsBb/Oj/ZU0+oni8VWJMEMWwVgEOlwweAw8PK+C24F2vAj+tY3DU Q9ZQB6nX4PZesRnah95IKrDFJjOGhmdSls0uGRQkmY/U3ESuD+3AkRGXnXZ7kz6B rTVqonegmGzG6If3BulvLqv/bdwE32JOe8UIY6cLNhgoRfMlx58Po9DZCnG4uwPr 5zVpuRO4SvOC3Rz1Q9tUV1rbrWa/QWsDlDbwzIX92eXeVs1nrQokO9VE5Fg3279k tyVJGdcSd53h5xXCvO0SKVIkfvNtTOxodhhFzhgfBgDa4eYpJfSlgSMEDOab/vRg jAjqWFbqjY+fa2OAvGXuPhCO8aofKtgnQxCK9yASayptn+3KKNy005/Q5Kuh1C89 csjRxhZSw6dB+gLdyZggtD8mv12+aaFIep3FITOKKmA4H/CUcKGDozXVvhL0r90o +BfzjopmIHn6V7LCwZcEEwEKAEECGwMFCQeGH4AFCwkIBwMFFQoJCAsFFgMCAQAC HgECF4AWIQTss2i4eQi/tpFNcmnvW6Tc1anzwAUCWnIHWAIZAQAKCRDvW6Tc1anz wMHxEAC7Bd/rmRO1XAMAkQWddCZHHyr9t9XlZYxVVkwz3Mw6YszTTo+UmWez28MT B9eRSxM4qkL0YRER0JXGypD9apis7Q7zIthExjQhDrDYHlxXO9/UPBjoWhzvM6kS C8C3mYJH0GgnV4d/3QqsdhTF/wBpaMn8ITgR03jAO8Rjbe1DWi/RF6I1miQp8opE XytFsGGnBFxHLNXh5qHda8orI7I8gYqq5cbQZaGC3Let822KifwCiYWhCUrSUKrn uiRCPQctLe8tPNd7G99awtz6ctdPx6jztyUxBpjPuHkSOozSvgU9GYYnXydDnACu 3m85/mhG/3RFIfdAktrFV2+3QEIOvazUnm1MbuBk/+srLP0Gs+1W8HCIcRbyOHDi UNtXfEhQRWSPhQSwz1eQesep3wmIU1lk48TblWS4B6h7IHeP2SZ9lzMX9/jVwenm /lHJNq+1r1BYDpDTsBE+7YkIEww36Un0b86TwmVSBIY7Adn7dHuOO8MwQWHgMmEX YHvsN0vGktUlLSHlxLxYzpr+ObVKToMCLhuCSx6293IT83/LFCYeiR0phbYsYOB3 tzB0zZfrrRq8VF7iiBnQ94tGKY9vIm5I3b6FkL9/LmMS/k+9n7qym7BgxgMKV59G m8EOqYILG18zUs0VGJeN1i9R0e9Dd9pwPM2k6Q8unRV7GMknYc0gRmxvcmlhbiBT bWVldHMgPGZsb0BGcmVlQlNELm9yZz7CwZQEEwEKAD4CGwMFCwkIBwMFFQoJCAsF FgMCAQACHgECF4AWIQTss2i4eQi/tpFNcmnvW6Tc1anzwAUCYfBT1QUJC0iW3wAK CRDvW6Tc1anzwE+0EACIw1ITj7Nd1WvigN6eJJzumzGuUJuNVC9foilOJQHQ7ukd yGbnHDIaXaECdg2VkUoqn5ouv8TOqsFdFdcMe07CBAqEN2McJ3D5b6IGSzoAO5Zr fDleE8n2UrRHas9ZiOJqmeeo5WGep5IzlOJegs9R39/ZVFx2Z0qhKvclvs5MsskI GE3dC8MK9qw5SxRhdQ0Ew7SHwOWyzszUhcNO/cIs1G0mSKgzMhnBYGqdqLbwjNO0 AkrASw7Vr69UMYp5ffeaFpH7SjMMm/Ts5MLPWihy+WpJ3clEoc/T+duLLMlGKTkE MXgwIHSNUs+PIn21hb7yc59DB5JH2XhqjmCdLr5fkifKHxAuMPrp02KI1nyqeHT4 2dlUBvpMxDdD/xpCF7LueakO61NnnfMkjlzVhDuFyPMAPNO4yQegxkz2gdHUdqjB mUytapVA6/9nnn0Ux5Oixpy8Fq8/Ojtb0D3yyYKG6NsnDla6sK2QzpGjt+K3WNw8 KjgZRc19PXnYoYd4OSFW8dqwFsCQtsElnDH6Xsc71Oq8Te25gmnOugr8q8z7kAM+ WImGcd5ro3mWTVOtaYsZSHIzxqfYQlZN1FeH126pnZrzOuHvCRTYefQek2ojB1L7 KYeB9xeWurRTKvTTp/LZ/kCmaQ1hq6V94ON2chMseQeJe6yT0z0zCv5r/HnfusLB lAQTAQoAPhYhBOyzaLh5CL+2kU1yae9bpNzVqfPABQJacgdXAhsDBQkHhh+ABQsJ CAcDBRUKCQgLBRYDAgEAAh4BAheAAAoJEO9bpNzVqfPAu2MP/j3MvBdI6rtfraSz pUHfPJ7HDy/YN1HD+oqqK9VTP00JgREoMQpPmC3Y1mtggUhODdteXS2hLqq0pbsr 2V81p5Rybjz6IcAztvtPGFtSNilhjP5jDuYlaxL52JYEYdkjg43zqzGQtJtSuNxv ZWCcuJdPbHqzQOflMC7KGuAF+acBDJIqd5xV+nRQtOgHaRUM9hMRS//63wXZVwgM MwdxTW7rHuTWIofwZLYNWQpOhq9Rx768ytI1QfDJdmb1NsfHMTqmCTHRj+c+wEML p8uvoczBQFeJM4iHiHSy9qaqzZGvNYWMfk+EseWcw230Acn2LV9o41eFwQiMr1h/ sxiI3wWiCaZmWNxCtubg5y75pWJef5DaFYEAgywzpNAdEXHTNuqSfBtnzQQ5ZCfH Wl00fMKKFQwjVgttEt63/Bqei2hVJoqlLzuKZzMIOg+sC6Wv4ZcYBhDuDRCsqOv9 fr69c/Ev4a6q55TlUAghjcncAcnCEOv6BVaPDqO2qyDKoRyyx3x7Df1HAOXyc7r/ qKCPTu5yGeA9RVhHOs53QyWk3rqDd0PoiHekPxnSp8RZ29UUaMq4oxztppHlEDXR Lej6n1umFbhUu0bpRurubiaLszXrarckCdQu0R97d5jwZvvjKx4TiWL7oHiEs3TY NZAx8xmMWZiBOZrO6z5vq1moCf++zsFNBFpyBwsBEADR6zpub8nSv4o9c5A8i2c2 6IJOc4zIeqAK93B+KBmyRzy5chWUwlQWFMA+JIejVdbCrmTnl/2soMlYNUci7pZ8 7HOmI1ziMZaoakMBiPJPLLACKTEn9Nve/NQjRdhwuNgqyXh7VzTjQzTo7DLqMc4G vcy0AoeIy05RP01CaOilQAVgVUbU1Ydme+6SrTe49jTxQR76eytFh31fk2J5bII4 VANAAmZ1HR0tmEcwYQs80HpbncQc+eEvcW1KtZn2X1cfAGwBlxds8aOvJ77wACZ+ PB4gUt3TIQhmCQ3WXY2ukHVBT4npopzscJFMwqpisZvgI+1ErntUm2WaicZjCNXh eDq5PwSSSO+GfxZyYGEeFJBIg9yfylKHEAiB93Wgdfvwl5YffSG+wD/kBripN75z R4e1QatxPlQIjOS1NAZoFvnHUTx5IsDO7A2tlZ1d1ar1e0JqDCpxxc1AejZ/LhPo mpKeSfNT6+vJAzqu5C1t1JxpoNT1Km7Jwmk4piW9yQGFszlv/QmHD5WwHSKovsB+ zDqHi/jwPfQN5Fv/PNaxpnjmBc867DVS7XmvgCX17aeCzeYDlSDyKaLwjUlV1xCo Je2uL41Bs1Qc6x+z80/pOF1BEMDQgAnxmcRBMbZ8tfW477pmdK7/gBAB77Fkilx1 FScyDY6nfVIqGhGyhgD5TwARAQABwsF8BBgBCgAmAhsMFiEE7LNouHkIv7aRTXJp 71uk3NWp88AFAmHwU/4FCQtIluAACgkQ71uk3NWp88ByqQ//c50WjTdLufk8CcUg 922ngNjqnnmzuoI6bHH6E9c9SzkyYhv6TzM+0weStm6PtCcM0VdvZ34knjRkKgcd Ux2d2NKYebRQfK3xeGhHXY4bcMT/NEOEs8U6EmQBjAZJ3TV5RKTHsh6FaXBqEe6p CgLa6+zPYPaHH/JEzt4c7w8wElSMIgElcJeEARgL+LJUoW8SfOg24bVIL7/upEnt aputoTE64vHA/9JlQQBMJgH+pOJfacGFtqAHZdL40ubM9NLqgfJ7k9tjbogd1wY0 geQhW3ioctxGZHKRtbWjJrl7cIQIEE5ppJ67jL/Trz/I6EitZ60skQcM3DG2FuD0 uaceHP0UrHVSHMoUC0NPOHNWpPXAyJoslPaWYR57zSHafOKnxFlzq17VklH1MhI9 J6SvbwIyh+Fa32pMPlrUa5XhQv5rk0rtRX7JHgaYbbPYJNH6MdVWfqVjC7McLCpa YAqoQhc6TeXsvobGsI2zgPF9iiY5di6+32Lr5sbvxToEcT4YjtPFDJBQCJR1p/rF 4rxk28WcWoBqLMzq+jGZik99SHFNVqmNxCIwP2aHQ5Ac/3E/LHuIb4ecIa6EbhlB n3KeSplVCYZAr0sZ1cDGM+Lg6a/CPk2FlPi5yWyAWXB7PMLzbmkjC3fQi0v+DItm yQ0bwHZkXjsIiMc88XYq16uypGjCwXwEGAEKACYWIQTss2i4eQi/tpFNcmnvW6Tc 1anzwAUCWnIHCwIbDAUJB4YfgAAKCRDvW6Tc1anzwM/8D/9IbDzMvsz4O+Gcz1oU x4IMxbQDw99qgJexR5cjW207GkRnKVJ0zqx7Xc+U3AytniuwqHEXeV4qIqP6h14p EuCqdRJ+fSm65rB4+ZdeM2Y5YYvUBByOM78Mbs6SZy2k5X0EL5FXjNVIMOv2Imbl yeRWhWK6gCfc/l7kV1EYVx9LV3umsc7K+ceZlfE1U8hWbie8r7tl3V9ggF2g1cyc 9ru0qW3sg8D4vNTS1uwdqeccKRc3osrVw4WrW1nGxTmTTCqVYGHjF2sANF9o1JB9 3hoXz8lydmDdhJ/62/XHapeT1FB8m7gulinM33VeOCCjN+dUgLQk5tAGg+iHQWhC 4Q/o4m0OqfdcSYdhCJ7h2I4GwOoGaxzoXqEL47Guxz+zE4osAFP5JLxCTbi2x5sd uCvxx3WbO95kZJKp7D0BIKpbKcfkyWse53YBI9wSrkIil+InnqvSDzU9nMvIyKSj v4uiwvZi1HY7tPiir/P2naZaiQ1SAM0KLP3g123WcnhRKo++ZRHhay5/70SKGdxE mKf3nld8xNCs9EIWOTpRaqc9+zOcD1zVTZwnwgBrnPqzfPW9+d7FwAP1MdJbrROu C2bfzNZyoR4uHAnDOyNWwGSmShv7hhdettO8dJblneTY8vhzxo36pWmojEdgghXN w9Ji7kyInAmWq9kwV5Vou3ZNFw=3D=3D =3DCZJt -----END PGP PUBLIC KEY BLOCK----- --------------stAJM5daP76iyIEBXMKjSENZ-- --------------k9EyQdLWX0g08eualvhqQ70P-- --------------ZtsMrSGEuxkWLArxNyW80EFQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmQ6y8YFAwAAAAAACgkQ71uk3NWp88Ah rw//UWfouJekp/rbLBKnDc4u8C7O9D3M8q6/+NwGW+/GauF9PjjCitBUwSUHMSGnrc44b0V+rVvW +v4kq2PbrNuLh96SLiSfPemZc9FAQzp490fh58l7eWvrwgv/SR7jvei/VAUNtoL6LPglfOLMEkdm W1cja/j8rcbB3JOGC2arVjgQAHCCxr9EzyeVL95v4ERyymLGDZdEVrxwy8zbroOLYYlgC1ThMyUj JIHlrm+YSGTYm15dgWWUAJ+ZJZjcdqvYJ2BdLpjB9TpFNSJdOjFAqUBecqmy3txNEjE5grVe5Aut 50n482ocuwsYuUJvf+/FojThrmqAKYZZSNLlKzzfkmQ0hQtjhjuUBXQfnRB0SIVPYL8sCTjh8Z5K teWnmmu7MF0L4S04vhbpjzkWvWuKEdJ5OMwKocF9ZeZM73Oup0EEsTGpYfy7Nmtto0jLAiFZQwsT LKzUiIKzA9cFAGc/KIPuSmh2+a8TD8v3P+nAiIxp89PE0GKia/vLrulXrV20bvQX4qvnKpe22DKz lCq9eMPAaKCp/ZR1dWWqfgT9wZVI3+qWGrf5O604rP2qh6kHJhtlHvG74Cy0E78C90NOH6mt5aPi r13kRBulJVMCX7At6bgh6pROW/JOi55YPs74cTnqenFGgmxxzUnPDh8GJOvXpSsHBSwZbnEdeHpA H/c= =s9Qn -----END PGP SIGNATURE----- --------------ZtsMrSGEuxkWLArxNyW80EFQ-- From nobody Sat Apr 15 16:09:28 2023 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 4PzJDD2fc4z45ZcT; Sat, 15 Apr 2023 16:09:32 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PzJDD0gmJz43lG; Sat, 15 Apr 2023 16:09:32 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id niKqp7scauZMSniSxpWqDS; Sat, 15 Apr 2023 16:09:31 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id niSupkkeQ3fOSniSvpk2vg; Sat, 15 Apr 2023 16:09:31 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=643acc3b a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=YxBL1-UpAAAA:8 a=CjxXgO3LAAAA:8 a=6I5d2MoRAAAA:8 a=NEAV23lmAAAA:8 a=EkcXrb_YAAAA:8 a=zfX4q9hhoeRGHETbNR8A:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 7FFAFA7D; Sat, 15 Apr 2023 09:09:28 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 6779826E; Sat, 15 Apr 2023 09:09:28 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: FreeBSD User cc: Cy Schubert , Mark Millard , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> Comments: In-reply-to FreeBSD User message dated "Sat, 15 Apr 2023 17:51:51 +0200." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Apr 2023 09:09:28 -0700 Message-Id: <20230415160928.6779826E@slippy.cwsent.com> X-CMAE-Envelope: MS4xfA3hYRYkpzrM6zEzVLrv5Mg5wDzl4dkfqQc7xkpy38JapMH6TXj9ZcCD9p1LK956upp/v0B9bjaNpLbweB0224y0fMLpmMq6CM9S/Yw8jm/iWgqxUJE0 pbwkgE9IndCpJzXWVxvI2PiR1ZbXvVmqd9rvaOJGRCEvjjrLQ1r1vOGN5+KeZy+ehMWtEaw/jM3/GtCpfa3vwOs1gPed9WEnGUtNOQZRewXnSZ7HnhFNYh8r +UEEtRWIvcMK1Hn/EQC2Px6qJmFYNIaOMB9JjrV3dKHnVcniuByepSugbsmso/Y+olb6VSK8bm27dJVCM1X81pi3x8RG4XxU5ymMRI/lrUgKnHy0aN9zwBmA EAPswYAvMju7dW4pPAGU2QfvQXvI/51YMfHfE5x4s89Kq9Joncg= X-Rspamd-Queue-Id: 4PzJDD0gmJz43lG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de>, FreeBSD Us er writes: > Am Sat, 15 Apr 2023 07:36:25 -0700 > Cy Schubert schrieb: > > > In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>, > > FreeBSD Us > > er writes: > > > Am Thu, 13 Apr 2023 22:18:04 -0700 > > > Mark Millard schrieb: > > > > > > > On Apr 13, 2023, at 21:44, Charlie Li wrote: > > > > > > > > > Mark Millard wrote: > > > > >> FYI: in my original report for a context that has never had > > > > >> block_cloning enabled, I reported BOTH missing files and > > > > >> file content corruption in the poudriere-devel bulk build > > > > >> testing. This predates: > > > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > > > > >> but had the changes from: > > > > >> https://github.com/openzfs/zfs/pull/14739/files > > > > >> The files were missing from packages installed to be used > > > > >> during a port's build. No other types of examples of missing > > > > >> files happened. (But only 11 ports failed.) > > > > > I also don't have block_cloning enabled. "Missing files" prior to brt > _rev > > > ert may actually > > > > > be present, but as the corruption also messes with the file(1) signat > ure, > > > some tools like > > > > > ldconfig report them as missing. > > > > > > > > For reference, the specific messages that were not explicit > > > > null-byte complaints were (some shown with a little context): > > > > > > > > > > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not foun > d > > > > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg > > > > > [CA72_ZFS] Installing libxml2-2.10.3_1... > > > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done > > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found > > > > (/usr/local/lib/libxml2.so) . . . > > > > [CA72_ZFS] Extracting libxslt-1.1.37: .......... done > > > > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found > > > > (/usr/local/lib/libxslt.so) ===> Returning to build of py39-lxml-4.9. > 2 > > > > . . . > > > > ===> Configuring for py39-lxml-4.9.2 > > > > Building lxml version 4.9.2. > > > > Building with Cython 0.29.33. > > > > Error: Please make sure the libxml2 and libxslt development packages ar > e in > > > stalled. > > > > > > > > > > > > [CA72_ZFS] Extracting libunistring-1.1: .......... done > > > > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not f > ound > > > > > > > > > > > > > > > [CA72_ZFS] Extracting gmp-6.2.1: .......... done > > > > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found > > > > > > > > > > > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > > > ===> Installing existing package /packages/All/gmp-6.2.1.pkg > > > > [CA72_ZFS] Installing gmp-6.2.1... > > > > the most recent version of gmp-6.2.1 is already installed > > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > > > > *** Error code 1 > > > > > > > > > > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > > > > > > > > > > > > checking for GNU > > > > M4 that supports accurate traces... configure: error: no acceptable m4 > coul > > > d be found in > > > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommende > d. > > > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > > > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > > > > > > > > > > > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > > > > > > > > > > > === > > > > Mark Millard > > > > marklmi at yahoo.com > > > > > > > > > > > > > > Hello > > > > > > whar is the recent status of fixing/mitigate this desatrous bug? Especial > ly f > > > or those with the > > > new option enabled on ZFS pools. Any advice? > > > > > > In an act of precausion (or call it panic) I shutdown several servers to > prev > > > ent irreversible > > > damages to databases and data storages. We face on one host with /usr/por > ts r > > > esiding on ZFS > > > always errors on the same files created while staging (using portmaster, > leav > > > es the system > > > with noninstalled software, i.e. www/apache24 in our case). Deleting the > work > > > folder doesn't > > > seem to change anything, even when starting a scrubbing of the entire poo > l (R > > > AIDZ1 pool) - > > > cause unknown, why it affects always the same files to be corrupted. Same > wit > > > h deve/ruby-gems. > > > > > > Poudriere has been shutdown for the time being to avoid further issues. > > > > > > Are there any advies to proceed apart from conserving the boxes via shutd > own? > > > > > > Thank you ;-) > > > oh > > > > > > > > > > > > -- > > > O. Hartmann > > > > With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded > > > blocks. #14739" patch I didn't have any issues, except for email messages > > with corruption in my sent directory, nowhere else. I'm still investigating > > > the email messages issue. IMO one is generally safe to run poudriere on the > > > latest ZFS with the additional patch. > > > > My tests of the additional patch concluded that it resolved my last > > problems, except for the sent email problem I'm still investigating. I'm > > sure there's a simple explanation for it, i.e. the email thread was > > corrupted by the EXDEV regression which cannot be fixed by anything, even > > reverting to the previous ZFS -- the data in those files will remain > > damaged regardless. > > > > I cannot speak to the others who have had poudriere and other issues. I > > never had any problems with poudriere on top of the new ZFS. > > > > WRT reverting block_cloning pools to without, your only option is to backup > > > your pool and recreate it without block_cloning. Then restore your data. > > > > > > All right, I interpret the answer that way, that I need a most recent source > tree (and > accordingly built and installed OS) AND a patch that isn't officially commite > d? Yes. > > On a box I'm with: > > FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST 2 > 023 amd64 > > The box is crashing while trying to update ports with the well known issue: > > Panic String: VERIFY(!zil_replaying(zilog, tx)) I never had that problem because I didn't enable block_cloning, except on one pool, which I created a zpool checkpoint to allow for simple rollback if needed. That pool, when tested, had all the patches applied when block_cloning was enabled. It never experienced the panic. > > At the moment all alarm bells are ringing and I lost track about what has bee > n patched and > already commited and what is still as patch available but in the phase of eva > luation or > inofficially emmited here. I maintain a separate branch which contains my own patches on top of what is main. I committed the additional patches on top of it, now a new branch, to keep track of this issue. Maintaining a separate branch saves a lot of grief. I can't help you with this. > > According to the EXDEV issue: in cases of poudriere or ports trees on ZFS, wh > at do I have to > do to ensure that those datasets are clean? The OS should detect file corrupt > ion but in my > case the box is crashing :-( File corruption will not cause a crash. Corruption of metadata might. AFAICT metadata was never corrupted. Only file contents were. > > I did several times scrubbing, but this seems to be the action of a helpless > and desperate man > ... ;-/ Scrubbing doesn't fix file contents that were corrupted prior to the checksum being calculated and written to disk. As far as ZFS is concerned the data is correct. > > Greetings > > Oliver > > -- > O. Hartmann I have for the time being reverted the ZFS import in my day-to-day branch. My branch with the new ZFS + pjd@ patch is currently building. I won't be able to test it until Monday -- because of life things that have taken precedence this weekend. The plan is, starting Monday, to install the branch on my sandbox machine and give it a thorough workout there. Once satisfied I will install it elsewhere. I will report my findings next week. I think it's a good policy for people who track -CURRENT, if they apply patches, commit them to a branch (not main), building and installing from that branch. This avoids all kinds of confusion. This policy will allow you to create your own personal patches you don't wish to share with others. My day-to-day branch contains at a minimum seven patches I never plan on committing. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Apr 15 16:13:47 2023 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 4PzJKC0Jkfz45bBh; Sat, 15 Apr 2023 16:13:51 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PzJKB6Dm3z4Dn4; Sat, 15 Apr 2023 16:13:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id nbnTp7UrxuZMSniX8pWrBU; Sat, 15 Apr 2023 16:13:50 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id niX6pklvc3fOSniX7pk3Xw; Sat, 15 Apr 2023 16:13:50 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=643acd3e a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=pIhXSETnAAAA:8 a=YxBL1-UpAAAA:8 a=NEAV23lmAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=Paoh2FSOps8af3h1t30A:9 a=CjuIK1q_8ugA:10 a=aStlkcwk48vnf0XRxVrg:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 6B176AEB; Sat, 15 Apr 2023 09:13:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 2477026F; Sat, 15 Apr 2023 09:13:48 -0700 (PDT) Date: Sat, 15 Apr 2023 09:13:47 -0700 From: Cy Schubert To: Florian Smeets Cc: FreeBSD User , Mark Millard , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <20230415091342.75009659@cschubert.com> In-Reply-To: <6792aded-6e2e-a118-259d-0df0f80c361c@smeets.xyz> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> <6792aded-6e2e-a118-259d-0df0f80c361c@smeets.xyz> Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfCSL93zqe2hzlbT+rN0mtdsNDcYLe6PAakrNqlaNvC6WGkAjG20z7r/moR5K9lHkrQr6GuPNrLme3GKKTIT4JdqVclocQG3TcUsNYQkAZ05Mtuoucwg7 BRcIF5K8VJFCG2SfpdY7rkRd9qxDNx+kA925eDmCzkFW/TgZO296hG9Y5iF+VRNaiOn6O8k+ATgsENHnOfLCPfCrst/9WkPpCQBZJcIH84xOreqOpHacjoJN xp2VS+huqlD5U5E0UGb+Vm57eYdhBen/WPokplwHg3GTrD4Tg3po/t/6+XnSBIsIohiMQPz7SyeKIlU1/aydMQeFT62Cz4MBNpm2bfv72e8qV1E1hHusbz/B 7wB4iO3qqkpWzk+xzxB82scS7x974yKM5BimwScYLWLGS9IpMTcAyZM+f3oMuiaEkByavSPeQB0VpNXuncVgXMg+CLqcmg== X-Rspamd-Queue-Id: 4PzJKB6Dm3z4Dn4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, 15 Apr 2023 18:07:34 +0200 Florian Smeets wrote: > On 15.04.23 17:51, FreeBSD User wrote: > > Am Sat, 15 Apr 2023 07:36:25 -0700 > > Cy Schubert schrieb: > >> > >> With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded > >> blocks. #14739" patch I didn't have any issues, except for email messages > >> with corruption in my sent directory, nowhere else. I'm still investigating > >> the email messages issue. IMO one is generally safe to run poudriere on the > >> latest ZFS with the additional patch. > > This is also my current observation. I have 2 hosts where I was > unfortunate enough to update at the wrong time. I currently *think* that > I'm *not* seeing data corruption with head from April 12th and this > patch > https://github.com/openzfs/zfs/commit/d3a6e5ca3b2f684132238ca968bf0b96f17ec7e1.diff > applied. > > One pool has been upgraded with feature@block_cloning and the other hasn't. > > > > FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST 2023 amd64 > > > > The box is crashing while trying to update ports with the well known issue: > > > > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > > On the pool that has block_cloning enabled I see the above insta panic > when poudriere starts building. I found a workaround though: > > --- /usr/local/share/poudriere/include/fs.sh.orig 2023-04-15 > 18:03:50.090823000 +0200 > +++ /usr/local/share/poudriere/include/fs.sh 2023-04-15 > 18:04:04.144736000 +0200 > @@ -295,7 +295,6 @@ > fi > > zfs clone -o mountpoint=${mnt} \ > - -o sync=disabled \ > -o atime=off \ > -o compression=off \ > ${fs}@${snap} \ > > With this workaround I was able to build thousands of packages without > panics or failures due to data corruption. Thanks for this. I'll test this next week. A one should be able to test this by hand to capture a dump. > > Florian -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Apr 15 17:44:27 2023 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 4PzLL56mcgz44l8t for ; Sat, 15 Apr 2023 17:44:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (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 4PzLL51bLtz4VPv for ; Sat, 15 Apr 2023 17:44:45 +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=1681580683; bh=ZrcTxurK9d5UwjEFLNbzf6XObLroMR1smTK6w0slaP0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HWLW8b95Y//vR8DV/vtP+5lDt24PVKvE1pirek45s9Nzvyn8hxzkFztHiHQbjZF6hPWbgEuZdbgHcaOaUXH9zN/pDD70z83qbXmXMO9qIbwCQ8rvtl7PDAwYM3ol07S6mNnZ7ZYxSaaVKSGOo20JybgIe1i2dmnIwaXkMslO8V+QILIiCXEr5oRMG0a4FOnzF6Jho41synNjBKgRNGFXWOKYxFW7/XjyZiMjowffq/2P21VavDs/iZZi0peqiUrhghCP0TOv/b01L6wHFqVnLUkiHWaZL6KXyqa1y4eKIjLoE1PqAzp6v4gyjUiBGqNwj9V657jguRViA3EwCS1eRg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681580683; bh=KmVwmZ6OGecjTyNjv9Ga2ZU7Kb3BbmUQoHPc8E0o0eF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QnwrYUH+kE10i87vVWzRIkzNun2W44Xr4RTI4bx05cQdfSP74PEGQove+XWw11H2AXN7uhJFuTWC062H6b/23opeiaYer7TbaruPkRTxBGJLlMb6U/7seTOmOGTx1hkmnk8gFuPJ7xgK0XKh+2Iyu1EoVMVHJAr+pLG/eMzfRnJPH0symEurxhG29GuGqrG3nPyGysvhioLVVYHEQKdwvwqNW7WhejOnRD+A6la3vIMwHBnBXt7RRVQvdbr+f03tgCxTjI3qGt1H+oKksI+Qc40bgQAU3M4pcc0FB+1oUsygcPPjumrqP0yiX6++tBGR2NEZ+VKNMHr3XY15fINIpQ== X-YMail-OSG: ziZLTjoVM1li2vHARzQBVnvieb_HH12r26BBvcAxPwVw_VDpkrUTsnE2QqSmhKe .zgCQ_rBSL9wDZwqakey3X.wPYjpBYcMagyogXykPc6NWPuygVoXzbLP2ZmLH06KwMd95xJFBx2P wZg2TS6BZzmT7OM2BF7UWEPqo6WMaRsuG.QFbd3WBE.hCtu68duMBkB.vlG0b84.ll1hTNyXWjFS TTbFk_.yyTlwNfVBwG3SfdIjvFrojqml2RVBQgXFf2puzC5wJ9qBPnV_Ratsa0RpFzXuLYGSN_XC hNcg.yOsliytcKPcMtCl.dKdECLNl41aQGU.WzW_M7AzLcmis3Dsz5wqfyidLuwJZ5z5ivXoMy5l pjmhk8.JbHqIia2N2JEGDTXDyrHQB4ldeEuubkkmS7D7kFQ8Fln2SbRMOnFqL1KXDG4HK9T.TiS5 BIYVmHE0givi4A6szG5S3zc2LYNx_7KddYOtbOftZtKm.qXGZI3aYlUkgUDbYPbZKuraKsczQjz7 xlWN5icjnrL7x_WyczhMRDtn13HQh4ucE39BlgBn13_FaYh_BAecW6c5KrqhEMX9_W.qoxKhiZAj CUBLbSD7EJhhfLghx_Byk1cu44g2xbT14pcc2oJUJNuJTVGU_R6A.npS1JXSsSlEBIqngMzgMjdc QxIoqIlcuixqegcTgnBk4fBBG9ZqsUSAH_l1inNtGsLFtqO4M1bUorFQi7gcvhERYk6YUDwSD6Eb 5rs4QajclMZFs0u2nIjp.wvUIrISOOKueBxFy8dbEnGHwuE2di9TvputG0fMRKfu95aAXsmW1vxN g_SyuHP9vSwplSWkz_Nb0FRXeemqju7zhQpODE7LlxB33OYz5WPUe4QB.NOjuc0EWq3AviBtk7Un 9OwcEjB9sBenPbbS9TRzvPcWLBC_mEjmlAE9h3a_0gKQpB7uk11Ky0GlYPWJMRqgDLNWHJJyg_3n vPaEuQ1_yCYmhfXpg3Z7mPP2NScbUVNSGGokYi16SsacdAo_UvHdVWfmnJZMrr8NT4JkYeIwYVzq ULwj.5TdJoVd.5v1lhT5efnelDcN3ayzd0T4Nt1N6nEXMyoVyRs.KFESmr40cQcY6ekSAG35rPqG aBQ2HZLgjdbGl410wIaV3bdqfD6ewHb4Yojaauzd3IO3s2TM3y63H4xIhXkDvurKUeIcG0_KrKlt sI.4TFAx0.tBnP6gX8NjewhA8cnEC6B3R3L37GmiaTD6o7Sy1hdLOE3SnOZ0bpF.akixkFWHuws3 Mm5knQLtCPS7P97f2zS3c.t309As76RzHD_O.ljIEc.sc9QnD6tCg1DcZOWgirlcHuY_ndAZLxdG ChJQAG7eYV5wZK4OWRfjdJdps7BDo51cZGs7I1lKFdnv3DNMvzhMzvQx8ELQOWv.q.aY4cPqiYXK rkka7O7BhA9ghIZOmYdzutWwgpA9s.Tk37xpsczuFWiCELtDs9veQFE67AOpIGjSwip2YRohG1nu S01RwEhHNO6echm78yZhPeLyT8ypirJOCdk8LtIlWhS.JLrkhHXhx0FDBXoMmshRXkQ4GFgGt.re r3k5pbmYxOqEH0VRSrhJf_laI399pHZr5ljx3h58OLmvgLMsIzj_Ql3WoVDglxHT7aBe6rVywJYf NaFF1aDhKMqQcnBH_U8Te_qHrpQmhb3KhdmvaV5Tm3XexQHh3kyWRnbBd_hhaJATtLr2m8NmcQHt 7mfrlZoiBqFgizfJ7CbS16Z6_lKHVVyUr9bIBO6w08ntCSeqjdvWY4wpCMpIdZ4nOw8MqqRIssL1 27Xl.uEC4O18T4gPbbqr8L9cYgkXxBbiGL.QcB4PCrfa2zoSaLHKuyElegZJbqUkvT53VkLKSRdH 8jbdUw1nqxTAKCmW8PqrenMFWPQW8.uI995nezHOVsdFCAC_IVH8rwUJiN_STgM7eF4Ntx9q9oTv e9PwZ9DIf.fXaHG6qd0z1gp1tAfQtt3SRK2Qe0Wx97BigVDUrYjSkD.UvrnS4zlhJppjfyM7JNe5 xPmZ3Xevip5jeVAqF_uZCXVDbMSjGMJn1lAN5EAjVTdqMMTSUn_7pM7wDMyH2evEBFbEWjdzruwp VsrW7i21qZ87m.ZZZ4NgMdD7upFowIt0AI9KhkavdN7vyHWQCiR._uLvIKpNh5VOxPwBlzdnJeBs jAkQIRdKJ6znJ9XOKjXRh5XOyX.KEtQ6YFq9Q3H2PHB7ICTH.0b6sN4RtztB1KHOspiT6vLxQiHf zgC59Qx8tv9HvsDDYxTWt1Ymv3JLzANGwrfFkVniZi18AqerRN_M.hErmBXfoSp00VOThxEkvB6l jjBRVlw-- X-Sonic-MF: X-Sonic-ID: 6e967237-709d-47c4-aa42-43619a05bffe Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Apr 2023 17:44:43 +0000 Received: by hermes--production-bf1-5f9df5c5c4-lwjq6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fdf4869d8b16ad3ffd6f52e10113979a; Sat, 15 Apr 2023 17:44:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <20230415143625.99388387@slippy.cwsent.com> Date: Sat, 15 Apr 2023 10:44:27 -0700 Cc: Cy Schubert , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <5A47F62D-0E78-4C3E-84C0-45EEB03C7640@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> To: FreeBSD User X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PzLL51bLtz4VPv X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 15, 2023, at 07:36, Cy Schubert = wrote: > In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>,=20= > FreeBSD Us > er writes: >> Am Thu, 13 Apr 2023 22:18:04 -0700 >> Mark Millard schrieb: >>=20 >>> On Apr 13, 2023, at 21:44, Charlie Li wrote: >>>=20 >>>> Mark Millard wrote: =20 >>>>> FYI: in my original report for a context that has never had >>>>> block_cloning enabled, I reported BOTH missing files and >>>>> file content corruption in the poudriere-devel bulk build >>>>> testing. This predates: >>>>> https://people.freebsd.org/~pjd/patches/brt_revert.patch >>>>> but had the changes from: >>>>> https://github.com/openzfs/zfs/pull/14739/files >>>>> The files were missing from packages installed to be used >>>>> during a port's build. No other types of examples of missing >>>>> files happened. (But only 11 ports failed.) =20 >>>> I also don't have block_cloning enabled. "Missing files" prior to = brt_rev >> ert may actually >>>> be present, but as the corruption also messes with the file(1) = signature, >> some tools like >>>> ldconfig report them as missing. =20 >>>=20 >>> For reference, the specific messages that were not explicit >>> null-byte complaints were (some shown with a little context): >>>=20 >>>=20 >>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so - = not found >>> =3D=3D=3D> Installing existing package = /packages/All/libxml2-2.10.3_1.pkg =20 >>> [CA72_ZFS] Installing libxml2-2.10.3_1... >>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done >>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so - = found >>> (/usr/local/lib/libxml2.so) . . . >>> [CA72_ZFS] Extracting libxslt-1.1.37: .......... done >>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxslt.so - = found >>> (/usr/local/lib/libxslt.so) =3D=3D=3D> Returning to build of = py39-lxml-4.9.2 =20 >>> . . . >>> =3D=3D=3D> Configuring for py39-lxml-4.9.2 =20 >>> Building lxml version 4.9.2. >>> Building with Cython 0.29.33. >>> Error: Please make sure the libxml2 and libxslt development packages = are in >> stalled. >>>=20 >>>=20 >>> [CA72_ZFS] Extracting libunistring-1.1: .......... done >>> =3D=3D=3D> libidn2-2.3.4 depends on shared library: = libunistring.so - not found >>=20 >>>=20 >>>=20 >>> [CA72_ZFS] Extracting gmp-6.2.1: .......... done >>> =3D=3D=3D> mpfr-4.2.0,1 depends on shared library: libgmp.so - not = found =20 >>>=20 >>>=20 >>> =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - not = found >>> =3D=3D=3D> Installing existing package /packages/All/gmp-6.2.1.pkg = =20 >>> [CA72_ZFS] Installing gmp-6.2.1... >>> the most recent version of gmp-6.2.1 is already installed >>> =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - not = found =20 >>> *** Error code 1 >>>=20 >>>=20 >>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 >>>=20 >>>=20 >>> checking for GNU=20 >>> M4 that supports accurate traces... configure: error: no acceptable = m4 coul >> d be found in >>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is = recommended. >>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems. >>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. >>>=20 >>>=20 >>> ld: error: /usr/local/lib/libblkid.a: unknown file type >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>>=20 >>>=20 >>=20 >> Hello=20 >>=20 >> whar is the recent status of fixing/mitigate this desatrous bug? = Especially f >> or those with the >> new option enabled on ZFS pools. Any advice? >>=20 >> In an act of precausion (or call it panic) I shutdown several servers = to prev >> ent irreversible >> damages to databases and data storages. We face on one host with = /usr/ports r >> esiding on ZFS >> always errors on the same files created while staging (using = portmaster, leav >> es the system >> with noninstalled software, i.e. www/apache24 in our case). Deleting = the work >> folder doesn't >> seem to change anything, even when starting a scrubbing of the entire = pool (R >> AIDZ1 pool) - >> cause unknown, why it affects always the same files to be corrupted. = Same wit >> h deve/ruby-gems. >>=20 >> Poudriere has been shutdown for the time being to avoid further = issues.=20 >>=20 >> Are there any advies to proceed apart from conserving the boxes via = shutdown? >>=20 >> Thank you ;-) >> oh >>=20 >>=20 >>=20 >> --=20 >> O. Hartmann >=20 > With an up-to-date tree + pjd@'s "Fix data corruption when cloning = embedded=20 > blocks. #14739" patch I didn't have any issues, except for email = messages=20 > with corruption in my sent directory, nowhere else. I'm still = investigating=20 > the email messages issue. IMO one is generally safe to run poudriere = on the=20 > latest ZFS with the additional patch. My poudriere testing failed when I tested such (14739 included), per what I reported, block_cloning never have been enabled. Others have also reported poudriere bulk build failures absent block_cloning being involved and 14739 being in place. My tests do predate: https://people.freebsd.org/~pjd/patches/brt_revert.patch and I'm not sure of if Cy's activity had brt_revert.patch in place or not. Other's notes include Mateusz Guzik's: = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014534.= html which said: QUOTE There is corruption with the recent import, with the https://github.com/openzfs/zfs/pull/14739/files patch applied and block cloning disabled on the pool. There is no corruption with top of main with zfs merge reverted = altogether. Which commit results in said corruption remains to be seen, a variant of the tree with just block cloning support reverted just for testing purposes is about to be evaluated. END QUOTE Charlie Li's later related notes that helps interpret that were in: = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014545.= html QUOTE Testing with mjg@ earlier today revealed that block_cloning was not the=20= cause of poudriere bulk build (and similar cp(1)/install(1)-based)=20 corruption, although may have exacerbated it. END QUOTE Mateusz later indicated had a hope to have is sorted out sometime Friday for what the cause(s) were: = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014551.= html QUOTE I'm going to narrow down the non-blockcopy corruption after my testjig gets off the ground. Basically I expect to have it sorted out on Friday. END QUOTE But the lack of later related messages suggests that did not happen. > My tests of the additional patch (I'm guessing that is a reference to 14739, not to brt_revert.patch .) > concluded that it resolved my last=20 > problems, except for the sent email problem I'm still investigating. = I'm=20 > sure there's a simple explanation for it, i.e. the email thread was=20 > corrupted by the EXDEV regression which cannot be fixed by anything, = even=20 > reverting to the previous ZFS -- the data in those files will remain=20= > damaged regardless. Again: my test jump from prior to the import to after the EXDEV changes, including having 14739. I still had poudriere bulk produce file corruptions. > I cannot speak to the others who have had poudriere and other issues. = I=20 > never had any problems with poudriere on top of the new ZFS. Part of the mess is the variability. As I remember, I had 252 ports build fine in my test before the 11th failure meant that the rest (213) had all been classified as skipped. It is not like most of the port builds failed: relatively uncommon. Also, one port built on a retry, indicating random/racy behavior is involved. (The original failure was not from a file from installing build dependencies but something that the builder generated during the build. The 2nd try did not fail there or anywhere.) > WRT reverting block_cloning pools to without, your only option is to = backup=20 > your pool and recreate it without block_cloning. Then restore your = data. >=20 Given what has been reported by multiple people and Cy's own example of unexplained corruptions in email handling, I'd be cautious risking important data until reports from testing environment activity consistently report not having corruptions. Another thing my activity does not include any testing of the suggestion in: = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014607.= html to use "-o sync=3Ddisabled" in a clone, reporting: QUOTE With this workaround I was able to build thousands of packages without=20= panics or failures due to data corruption. END QUOTE If reliable, that consequence to the change might help folks that are trying to isolate the problem(s) figure out what is involved. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 15 17:56:21 2023 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 4PzLbb3y1pz44ltf for ; Sat, 15 Apr 2023 17:56:27 +0000 (UTC) (envelope-from grahamperrin@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 4PzLbb3VsMz3NY9 for ; Sat, 15 Apr 2023 17:56:27 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681581387; 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=KXwR1YUHwld2jdtvfftnuD0y+OrcrOr9PqNwoqI74nE=; b=rlli5sAI9IKA0IZ5qERgN8wqO6ULbQ8QUxivszC2H6Qk3MSLlbpP5UKbg4Fmry8dk8Uxds Ck9v43CsSe0knzZZrtTl17k4ydubYA1cDJwTDrMkvZO5I/YttESJL9oVXSwTZZ9n2Cy0WX zGJm2mQXiu6FtCTE4y5bIC3aH66ZEOfTnVdRfiZyMm4Px/b/cD8U3IElkvkV0YnTcKMO1f U4AZprrshwFqHpjXtLldFAUKeiiEC2FZ2+JiRCyuLvAG8iZ0Y2vpsTCpvCYtiNGtRgIl6I 1rFF62FHFN0m8I1N+ARr+x8dnxCEGUFXqWnHJ4yl7WzgY/xR+qUjw8o3PunoQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681581387; 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=KXwR1YUHwld2jdtvfftnuD0y+OrcrOr9PqNwoqI74nE=; b=CuFSynm4jKi0FJ/wmdrV15GuQ2ow0dQ8e8ZOUqNP3djDyj5cxjHF5t31EDCIcxiWQQ024u Ur6nGAO+T3pkE0ipHRA9FoB2fUmdn7+9+JbrKf7Fu8P46+IZhjJ9Iwn4IKu91Lz3L1SnTO /BdJq2MXLXKeotb0XxF1yzBTcaOBC1UnRcfyJ2PU1jr/PruLRNEIUCRveKV+ejSI/k9DxQ kdXnZC3oh3FafhY1OiGqn0YSCLd7lwm45EZAoSuf1zfXSucok13oD688xdEXWrEZHfChjk D1mOJH3NqMX3XbX7C8MeKzBBV0+yUht79lsGym1gCX6SVrqPdQZFoNmX+n3Nhg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681581387; a=rsa-sha256; cv=none; b=F2chrfR0CYulo227VO8zaYFLi/h5aE4HjvWmsqa/nIz4YAZQKxCvNl7HMQx9eG9qwJqMez Zu5Wi5fylO7eBWWWDWiwi4XPKKMuc0SeiGQKCEBfsEUOwxsQKvlqeexz5tRD9M5x8CdYQR eFcjwqrBXjEQcXdUcg24AmUw0Yuc+Fbi3n9n5/SyMMuphjVDzlZVWg+EWfUZ3bgXG6joMB MaAYu1F7oJtgF2wIt1T9SLkcEmkHoZ18gAlXY9hNXvAgeUFy0+kWZvCPcToLp1jU5dpKqA eUWhwHo129EoFyGX7jv/ltnhHy85Q7zubO0ELBLxXkNtZVzNmy2VCDOLKUabqw== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (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: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PzLbZ5g8hzjdr for ; Sat, 15 Apr 2023 17:56:26 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <29ec969d-1aa2-0e4d-ba35-6fc3a5ba2b61@freebsd.org> Date: Sat, 15 Apr 2023 18:56:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: =?UTF-8?Q?Re=3a_OpenZFS_recently_=28was_=e2=80=a6_=5bzfs_corruption?= =?UTF-8?Q?s_without_block=5fcloning_involved!=5d=29?= To: freebsd-current@freebsd.org References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> Content-Language: en-US From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------AVRsKUpvuKb1ffKxHi3TdLXX" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------AVRsKUpvuKb1ffKxHi3TdLXX Content-Type: multipart/mixed; boundary="------------NFkfS0fBzNP8DoxVXPM4TptA"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Message-ID: <29ec969d-1aa2-0e4d-ba35-6fc3a5ba2b61@freebsd.org> Subject: =?UTF-8?Q?Re=3a_OpenZFS_recently_=28was_=e2=80=a6_=5bzfs_corruption?= =?UTF-8?Q?s_without_block=5fcloning_involved!=5d=29?= References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> In-Reply-To: --------------NFkfS0fBzNP8DoxVXPM4TptA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTUvMDQvMjAyMyAxNDo0MSwgdm9pZCB3cm90ZToNCj4gT24gU2F0LCBBcHIgMTUsIDIw MjMgYXQgMDk6NTY6MzRBTSArMDEwMCwgR3JhaGFtIFBlcnJpbiB3cm90ZToNCj4+DQo+PiBJ cyB0aGUgcmVjZW50IHNpdHVhdGlvbiB1bnVzdWFsIGVub3VnaCB0byB3YXJyYW50IGFuIGVu dHJ5IGluIFVQREFUSU5HPw0KPj4NCj4NCj4geWVhaCBJJ2Qgc2F5IHNvLg0KPg0KPiBBbHNv IGRvZXMgdGhpcyBhZmZlY3QgMTMtc3RhYmxlIGFuZCB0aGUgcmVjZW50IDEzLjItUkVMRUFT RSBvciBqdXN0IA0KPiAtY3VycmVudD8NCg0KDQpJZiBJJ20gbG9va2luZyBpbiB0aGUgcmln aHQgcGxhY2U6DQoNCjxodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVlYnNkLXNyYy9j b21taXQvMmE1OGIzMT4gdG8gbWFpbiBvbiANCjIwMjMtMDQtMDMsICJ6ZnM6IG1lcmdlIG9w ZW56ZnMvemZzQDQzMTA4M2Y3NSINCg0KPGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMv bG9nLz9oPXN0YWJsZSUyRjEzJnF0PWdyZXAmcT1tZXJnZT4gbm8gDQpjb21wYXJhYmxlIG1l cmdlIHRvIHN0YWJsZS8xMy4NCg0K --------------NFkfS0fBzNP8DoxVXPM4TptA-- --------------AVRsKUpvuKb1ffKxHi3TdLXX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmQ65UYFAwAAAAAACgkQt2dIb0oY1As3 2xAAgQd21RJcNbVNmb9mzOTVWwog5Dp00QYQMiZSN5iNxOQW9C3GaDmC0Y6FQyjYhWHarWs5YfHj /LPjFbAgjeSe+q86yYcjq0sBq/YEyS7znd0Ifej0Ry8LVmXjJTpMhGcgKG4NAIf+tOwpOjqeytTf lt61fPL78/kCXcFdLcmgwSkGoBj1vY34I82R2fvxCzwruQWMwdlzT+eHkXbgNGc6aP88Vwi9TrCX yP5u2rx0qNSJRwRhjUI5bhywvyLxdidMoIU1TMqXpGyZXMOjJkiJOmi2BZM4fuw7PzhNMst08z69 g63lp+nYk1HyWA2d9X+UGoYdHiRUCToHJQYyENxN7JeOWMAdNvgdgPIRVkVrkfF1nxMZjCTYzgmt JAK4n2iMX3YGSxmSupRGPfnNjeDncxYy7snUrlNSYhiJOvLGvpSWolaC1+n6A3bkM1QDFG+DYaFm hpRjPzR2RfpOVDFbd1ZBc3gQ5jfUqH+tF9ZxE2mGTGADyizEwNOvXtWNyrTLOfmuj54rCGH+0cCb jx/FbkXSDDOS4q8t//MBrfC7qXK5NPKGw08536HMx2TvHkOk+OoaOHO1L+MQPCpoyUMdDxxM9c8a oe1BSEs6LZDJSTy8cEDqtARPVeUqat12X8kuMVcOn7Uf52loocVdpTBKxqa/loaeK4Qq2H6I8wOA 6ho= =Vuy/ -----END PGP SIGNATURE----- --------------AVRsKUpvuKb1ffKxHi3TdLXX-- From nobody Sat Apr 15 18:07:20 2023 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 4PzLrD6T01z44nBP; Sat, 15 Apr 2023 18:07:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PzLrD5Pltz3ptR; Sat, 15 Apr 2023 18:07:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id nfRep7gETuZMSnkJ1pXA6g; Sat, 15 Apr 2023 18:07:23 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id nkIzpYyrCHFsOnkJ0pZWpu; Sat, 15 Apr 2023 18:07:23 +0000 X-Authority-Analysis: v=2.4 cv=XZqaca15 c=1 sm=1 tr=0 ts=643ae7db a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=dKHAf1wccvYA:10 a=CjxXgO3LAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=NEAV23lmAAAA:8 a=EkcXrb_YAAAA:8 a=prghdMYoeJGcPJPqXUcA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id C845AC2B; Sat, 15 Apr 2023 11:07:20 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id AC396404; Sat, 15 Apr 2023 11:07:20 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Millard cc: FreeBSD User , Cy Schubert , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 In-reply-to: <5A47F62D-0E78-4C3E-84C0-45EEB03C7640@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <5A47F62D-0E78-4C3E-84C0-45EEB03C7640@yahoo.com> Comments: In-reply-to Mark Millard message dated "Sat, 15 Apr 2023 10:44:27 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Apr 2023 11:07:20 -0700 Message-Id: <20230415180720.AC396404@slippy.cwsent.com> X-CMAE-Envelope: MS4xfCDP39lIXqdix0YHS8OJ95czLgtmj+dK9h+5b5rp5lmoDN01+SkRJE06GU348XBHm6uKgt1J2D6+iHeJuzrXpmspKDwQBj1B8Mscj/v0rs74pIr4iAJJ dE6kjG/dSWrdq/jTggzB/EWlG4l0qqtRiG2EeOjeOKNXb2lGRH3iwxh+DyGRQNROIQysqlij7vqmKTYrbWOtdssS2eMyuXjzFC8msW0cyM+aIL3HnOLjmK7g 0IlUjw4jkwN0gA0xOBvsfETy5ap17YnnQ86HsFmMQJjVxhOGlXDL+4wzilvargA2VoXABZZWYJRwZDtl9XUGU4z3qwB1wKXVvDFSDzuMFyLo0QZT8XsomFQp KnkBIgiCm/Q8FNVXwyyREewHkTq7GzEXTmYVgHlzWYCtUMCKrQo= X-Rspamd-Queue-Id: 4PzLrD5Pltz3ptR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <5A47F62D-0E78-4C3E-84C0-45EEB03C7640@yahoo.com>, Mark Millard write s: > On Apr 15, 2023, at 07:36, Cy Schubert = > wrote: > > > In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>,=20= > > > FreeBSD Us > > er writes: > >> Am Thu, 13 Apr 2023 22:18:04 -0700 > >> Mark Millard schrieb: > >>=20 > >>> On Apr 13, 2023, at 21:44, Charlie Li wrote: > >>>=20 > >>>> Mark Millard wrote: =20 > >>>>> FYI: in my original report for a context that has never had > >>>>> block_cloning enabled, I reported BOTH missing files and > >>>>> file content corruption in the poudriere-devel bulk build > >>>>> testing. This predates: > >>>>> https://people.freebsd.org/~pjd/patches/brt_revert.patch > >>>>> but had the changes from: > >>>>> https://github.com/openzfs/zfs/pull/14739/files > >>>>> The files were missing from packages installed to be used > >>>>> during a port's build. No other types of examples of missing > >>>>> files happened. (But only 11 ports failed.) =20 > >>>> I also don't have block_cloning enabled. "Missing files" prior to = > brt_rev > >> ert may actually > >>>> be present, but as the corruption also messes with the file(1) = > signature, > >> some tools like > >>>> ldconfig report them as missing. =20 > >>>=20 > >>> For reference, the specific messages that were not explicit > >>> null-byte complaints were (some shown with a little context): > >>>=20 > >>>=20 > >>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so - = > not found > >>> =3D=3D=3D> Installing existing package = > /packages/All/libxml2-2.10.3_1.pkg =20 > >>> [CA72_ZFS] Installing libxml2-2.10.3_1... > >>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done > >>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so - = > found > >>> (/usr/local/lib/libxml2.so) . . . > >>> [CA72_ZFS] Extracting libxslt-1.1.37: .......... done > >>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxslt.so - = > found > >>> (/usr/local/lib/libxslt.so) =3D=3D=3D> Returning to build of = > py39-lxml-4.9.2 =20 > >>> . . . > >>> =3D=3D=3D> Configuring for py39-lxml-4.9.2 =20 > >>> Building lxml version 4.9.2. > >>> Building with Cython 0.29.33. > >>> Error: Please make sure the libxml2 and libxslt development packages = > are in > >> stalled. > >>>=20 > >>>=20 > >>> [CA72_ZFS] Extracting libunistring-1.1: .......... done > >>> =3D=3D=3D> libidn2-2.3.4 depends on shared library: = > libunistring.so - not found > >>=20 > >>>=20 > >>>=20 > >>> [CA72_ZFS] Extracting gmp-6.2.1: .......... done > >>> =3D=3D=3D> mpfr-4.2.0,1 depends on shared library: libgmp.so - not = > found =20 > >>>=20 > >>>=20 > >>> =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - not = > found > >>> =3D=3D=3D> Installing existing package /packages/All/gmp-6.2.1.pkg = > =20 > >>> [CA72_ZFS] Installing gmp-6.2.1... > >>> the most recent version of gmp-6.2.1 is already installed > >>> =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - not = > found =20 > >>> *** Error code 1 > >>>=20 > >>>=20 > >>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > >>>=20 > >>>=20 > >>> checking for GNU=20 > >>> M4 that supports accurate traces... configure: error: no acceptable = > m4 coul > >> d be found in > >>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is = > recommended. > >>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > >>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > >>>=20 > >>>=20 > >>> ld: error: /usr/local/lib/libblkid.a: unknown file type > >>>=20 > >>>=20 > >>> =3D=3D=3D > >>> Mark Millard > >>> marklmi at yahoo.com > >>>=20 > >>>=20 > >>=20 > >> Hello=20 > >>=20 > >> whar is the recent status of fixing/mitigate this desatrous bug? = > Especially f > >> or those with the > >> new option enabled on ZFS pools. Any advice? > >>=20 > >> In an act of precausion (or call it panic) I shutdown several servers = > to prev > >> ent irreversible > >> damages to databases and data storages. We face on one host with = > /usr/ports r > >> esiding on ZFS > >> always errors on the same files created while staging (using = > portmaster, leav > >> es the system > >> with noninstalled software, i.e. www/apache24 in our case). Deleting = > the work > >> folder doesn't > >> seem to change anything, even when starting a scrubbing of the entire = > pool (R > >> AIDZ1 pool) - > >> cause unknown, why it affects always the same files to be corrupted. = > Same wit > >> h deve/ruby-gems. > >>=20 > >> Poudriere has been shutdown for the time being to avoid further = > issues.=20 > >>=20 > >> Are there any advies to proceed apart from conserving the boxes via = > shutdown? > >>=20 > >> Thank you ;-) > >> oh > >>=20 > >>=20 > >>=20 > >> --=20 > >> O. Hartmann > >=20 > > With an up-to-date tree + pjd@'s "Fix data corruption when cloning = > embedded=20 > > blocks. #14739" patch I didn't have any issues, except for email = > messages=20 > > with corruption in my sent directory, nowhere else. I'm still = > investigating=20 > > the email messages issue. IMO one is generally safe to run poudriere = > on the=20 > > latest ZFS with the additional patch. > > My poudriere testing failed when I tested such (14739 included), > per what I reported, block_cloning never have been enabled. > Others have also reported poudriere bulk build failures absent > block_cloning being involved and 14739 being in place. My tests > do predate: > > https://people.freebsd.org/~pjd/patches/brt_revert.patch IIRC this patch doesn't build. My tree includes this patch. Pardon the cut&paste. This will not apply. diff --git a/sys/contrib/openzfs/module/zfs/dmu.c b/sys/contrib/openzfs/modu le/zfs/dmu.c985d833f58..cda1472a77aa 100644 --- a/sys/contrib/openzfs/module/zfs/dmu.c +++ b/sys/contrib/openzfs/module/zfs/dmu.c @@ -2312,8 +2312,10 @@ dmu_brt_clone(objset_t *os, uint64_t object, uint64_t offset, uint64_t length, dl->dr_overridden_by.blk_phys_birth = 0; } else { dl->dr_overridden_by.blk_birth = dr->dr_txg; - dl->dr_overridden_by.blk_phys_birth = - BP_PHYSICAL_BIRTH(bp); + if (!BP_IS_EMBEDDED(bp)) { + dl->dr_overridden_by.blk_phys_birth = + BP_PHYSICAL_BIRTH(bp); + } } mutex_exit(&db- > > and I'm not sure of if Cy's activity had brt_revert.patch in > place or not. I don't know if your poudriere has any residual file corruption or not. My poudriere working 100% ok and yours not indicates there may be something amiss with your poudriere tree. Remember I rolled back to the last nightly snapshot whereas you did not. I don't know the state of your poudriere tree. I know with 100% certainty that my tree is good. > > Other's notes include Mateusz Guzik's: > > = > https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014534.= > html My tree included this patch + pjd@'s last patch on people.freebsd.org. > > which said: > > QUOTE > There is corruption with the recent import, with the > https://github.com/openzfs/zfs/pull/14739/files patch applied and > block cloning disabled on the pool. I had zero poudriere corruption with this patch. My only corruption was in my sent-items in my MH mail directory, which I think was due to email threads already containing nulls. > > There is no corruption with top of main with zfs merge reverted = > altogether. > > Which commit results in said corruption remains to be seen, a variant > of the tree with just block cloning support reverted just for testing > purposes is about to be evaluated. > END QUOTE > > Charlie Li's later related notes that helps interpret that were in: > > = > https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014545.= > html > > QUOTE > Testing with mjg@ earlier today revealed that block_cloning was not the=20= > > cause of poudriere bulk build (and similar cp(1)/install(1)-based)=20 > corruption, although may have exacerbated it. > END QUOTE > > Mateusz later indicated had a hope to have is sorted out sometime > Friday for what the cause(s) were: > > = > https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014551.= > html > > QUOTE > I'm going to narrow down the non-blockcopy corruption after my testjig > gets off the ground. > > Basically I expect to have it sorted out on Friday. > END QUOTE > > But the lack of later related messages suggests that did not happen. > > > My tests of the additional patch > > (I'm guessing that is a reference to 14739, not to brt_revert.patch .) > > > concluded that it resolved my last=20 > > problems, except for the sent email problem I'm still investigating. = > I'm=20 > > sure there's a simple explanation for it, i.e. the email thread was=20 > > corrupted by the EXDEV regression which cannot be fixed by anything, = > even=20 > > reverting to the previous ZFS -- the data in those files will remain=20= > > > damaged regardless. > > Again: my test jump from prior to the import to after the EXDEV > changes, including having 14739. I still had poudriere bulk > produce file corruptions. > > > I cannot speak to the others who have had poudriere and other issues. = > I=20 > > never had any problems with poudriere on top of the new ZFS. > > Part of the mess is the variability. As I remember, I had 252 > ports build fine in my test before the 11th failure meant that > the rest (213) had all been classified as skipped. > > It is not like most of the port builds failed: relatively uncommon. > > Also, one port built on a retry, indicating random/racy behavior > is involved. (The original failure was not from a file from > installing build dependencies but something that the builder > generated during the build. The 2nd try did not fail there or > anywhere.) > > > WRT reverting block_cloning pools to without, your only option is to = > backup=20 > > your pool and recreate it without block_cloning. Then restore your = > data. > >=20 > > Given what has been reported by multiple people and > Cy's own example of unexplained corruptions in email > handling, I'd be cautious risking important data > until reports from testing environment activity > consistently report not having corruptions. The "unexplained" email corruptions occurred in only the threads that already had corruption. I haven't been able to reproduce it anywhere else. I will continue testing on Monday. I expect my testing to confirm this hypothesis. > > Another thing my activity does not include any testing > of the suggestion in: > > = > https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014607.= > html > > to use "-o sync=3Ddisabled" in a clone, reporting: This is a different issue. We need a core dump to resolve this. I'll test this on my sandbox on Monday. We can now reproduce this panic by hand. If there is no panic a diff -qr will confirm/deny this bug. > > QUOTE > With this workaround I was able to build thousands of packages without=20= > > panics or failures due to data corruption. > END QUOTE > > If reliable, that consequence to the change might help > folks that are trying to isolate the problem(s) figure > out what is involved. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com IMO we've had a lack of systematic testing of the various bugs. The fact that this has caused some corrupt files has led to human panic over the issue. Now that I've reverted my laptop to the old ZFS, the MH sent-email issue continues to exhibit itself. This is because the files I forward to myself already contain corrupt data. The old ZFS will not magically remove this. This testing is necessary to prove my hypothesis. I expect brand new email threads not to exhibit this problem with the new ZFS. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Apr 15 18:23:36 2023 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 4PzMC12Syrz44pTy for ; Sat, 15 Apr 2023 18:23:41 +0000 (UTC) (envelope-from chris@cretaforce.gr) Received: from relay4.cretaforce.gr (relay4.cretaforce.gr [195.201.253.147]) (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 "*.cretaforce.gr", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PzMC01NjNz46Sg for ; Sat, 15 Apr 2023 18:23:40 +0000 (UTC) (envelope-from chris@cretaforce.gr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cretaforce.gr header.s=cretaforce header.b="N/Ak2FqW"; spf=pass (mx1.freebsd.org: domain of chris@cretaforce.gr designates 195.201.253.147 as permitted sender) smtp.mailfrom=chris@cretaforce.gr; dmarc=pass (policy=none) header.from=cretaforce.gr Received: from server1.cretaforce.gr (server1.cretaforce.gr [94.130.217.104]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "*.cretaforce.gr", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by smtp2.cretaforce.gr (Postfix) with ESMTPS id 78B551FBC6 for ; Sat, 15 Apr 2023 21:23:37 +0300 (EEST) Received: from smtpclient.apple (athedsl-4392785.home.otenet.gr [79.130.119.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: chris@cretaforce.gr) by server1.cretaforce.gr (Postfix) with ESMTPSA id 48A20A8D9 for ; Sat, 15 Apr 2023 21:23:37 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cretaforce.gr; s=cretaforce; t=1681583017; 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=haLP2T8Xz4McQbRVBJHQ/854iwUdCRoBF+WpYRKOXw8=; b=N/Ak2FqWIk2A4RuzKXsQux09Aj2D/l8yy2qzGLYVi2x3PYE4O2W8DDrduGGPIA3NQ0jlKq pTgSiMUWhHhXyko58yor5pqFtlvz25TykEM/L+81jhCM8jDOwYvHEZIQjNP1aZXXEb24nU D3fhoYcLOjMEksz6xKMsscHhiY0nbsw= From: Christos Chatzaras Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: =?utf-8?Q?Re=3A_OpenZFS_recently_=28was_=E2=80=A6_=5Bzfs_corrupti?= =?utf-8?Q?ons_without_block=5Fcloning_involved!=5D=29?= Date: Sat, 15 Apr 2023 21:23:36 +0300 References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> <29ec969d-1aa2-0e4d-ba35-6fc3a5ba2b61@freebsd.org> To: FreeBSD CURRENT In-Reply-To: <29ec969d-1aa2-0e4d-ba35-6fc3a5ba2b61@freebsd.org> Message-Id: X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-4.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[cretaforce.gr:dkim]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[cretaforce.gr,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.253.147]; R_DKIM_ALLOW(-0.20)[cretaforce.gr:s=cretaforce]; RCVD_IN_DNSWL_LOW(-0.10)[195.201.253.147:from]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[chris]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; SUBJECT_HAS_EXCLAIM(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cretaforce.gr:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4PzMC01NjNz46Sg X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N > On 15 Apr 2023, at 20:56, Graham Perrin = wrote: >=20 > On 15/04/2023 14:41, void wrote: >> On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote: >>>=20 >>> Is the recent situation unusual enough to warrant an entry in = UPDATING? >>>=20 >>=20 >> yeah I'd say so. >>=20 >> Also does this affect 13-stable and the recent 13.2-RELEASE or just = -current? >=20 >=20 > If I'm looking in the right place: >=20 > to main on = 2023-04-03, "zfs: merge openzfs/zfs@431083f75" >=20 > = no comparable merge to stable/13. >=20 Looks like only CURRENT is affected.= From nobody Sat Apr 15 18:24:37 2023 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 4PzMDf42T7z44pXk for ; Sat, 15 Apr 2023 18:25:06 +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 4PzMDc12vqz49PP for ; Sat, 15 Apr 2023 18:25:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62a.google.com with SMTP id ud9so53571129ejc.7 for ; Sat, 15 Apr 2023 11:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1681583101; x=1684175101; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ymfx2uyYjLLh9sRkwRwkI3ZR3OpoHQKfJxGEx+5KUBc=; b=tp+F1M9Tx3MWYOSY0ZvbcBFd9EZj6E2zzypL960EZ8gq+6BmQo+UNeNaKq/yFWfoQt fUc+Nh1VwbD63iBzr26+yK73uOd9iaeb3UrTTtQtnHqtGo9+kF6fkh8QYciNICmFEZTz 62mNPZFhzHQqhcLixKEN7k7an3Hdv9WE2tKEWD365FqXdS+JAjLNhR8EGUIJENFOPE1l PGNUMGzzPlIKywSeGlXIBTAUvRdQdQRfY/2KADg6WnU4oJNahLhSlyoj7J87n1f+d3hN 1Vsj4rhezpTXr9TU2HrFZ0c0dgcTMod1k7DI/ZwsPMrDXsZWrWOvSa42zAOj1z4hJTgy QEIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681583101; x=1684175101; 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=ymfx2uyYjLLh9sRkwRwkI3ZR3OpoHQKfJxGEx+5KUBc=; b=kbW81MCX7MDPseME7OOFvNB0TQCLrlqc9vQIm595XJ91d4iUWz0raUzy4p/wFQlvzV 2V6KFZR4NeEsnvYiZm5zr5a7lscL48ECfIwbcjCD74DGpnGGCBCKrj8lY3937ja6UGGu uyM6XFcSoApkY7MyKsRhs8Wq+Lugrxgp94tSM6nUOaqvKfAznb2MIR/bM9N5k4zaGCWh lSEBpha59/qrEGkkgKPBW6lQ40sqjNCshFx6wZw0y3mSUirkvjFeQ0mL7NLbOIeWceWb 5UkXTGetxAecF0b09b65t4ypajI97R6eUBPG0Qi3TFuANLVqiuWG+ikJ8FmEQ7STEojP PMrw== X-Gm-Message-State: AAQBX9eaNtJCPAhuTtQRZ2ONTMRVoVKty6lVh5fs/zIZW7pD0ibhokVV toL9R8Us3EtOTkvX6MEva/nHlBE+imUp/SkRgrsOBg== X-Google-Smtp-Source: AKy350YaHJBlNXWnCy1OBgjFxk6fq6uFSILzZpRSZcssJLNrS+TRXpZoT+jvUYLLb1AOiZfkGEsOYlJD6l/tc9Fzcmg= X-Received: by 2002:a17:906:a443:b0:94e:4925:3c41 with SMTP id cb3-20020a170906a44300b0094e49253c41mr1129859ejb.2.1681583101244; Sat, 15 Apr 2023 11:25:01 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> <988674ff-d7a7-b271-4ec6-9f568e407945@freebsd.org> <29ec969d-1aa2-0e4d-ba35-6fc3a5ba2b61@freebsd.org> In-Reply-To: <29ec969d-1aa2-0e4d-ba35-6fc3a5ba2b61@freebsd.org> From: Warner Losh Date: Sat, 15 Apr 2023 12:24:37 -0600 Message-ID: Subject: =?UTF-8?Q?Re=3A_OpenZFS_recently_=28was_=E2=80=A6_=5Bzfs_corruptions_witho?= =?UTF-8?Q?ut_block=5Fcloning_involved=21=5D=29?= To: Graham Perrin Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000690c1705f96413a4" X-Rspamd-Queue-Id: 4PzMDc12vqz49PP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000690c1705f96413a4 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 15, 2023, 11:56 AM Graham Perrin wrote: > On 15/04/2023 14:41, void wrote: > > On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote: > >> > >> Is the recent situation unusual enough to warrant an entry in UPDATING? > >> > > > > yeah I'd say so. > > > > Also does this affect 13-stable and the recent 13.2-RELEASE or just > > -current? > > > If I'm looking in the right place: > > to main on > 2023-04-03, "zfs: merge openzfs/zfs@431083f75" > > no > comparable merge to stable/13. > Correct. The change isn't in the branch stable/13 tracks. Warner > --000000000000690c1705f96413a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Apr 15, 2023, 11:56 AM Graham Perrin <grahamperrin@freebsd.org> wro= te:
On 15/04/2023 14:41, void wrote= :
> On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote:
>>
>> Is the recent situation unusual enough to warrant an entry in UPDA= TING?
>>
>
> yeah I'd say so.
>
> Also does this affect 13-stable and the recent 13.2-RELEASE or just > -current?


If I'm looking in the right place:

<https://github.com/freebsd/fre= ebsd-src/commit/2a58b31> to main on
2023-04-03, "zfs: merge openzfs/zfs@431083f75"

<https://= cgit.freebsd.org/src/log/?h=3Dstable%2F13&qt=3Dgrep&q=3Dmerge&g= t; no
comparable merge to stable/13.


Correct. The chan= ge isn't in the branch stable/13 tracks.

Warner=C2=A0
--000000000000690c1705f96413a4-- From nobody Sat Apr 15 19:28:30 2023 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 4PzNds3SFhz44vkC for ; Sat, 15 Apr 2023 19:28:33 +0000 (UTC) (envelope-from grahamperrin@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 4PzNds0pzgz3L1j for ; Sat, 15 Apr 2023 19:28:33 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681586913; 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=rhzTu/Z/BZTnuFGg6TSaVjItshJ3ONg7YS1Cks+7U6o=; b=oj64z1AWkId9Z3PBbPsU3xjdAJ0ffOO+o2rmJb8uKC72amsXLCh1etHk460fpUo1jjht7q ErzkPk/01t8pvLHEOEvx6MYCv0ALkshksptbV+gSYqEX85FFSYG806JN0Blas8BVE7feTL kHrl1+0ipxcdRRoxKXapvdR8RFjc/r6Ba3BxlTj8zSWVIkKQX/FC9O84LU/nsXZrkzWz40 yJ4l+ye/wLbbSubfLpVWFbHNBcvWUZjsL/5Pkeyn1NtjAs0DPCLX7XUKQr8fwJMVe6cdG5 6mTcL9mFvowx5c9neo80OSYrlfhFcoDoQEsZb8BH1QBWqTcTirvCEhdfWL1yJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681586913; 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=rhzTu/Z/BZTnuFGg6TSaVjItshJ3ONg7YS1Cks+7U6o=; b=ilUwJWyCXdGRiuXfiWylf/2J6a7NqD5wo/hnb+NtLLgaiyB+KkddlKkoAss7d2BnbmhZPu 7BsgCip/M2Fedd53uoSBLTf0yStV82v1WeBrzKgsFda/rEsJdXvu51smIzLiBrihSon66+ rNBm7P2JMgjDaC3p69kw0gRpPYI9KPY6NGBTuDBHv+j8VHPJ440/hNtGqTngT06eyPUvGQ 30WMjXIAKq3rb+s1ncZtj3o8ABV40hzTVGtLAHTPz0FjJ+QslI9zJxigRM3oN5HSykUlJZ p+MotJcgcGEeHcZh/Vw/0udIcKVKiF5Vm8wydF8J39wHeQuGsmSmPwogKPAJ7g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681586913; a=rsa-sha256; cv=none; b=szEdBr6CA60llfAc2JWbJo4APrFRUULbvyl5zSIAEKgl/3R4nO/L794Q2NS35COGASNQpt LwU/JfB3q30WLn2CN2WRTT83CHfThIVL0ZZTlb+EshlDP1AoYVxY44ZDtYYgQQD7BZSy64 Y3q1zBllifBjKRXCcHHRfFzJf17c4LKUPE6xGS+46HGONXJyMOeAfILGZe2MXQ07Ot65M2 u2wVu+VGOiZXwCptb+kyeh5nWP51IpGDu8Ekaq0N6OWcTf4ur7Hj22e2H6StWgOVIrswvr veYNGFoTVi/CDWeZFKi1PDto9apgGLNQjplCS/cHEDyWuzpoZTuYDND5J6OCUQ== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (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: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PzNdr4yw8zkwy for ; Sat, 15 Apr 2023 19:28:32 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Sat, 15 Apr 2023 20:28:30 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!] Content-Language: en-US To: freebsd-current@freebsd.org References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> From: Graham Perrin Organization: FreeBSD In-Reply-To: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------27XE50kShBjzu6fq3XTn0tEg" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------27XE50kShBjzu6fq3XTn0tEg Content-Type: multipart/mixed; boundary="------------Ys0fbd1Hg4lNAZKzLH7Xq0Fz"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Message-ID: Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!] References: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7.ref@yahoo.com> <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> In-Reply-To: <2C2AB2E9-32B5-41D3-9A19-B8FEA6BA68F7@yahoo.com> --------------Ys0fbd1Hg4lNAZKzLH7Xq0Fz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQvMDQvMjAyMyAxMTo1OCwgTWFyayBNaWxsYXJkIHdyb3RlOg0KPiDigKYgemZzIGFm dGVyIHRoZSBpbXBvcnQgY29ycnVwdHMgZGF0YSBldmVuIHdpdGhvdXQgYmxvY2tfY2xvbmlu ZyBoYXZpbmcgZXZlciBiZWVuIGluIHVzZSwgZXZlbiBhcyB0aGUgY29kZSBjdXJyZW50bHkg aXMuIOKApg0KDQoNCjxodHRwczovL2dpdGh1Yi5jb20vb3Blbnpmcy96ZnMvcHVsbC8xMzM5 MiNpc3N1ZWNvbW1lbnQtMTUwNDIzOTEwMz4gDQooMjAyMy0wNC0xMikgZGlzY3Vzc2VzIHJl cG9ydGVkIGNvcnJ1cHRpb25zIHdoZW4gYmxvY2sgY2xvbmluZyB3YXMgDQpkaXNhYmxlZDsg IuKApiBOb3QgYSBkYXRhIGNvcnJ1cHRpb24gaW5zaWRlIFpGUy4g4oCmIi4NCg0KSFRIIChJ IGhhdmUgbm90IGZvbGxvd2VkIHRoZSBwYXJhbGxlbCBkaXNjdXNzaW9ucyBpbiBkZXB0aCkN Cg0K --------------Ys0fbd1Hg4lNAZKzLH7Xq0Fz-- --------------27XE50kShBjzu6fq3XTn0tEg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmQ6+t4FAwAAAAAACgkQt2dIb0oY1Aul /A/+IR1/Bp/D4Zz2qo87FWv05VnAn6Hy4zboRyrx90VXmG0KokzwLGk9V6rlDIq4N7f/UNQWDR0I Gdnr/oL0nY1JS+rHBUBmFPfYZoYjJqjzzHSjbEkOjfz4iNeKaef6dp0Bs1q1++WfIBtrl7ov2HyA M6F9yQYTYXXtdxGAK7kLzmgFvLunVAdg4qA1t1XaeXMu7nYTWhh/miBZb2szEVgGJ6IlMZJMCwZY FESB9X11FmeZJDjyDVAqMx+XwrClnrmwAwZxm0KiGRN9Og8/SsqjY46BWXicXUFLDxfkGYskHMev ACaQk65lpcenYrdbJISk+xII7Mx++Wjrf9Orlh13ViOCXv0B9EjcrpUnUtWo34vXc+qXQlIGsTlI Kpwx3P74xB9JwLLU6DVRQNPHy/DAVxhUCZUnxj/ZO4wEm0v8us8mtYp1P6r53RzgniGoNtfvLzao zE+rwRyTfC+Ah/AfxKJmvDwLcBDHN1WZ971QifDSE9Ohh6Ra2DztuwfoMNSVQATPYqU5rCZT4NeA wbEOGByE2V/lizbb2t/gQDgOxZlTwe6QpiiQWRuu3f1K8ARHP6/AdLQTfm8fEiBJeBczb+r2XqZN lUXvXbQpjkhXEdTUyHgQ8ziCCc86SOyyjNpT4P8X+eigFEfyhpvU2gWLG+5dplsonK76rcgy7cqn ls8= =+PtO -----END PGP SIGNATURE----- --------------27XE50kShBjzu6fq3XTn0tEg-- From nobody Sat Apr 15 20:25:56 2023 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 4PzPwR5d90z451HP for ; Sat, 15 Apr 2023 20:26:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4PzPwP4rRbz3wRp for ; Sat, 15 Apr 2023 20:26:13 +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=1681590372; bh=dzamcM83+dMvkGB+6hTezxhTVemFsAK40GYmtefBGso=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BZFJOgKBndDRvM8noHywJd2j81lTTJfbdmOW1vw+3ytVThpcupIjFJb7GOFDvy2VkRKluo+1w795Q81XFLqJrb/thoTHmkDYKLUhGzY5ixJmT6ssEZpvJEt5hMqRETEVkF8eOdECjpkx0JrVsvF1r2ss1ewCxb0LOFXo7J97Ti4xncdd+HAwbnu04gol5dRyFWRxrrV48sibLy14G65/jAU8YQ4XAA1IWT8MS3ZROqtsMJ/FUWbAK+rLlUFIbsd81usA4+CfC7RFqwWErqMf6GArwqF4UNexaNVvALEEw1qKcR3jUt0glFW4lK+6eyRD8UCrxlP1Ww5NWtN8FCL9ug== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681590372; bh=77zPJ87CMjHMihv9mGIcc5bygCMVuqX81GZdXWBfEC+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Zf0uRyRyHPzarARNjvuQDrtvBEXgTo0A881CjHMkau3CgwFO89sQzwZtny+zeRtsZ6RjhZQ4Fr06v2oUUgg9N5Umv61lYwozNMbAetn3pHr8dL9mwvOLe+TMc0hnV8RJN0aXdyDHqrFs8ZrSrAZhEkeIi1JV8RFv6JnH3R7UJeBI+tBJ3HC3UTuVPAN8v/U0Rhr4TBhIa201YFHjyZcFQD+Fsj9sMVDL59Rnl/G2iCIiqPWPfeE6aX3uYxByy/+q47wZZd69QylocslGIwrsVIH7alQYfSH+pMnQKSwremLJGt25aO90QpfbYRsrSePDaB2TdHb9e/QemhQIJb1oCA== X-YMail-OSG: k3TIrwAVM1nI59W9wUcQNSUpqWdgf3mdkM.cuYsue9VO.n4rhcxnfu6w9.jdJow Wg6XJUwQWGj0teCWQ0TrwyfA.QY6Xq14HsyjIizkQAbefinLAeifmqzkNteF8IGKqL5.jrcOme9L 7.EIOQ0ZN7Ig.OBYsjqI8EY1qtu1oKz0JznJWOSusfea63ib.tEPbKQnJFv9.5BOlJAsOzkLFQTY l._lMXeu84F1BBEoK83pBe5GfwXaG8nErvqC_CkFQFFhboLLcVPAEpk8P3zTSEyc9zjwMFuFbT_d Af4cfMNSnFcFABT4wmN9FdLap8FfbukqzdeASGhAGXgVuWVRxZQ_WCjpFdO7u04hLLr06.xoSusB LwT7cT7gSWVe_3GJl6QhdJ4Kj8YUluvO1JwOGvbqTtPkP..VxQbJ13VcBVWX1jJQaXodiJq8msHK bEV0.fxQR8l.KtlyhfyYLFhJXQprSCGcJL6o4N96y2JbiOi.q0ccw6bSBEwYR0ueswkRkotRwBLS ZyLsS1U7is_rxNLw9T9jxNdX9p0NaRSpK.9Osqt1.8fnLE7MTuACF0gqw60PdOJLR41aVITlTbeR pen_1MEXGXNqXgJ9Mwh3buAueJItun9gzoz4REbsWlKqoAusUEGvLnjGd5h5WGMDQPrRsfMOIcPP qARx9.akDFK0S2P1w1WwfYEKfRO8GKmCtGdqU_3YW7ns21YfNKB3p2g.8MqJDlwji4gnuK3gejkI SlRg_FBwF_8sSoo1P9gUR7FoG_J0xBq2hQYq8ip1u1ak.cIBQqSFNN9f1X0Pmi2sCozi1XnS5dYY 0QyGOqor54zNeKUXvhT1xTmqUoJdWACUbUwCUlF9gwnBfJ1V3jfQMBjSBHt8FK849ky4woq6OLax D4EeOkm8pQNfwCfcDUNAXg3Xg4w58z3z2Nv_M9GQNe0mtZHo_yySH6Lu_kDwbtH3XocDFPERaBXV 0D1Q2tcsh5WcCUJgF64.G7dZ13nmf0A5Y.5.mCNr5DEQBgxGcsYErU0YuAXirJGbjeE29R7wlnut jF82GOdIcOrjvcx3wBJc3jyz91ZUPTvZ9sH75NEsPQKBUUEFRRpRU2D.fEYE7LvlM4kJqE9i4Aks Nw.6nMpmO8oH22wqVxWQ9fOD5VMglLcg1lclnsjowD125xmlbtT.SDsuaa9Szb6iuesKKxqI2xmd ZfuuueQX3Ez3tlN9X5zU7fJjC9YHDF1TJ3SJXDA0Fzjy05a8vP5pXrqc_Ps_XVqoeCTViuxNw2sG ggbpb8Zm48Vqg42aogrJhr6s1rlIRe3lSmCQLHa8eRW0WE0y1OF10tI6oBKcOJhpHslJjsp2w4UK urNZ7mqbEgUkUndRtmuEGbGNMy3CpbMGc9mWRbvmEJjRiv1eqb4jhb6P58QyXFygj6JYqT7Ptykk hVzv5ie8sBnbh4mUIzOMLMluVLll0qMWeC98lgNn1EB3fZFR5HUXJFQJ9W5gxk7ulZd0f9ZU3fHc vHUZgjk1p1iWcz5HQCc.sLLk1hrStQWFrehe6cgI0uUrrNd0qzDNc8uoW3yXGh.nSGihPZ_59P8D ZrYNqDc_jHTzlHKp43gmOLiFZQZUQRn8Mfdzli6zzUUbjWBeEfm6q7a6X9Bjtf5YSCTpkqlimaWb zgb77Jm0QNG.aZPfxqIBOlbVIH7QUw9MV5dWbyMrlN3U328ZLrAEopdFd5RE8_mPGeU7TkfUaIY5 TpbwtgBABKeoUrTotaMXC0dKh3K3F140i8u6HKfQ_cLZf2KnhR9xI3c_Djgob0SEy60zdvmG1DgG nWEdZxS_rehJEUG0.YUMe4gwqHa_fE5idhSDP9KxnBcxuX9zcl8TcZ3uf7ird4Gosuwe6Z_Tfzx3 rhJZZyYQ4tD2rKV0ixavAdjRXUKuCHdu9ZNHoJdEUxrmvGEHfEqTmUWGbtMSfSnHtY66hOronRPa Qh3HGYeVt8NXArQ8S1aV4rNiq.SDIcGbvbJOhfq.LGn0XbcMjAV5iPu6fUWRU8xLgFftQe3lSl.1 .8boYXRm3P22Jp_F.grvQsNoea1J_wAzJNF4vjJGQis2.X5_UTS8eZRwqIxfONee.XvG6YnWmH0I 0MY5jmdSu.0DXTSC00Sg8Q3u99XvrbRmJqgSd2cYoe6aw8ZxqgbKeeT2WameKFuUp6hImNvaln4e m9.wlOaKkplJZS9Ju1qYzabStI33dh07zg1lDwn4i9W3gc4iqQT5GXmxreinriw36H68w5A8fE9T iS0T8gB1oCGGJbfSSiHxGfvxZDTPKfKm._AKIQozl78fNIxwXNqlpZQOMyiKcE8TjA7QliRx48w4 nBltgOOc- X-Sonic-MF: X-Sonic-ID: 1baa7b56-7719-49c5-b103-d876314db669 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Apr 2023 20:26:12 +0000 Received: by hermes--production-bf1-5f9df5c5c4-fgkgh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 240970ddb4e6aea88d95ffeaa746f9cd; Sat, 15 Apr 2023 20:26:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <20230415180720.AC396404@slippy.cwsent.com> Date: Sat, 15 Apr 2023 13:25:56 -0700 Cc: FreeBSD User , Charlie Li , Pawel Jakub Dawidek , Mateusz Guzik , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <7963CD10-C44A-4C4D-B760-FA6E0A053FA9@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <5A47F62D-0E78-4C3E-84C0-45EEB03C7640@yahoo.com> <20230415180720.AC396404@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PzPwP4rRbz3wRp X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 15, 2023, at 11:07, Cy Schubert = wrote: > In message <5A47F62D-0E78-4C3E-84C0-45EEB03C7640@yahoo.com>, Mark = Millard=20 > write > s: >> On Apr 15, 2023, at 07:36, Cy Schubert =3D >> wrote: >>=20 >>> In message = <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>,=3D20=3D >>=20 >>> FreeBSD Us >>> er writes: >>>> Am Thu, 13 Apr 2023 22:18:04 -0700 >>>> Mark Millard schrieb: >>>> =3D20 >>>>> On Apr 13, 2023, at 21:44, Charlie Li wrote: >>>>> =3D20 >>>>>> Mark Millard wrote: =3D20 >>>>>>> FYI: in my original report for a context that has never had >>>>>>> block_cloning enabled, I reported BOTH missing files and >>>>>>> file content corruption in the poudriere-devel bulk build >>>>>>> testing. This predates: >>>>>>> https://people.freebsd.org/~pjd/patches/brt_revert.patch >>>>>>> but had the changes from: >>>>>>> https://github.com/openzfs/zfs/pull/14739/files >>>>>>> The files were missing from packages installed to be used >>>>>>> during a port's build. No other types of examples of missing >>>>>>> files happened. (But only 11 ports failed.) =3D20 >>>>>> I also don't have block_cloning enabled. "Missing files" prior to = =3D >> brt_rev >>>> ert may actually >>>>>> be present, but as the corruption also messes with the file(1) =3D >> signature, >>>> some tools like >>>>>> ldconfig report them as missing. =3D20 >>>>> =3D20 >>>>> For reference, the specific messages that were not explicit >>>>> null-byte complaints were (some shown with a little context): >>>>> =3D20 >>>>> =3D20 >>>>> =3D3D=3D3D=3D3D> py39-lxml-4.9.2 depends on shared library: = libxml2.so - =3D >> not found >>>>> =3D3D=3D3D=3D3D> Installing existing package =3D >> /packages/All/libxml2-2.10.3_1.pkg =3D20 >>>>> [CA72_ZFS] Installing libxml2-2.10.3_1... >>>>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done >>>>> =3D3D=3D3D=3D3D> py39-lxml-4.9.2 depends on shared library: = libxml2.so - =3D >> found >>>>> (/usr/local/lib/libxml2.so) . . . >>>>> [CA72_ZFS] Extracting libxslt-1.1.37: .......... done >>>>> =3D3D=3D3D=3D3D> py39-lxml-4.9.2 depends on shared library: = libxslt.so - =3D >> found >>>>> (/usr/local/lib/libxslt.so) =3D3D=3D3D=3D3D> Returning to build = of =3D >> py39-lxml-4.9.2 =3D20 >>>>> . . . >>>>> =3D3D=3D3D=3D3D> Configuring for py39-lxml-4.9.2 =3D20 >>>>> Building lxml version 4.9.2. >>>>> Building with Cython 0.29.33. >>>>> Error: Please make sure the libxml2 and libxslt development = packages =3D >> are in >>>> stalled. >>>>> =3D20 >>>>> =3D20 >>>>> [CA72_ZFS] Extracting libunistring-1.1: .......... done >>>>> =3D3D=3D3D=3D3D> libidn2-2.3.4 depends on shared library: =3D >> libunistring.so - not found >>>> =3D20 >>>>> =3D20 >>>>> =3D20 >>>>> [CA72_ZFS] Extracting gmp-6.2.1: .......... done >>>>> =3D3D=3D3D=3D3D> mpfr-4.2.0,1 depends on shared library: = libgmp.so - not =3D >> found =3D20 >>>>> =3D20 >>>>> =3D20 >>>>> =3D3D=3D3D=3D3D> nettle-3.8.1 depends on shared library: = libgmp.so - not =3D >> found >>>>> =3D3D=3D3D=3D3D> Installing existing package = /packages/All/gmp-6.2.1.pkg =3D >> =3D20 >>>>> [CA72_ZFS] Installing gmp-6.2.1... >>>>> the most recent version of gmp-6.2.1 is already installed >>>>> =3D3D=3D3D=3D3D> nettle-3.8.1 depends on shared library: = libgmp.so - not =3D >> found =3D20 >>>>> *** Error code 1 >>>>> =3D20 >>>>> =3D20 >>>>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 >>>>> =3D20 >>>>> =3D20 >>>>> checking for GNU=3D20 >>>>> M4 that supports accurate traces... configure: error: no = acceptable =3D >> m4 coul >>>> d be found in >>>>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is =3D >> recommended. >>>>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems. >>>>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr = bug. >>>>> =3D20 >>>>> =3D20 >>>>> ld: error: /usr/local/lib/libblkid.a: unknown file type >>>>> =3D20 >>>>> =3D20 >>>>> =3D3D=3D3D=3D3D >>>>> Mark Millard >>>>> marklmi at yahoo.com >>>>> =3D20 >>>>> =3D20 >>>> =3D20 >>>> Hello=3D20 >>>> =3D20 >>>> whar is the recent status of fixing/mitigate this desatrous bug? =3D >> Especially f >>>> or those with the >>>> new option enabled on ZFS pools. Any advice? >>>> =3D20 >>>> In an act of precausion (or call it panic) I shutdown several = servers =3D >> to prev >>>> ent irreversible >>>> damages to databases and data storages. We face on one host with =3D >> /usr/ports r >>>> esiding on ZFS >>>> always errors on the same files created while staging (using =3D >> portmaster, leav >>>> es the system >>>> with noninstalled software, i.e. www/apache24 in our case). = Deleting =3D >> the work >>>> folder doesn't >>>> seem to change anything, even when starting a scrubbing of the = entire =3D >> pool (R >>>> AIDZ1 pool) - >>>> cause unknown, why it affects always the same files to be = corrupted. =3D >> Same wit >>>> h deve/ruby-gems. >>>> =3D20 >>>> Poudriere has been shutdown for the time being to avoid further =3D >> issues.=3D20 >>>> =3D20 >>>> Are there any advies to proceed apart from conserving the boxes via = =3D >> shutdown? >>>> =3D20 >>>> Thank you ;-) >>>> oh >>>> =3D20 >>>> =3D20 >>>> =3D20 >>>> --=3D20 >>>> O. Hartmann >>> =3D20 >>> With an up-to-date tree + pjd@'s "Fix data corruption when cloning =3D= >> embedded=3D20 >>> blocks. #14739" patch I didn't have any issues, except for email =3D >> messages=3D20 >>> with corruption in my sent directory, nowhere else. I'm still =3D >> investigating=3D20 >>> the email messages issue. IMO one is generally safe to run poudriere = =3D >> on the=3D20 >>> latest ZFS with the additional patch. >>=20 >> My poudriere testing failed when I tested such (14739 included), >> per what I reported, block_cloning never have been enabled. >> Others have also reported poudriere bulk build failures absent >> block_cloning being involved and 14739 being in place. My tests >> do predate: >>=20 >> https://people.freebsd.org/~pjd/patches/brt_revert.patch >=20 > IIRC this patch doesn't build. >=20 > My tree includes this patch. Pardon the cut&paste. This will not = apply. >=20 > diff --git a/sys/contrib/openzfs/module/zfs/dmu.c = b/sys/contrib/openzfs/modu > le/zfs/dmu.c985d833f58..cda1472a77aa 100644 > --- a/sys/contrib/openzfs/module/zfs/dmu.c > +++ b/sys/contrib/openzfs/module/zfs/dmu.c > @@ -2312,8 +2312,10 @@ dmu_brt_clone(objset_t *os, uint64_t object,=20 > uint64_t offset, uint64_t length, = dl->dr_overridden_by.blk_phys_birth =3D 0; > } else { > dl->dr_overridden_by.blk_birth =3D dr->dr_txg; > - dl->dr_overridden_by.blk_phys_birth =3D > - BP_PHYSICAL_BIRTH(bp); > + if (!BP_IS_EMBEDDED(bp)) { > + dl->dr_overridden_by.blk_phys_birth =3D > + BP_PHYSICAL_BIRTH(bp); > + } > } >=20 > mutex_exit(&db-=C2=B0=18=02=C2=93=1D>db_mtx); >=20 >>=20 >> and I'm not sure of if Cy's activity had brt_revert.patch in >> place or not. >=20 > I don't know if your poudriere has any residual file corruption or = not. I've only done the one test sequence that started from a context predating the import of the openzfs update. There was no prior corruption involved and no stage without the source fixes involved. > My=20 > poudriere working 100% ok and yours not indicates there may be = something=20 > amiss with your poudriere tree. The original media still predates the import and still is fine. The snapshot of the transfer state to the test media has no corruptions. > Remember I rolled back to the last nightly=20 > snapshot whereas you did not. You are confused: I had nothing to roll back as I started from pre-import and jumped in one step to a build that had the commits and 14739 with no intermediate steps. I then did the poudriere bulk for a jail that had no packages, one I use for temporary odd experiments that I clean out afterwards. Please quit attributing to my activities things that were not involved in my activites. It is likely confusing folks about what I'm reporting. I'll give a more detailed sequencing below, in case that helps. > I don't know the state of your poudriere=20 > tree. I know with 100% certainty that my tree is good. Remember my sequence for that (as reported before, but with a different presentation in case that helps): A) Start with root on ZFS media that predates the openzfs import. Note: This is a bectl context that looks like: # bectl list BE Active Mountpoint Space Created main-CA72 NR / 4.02G 2023-03-15 21:29 old-main-CA72 - - 1.82G 2023-03-01 17:25 (Lots of stuff is outside the BE's, so common to both.) It shows: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 B) Establish a copy of the normal media on a 2nd media. C) Use the 2nd media for all the following steps, leanving my normal environment alone. D) Update git and /usr/main-src/ worktree to: main-n262122-2ef2c26f3f13-dirty E) Also apply 14739. F) buildworld buildkernel G) Do a sequence that in overall effect deletes old-main-CA72 and renames main-CA72 to old-main-CA72 and has the installkernel installworld results in a (new) main-CA72. (This is a normal update result for me.) H) Boot the new main-CA72. It showed: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 = main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 (Taken from the report I made at the time.) I) Next I did the poudriere bulk run, for a jail with no packages present, even pkg needing to be built. That poudriere bulk run had the 11 failures, 252 successes and 213 skipped. It was based on USE_TMPF=3Ddata instead of, say, USE_TMPFS=3Dall . This was in order to be sure there was more file system activity. (I'd not be surprised of USE_TMPFS=3Dall would have finished fine because of having far less zfs I/O involved.) An odd aspect that may be relevant: I do bulk builds in a manor that at times can have 100+ for one or more of the 3 load averages --on a system with just 16 cores (16 hardware threads). (I do not have specific maximum observed load average figures for the specific bulk run. But I could set up a retest and get such if desired. I use a modified top to get the "MaxObs" figures.) At no point in that sequence is a rollback relevant! Please quit assuming that I had ever built, installed, or booted something from a middle time frame compared to what I've explicitly reported. I did not, as I've reported multiple times. But you seem to forget or not believe such each time. >>=20 >> Other's notes include Mateusz Guzik's: >>=20 >> =3D >> = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014534.= =3D >> html >=20 > My tree included this patch + pjd@'s last patch on people.freebsd.org. >>=20 >> which said: >>=20 >> QUOTE >> There is corruption with the recent import, with the >> https://github.com/openzfs/zfs/pull/14739/files patch applied and >> block cloning disabled on the pool. >=20 > I had zero poudriere corruption with this patch. But I did. > My only corruption was in=20 > my sent-items in my MH mail directory, which I think was due to email=20= > threads already containing nulls. >=20 >>=20 >> There is no corruption with top of main with zfs merge reverted =3D >> altogether. >>=20 >> Which commit results in said corruption remains to be seen, a variant >> of the tree with just block cloning support reverted just for testing >> purposes is about to be evaluated. >> END QUOTE >>=20 >> Charlie Li's later related notes that helps interpret that were in: >>=20 >> =3D >> = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014545.= =3D >> html >>=20 >> QUOTE >> Testing with mjg@ earlier today revealed that block_cloning was not = the=3D20=3D >>=20 >> cause of poudriere bulk build (and similar cp(1)/install(1)-based)=3D20= >> corruption, although may have exacerbated it. >> END QUOTE >>=20 >> Mateusz later indicated had a hope to have is sorted out sometime >> Friday for what the cause(s) were: >>=20 >> =3D >> = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014551.= =3D >> html >>=20 >> QUOTE >> I'm going to narrow down the non-blockcopy corruption after my = testjig >> gets off the ground. >>=20 >> Basically I expect to have it sorted out on Friday. >> END QUOTE >>=20 >> But the lack of later related messages suggests that did not happen. >>=20 >>> My tests of the additional patch >>=20 >> (I'm guessing that is a reference to 14739, not to brt_revert.patch = .) >>=20 >>> concluded that it resolved my last=3D20 >>> problems, except for the sent email problem I'm still investigating. = =3D >> I'm=3D20 >>> sure there's a simple explanation for it, i.e. the email thread = was=3D20 >>> corrupted by the EXDEV regression which cannot be fixed by anything, = =3D >> even=3D20 >>> reverting to the previous ZFS -- the data in those files will = remain=3D20=3D >>=20 >>> damaged regardless. >>=20 >> Again: my test jump from prior to the import to after the EXDEV >> changes, including having 14739. I still had poudriere bulk >> produce file corruptions. >>=20 >>> I cannot speak to the others who have had poudriere and other = issues. =3D >> I=3D20 >>> never had any problems with poudriere on top of the new ZFS. >>=20 >> Part of the mess is the variability. As I remember, I had 252 >> ports build fine in my test before the 11th failure meant that >> the rest (213) had all been classified as skipped. >>=20 >> It is not like most of the port builds failed: relatively uncommon. >>=20 >> Also, one port built on a retry, indicating random/racy behavior >> is involved. (The original failure was not from a file from >> installing build dependencies but something that the builder >> generated during the build. The 2nd try did not fail there or >> anywhere.) >>=20 >>> WRT reverting block_cloning pools to without, your only option is to = =3D >> backup=3D20 >>> your pool and recreate it without block_cloning. Then restore your =3D= >> data. >>> =3D20 >>=20 >> Given what has been reported by multiple people and >> Cy's own example of unexplained corruptions in email >> handling, I'd be cautious risking important data >> until reports from testing environment activity >> consistently report not having corruptions. >=20 > The "unexplained" email corruptions occurred in only the threads that=20= > already had corruption. Good to know. > I haven't been able to reproduce it anywhere else.=20 > I will continue testing on Monday. I expect my testing to confirm this=20= > hypothesis. Your evidence can not cancel what I and others have reported. It is just more evidence of observed variability (that is, as, yet, unexplained as far as I know). >> Another thing my activity does not include any testing >> of the suggestion in: >>=20 >> =3D >> = https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014607.= =3D >> html >>=20 >> to use "-o sync=3D3Ddisabled" in a clone, reporting: >=20 > This is a different issue. We need a core dump to resolve this. I'll = test=20 > this on my sandbox on Monday. >=20 > We can now reproduce this panic by hand. My sequence has appearently avoided what leads to panics so my only contribution to evidence about them is the lack of getting any panics for my sequence. > If there is no panic a diff -qr=20 > will confirm/deny this bug. Up to possible lack of reproducible builds for the activity done on the clone? Some files might be expected to be different if I understand the sequence that was being suggested. >>=20 >> QUOTE >> With this workaround I was able to build thousands of packages = without=3D20=3D >>=20 >> panics or failures due to data corruption. >> END QUOTE >>=20 >> If reliable, that consequence to the change might help >> folks that are trying to isolate the problem(s) figure >> out what is involved. >>=20 >> =3D3D=3D3D=3D3D >> Mark Millard >> marklmi at yahoo.com >=20 > IMO we've had a lack of systematic testing of the various bugs. What about my sequence would be an example of lack of being systematic? > The fact=20 > that this has caused some corrupt files has led to human panic over = the=20 > issue. I've no personal panic: the only context with the corruptions for me was a specially created context to test to see if I'd get corruption based on what was commited at the time (+1 separate patch). My standard/normal environment still predates the import of the openzfs update and has no problems. > Now that I've reverted my laptop to the old ZFS, the MH sent-email = issue=20 > continues to exhibit itself. This is because the files I forward to = myself=20 > already contain corrupt data. The old ZFS will not magically remove = this.=20 > This testing is necessary to prove my hypothesis. I expect brand new = email=20 > threads not to exhibit this problem with the new ZFS. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 15 20:30:13 2023 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 4PzQ144xkFz451J2; Sat, 15 Apr 2023 20:30:16 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (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 4PzQ140t2Xz44jc; Sat, 15 Apr 2023 20:30:16 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-1879edfeff5so8940048fac.4; Sat, 15 Apr 2023 13:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681590615; x=1684182615; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XS26ZCFyDqYHCZnay/VuIVQSOWVO9Vx56anBOmfV3Zw=; b=BVjYLBoh5FrR4HYd9jgz/LjZAi7o4MhGeyjqiHPylrUmZRVX5XPnC55MvmasK7uAYQ ufgnldYL3RYwAnQzb0mR5dn9XaCX+Ga6a1paW1QGOwSGyegd9tww7lJhvLS4+p2IKvef JvfFcZ0gFvCVkweEAXu8n02eQa81+nJzHkHjDJnAX0gOOEcAwW98Vn0Z9t5YfRGLlO5R gZv4mqDh6hW/Tjn1S87hGbytv8lB3ZwDpUrNHg7PchJabCZ2mnjFXZH1RChfSGNw0D3B VPoLbVoMDcEzAGUcbJS+QmGt1ZWlYegmxwX2HjKLNNMK3yFbzyyXcdoEGN7Fm/es4JIb xRPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681590615; x=1684182615; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XS26ZCFyDqYHCZnay/VuIVQSOWVO9Vx56anBOmfV3Zw=; b=I4ROf5/y4OjmSlDkMIluy1mYbEqlQyFZfuae88plZ7yrbdegCh25bUJTqznZaPJDDo 374CHN8cXGllN/nQug/m4JRIjf1ylEiJje6/556NS6HzKmzpNfVNhbm3/9WEmopXFqRh L0Ceq2hlKUOLZe788m1JJojViPPHkI1cZV6GHuSBfSIjYBix9w1RD+W/czHFevipnupd WDAzv63pX3uI+ER6nEtLc4uIsAlzT3tD4Iki7hfM9UiF6U/alfC6M49sKfUJ9ijbS7OC QMf3799+2ETkoV0cTn4cmWOuo4QqU9n+AS2m9ytjESIz8O0+oCK0cG2/YbrWYY4Q7tNQ adfw== X-Gm-Message-State: AAQBX9dLgW+Gxch7N5tkdQTiufTh8qx92Xlsiz+yjIRgSc0vvry/HhAC htAQI9nQSGi+bNXDD7SThRWGU/HoPVlK/hDGWi0= X-Google-Smtp-Source: AKy350Zfd8XaGMQzhrASWvIcu8ZWBisEHr+qKOnRZlwkPZ80jf06/q4tYfdYxibFFBphsWAftliSVUEBXEZrhcv2Z94= X-Received: by 2002:a05:6870:46ab:b0:184:1a2c:83df with SMTP id a43-20020a05687046ab00b001841a2c83dfmr4702330oap.4.1681590614721; Sat, 15 Apr 2023 13:30:14 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:a8a:46:0:b0:49c:b071:b1e3 with HTTP; Sat, 15 Apr 2023 13:30:13 -0700 (PDT) In-Reply-To: <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> From: Mateusz Guzik Date: Sat, 15 Apr 2023 22:30:13 +0200 Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: FreeBSD User Cc: Cy Schubert , Mark Millard , Charlie Li , Pawel Jakub Dawidek , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4PzQ140t2Xz44jc X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/15/23, FreeBSD User wrote: > Am Sat, 15 Apr 2023 07:36:25 -0700 > Cy Schubert schrieb: > >> In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>, >> FreeBSD Us >> er writes: >> > Am Thu, 13 Apr 2023 22:18:04 -0700 >> > Mark Millard schrieb: >> > >> > > On Apr 13, 2023, at 21:44, Charlie Li wrote: >> > > >> > > > Mark Millard wrote: >> > > >> FYI: in my original report for a context that has never had >> > > >> block_cloning enabled, I reported BOTH missing files and >> > > >> file content corruption in the poudriere-devel bulk build >> > > >> testing. This predates: >> > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch >> > > >> but had the changes from: >> > > >> https://github.com/openzfs/zfs/pull/14739/files >> > > >> The files were missing from packages installed to be used >> > > >> during a port's build. No other types of examples of missing >> > > >> files happened. (But only 11 ports failed.) >> > > > I also don't have block_cloning enabled. "Missing files" prior to >> > > > brt_rev >> > ert may actually >> > > > be present, but as the corruption also messes with the file(1) >> > > > signature, >> > some tools like >> > > > ldconfig report them as missing. >> > > >> > > For reference, the specific messages that were not explicit >> > > null-byte complaints were (some shown with a little context): >> > > >> > > >> > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not >> > > found >> > > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg >> > > >> > > [CA72_ZFS] Installing libxml2-2.10.3_1... >> > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done >> > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found >> > > >> > > (/usr/local/lib/libxml2.so) . . . >> > > [CA72_ZFS] Extracting libxslt-1.1.37: .......... done >> > > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found >> > > >> > > (/usr/local/lib/libxslt.so) ===> Returning to build of >> > > py39-lxml-4.9.2 >> > > . . . >> > > ===> Configuring for py39-lxml-4.9.2 >> > > Building lxml version 4.9.2. >> > > Building with Cython 0.29.33. >> > > Error: Please make sure the libxml2 and libxslt development packages >> > > are in >> > stalled. >> > > >> > > >> > > [CA72_ZFS] Extracting libunistring-1.1: .......... done >> > > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not >> > > found >> > >> > > >> > > >> > > [CA72_ZFS] Extracting gmp-6.2.1: .......... done >> > > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found >> > > >> > > >> > > >> > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found >> > > ===> Installing existing package /packages/All/gmp-6.2.1.pkg >> > > [CA72_ZFS] Installing gmp-6.2.1... >> > > the most recent version of gmp-6.2.1 is already installed >> > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found >> > > >> > > *** Error code 1 >> > > >> > > >> > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 >> > > >> > > >> > > checking for GNU >> > > M4 that supports accurate traces... configure: error: no acceptable m4 >> > > coul >> > d be found in >> > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is >> > > recommended. >> > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. >> > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. >> > > >> > > >> > > ld: error: /usr/local/lib/libblkid.a: unknown file type >> > > >> > > >> > > === >> > > Mark Millard >> > > marklmi at yahoo.com >> > > >> > > >> > >> > Hello >> > >> > whar is the recent status of fixing/mitigate this desatrous bug? >> > Especially f >> > or those with the >> > new option enabled on ZFS pools. Any advice? >> > >> > In an act of precausion (or call it panic) I shutdown several servers to >> > prev >> > ent irreversible >> > damages to databases and data storages. We face on one host with >> > /usr/ports r >> > esiding on ZFS >> > always errors on the same files created while staging (using portmaster, >> > leav >> > es the system >> > with noninstalled software, i.e. www/apache24 in our case). Deleting the >> > work >> > folder doesn't >> > seem to change anything, even when starting a scrubbing of the entire >> > pool (R >> > AIDZ1 pool) - >> > cause unknown, why it affects always the same files to be corrupted. >> > Same wit >> > h deve/ruby-gems. >> > >> > Poudriere has been shutdown for the time being to avoid further issues. >> > >> > >> > Are there any advies to proceed apart from conserving the boxes via >> > shutdown? >> > >> > Thank you ;-) >> > oh >> > >> > >> > >> > -- >> > O. Hartmann >> >> With an up-to-date tree + pjd@'s "Fix data corruption when cloning >> embedded >> blocks. #14739" patch I didn't have any issues, except for email messages >> >> with corruption in my sent directory, nowhere else. I'm still >> investigating >> the email messages issue. IMO one is generally safe to run poudriere on >> the >> latest ZFS with the additional patch. >> >> My tests of the additional patch concluded that it resolved my last >> problems, except for the sent email problem I'm still investigating. I'm >> sure there's a simple explanation for it, i.e. the email thread was >> corrupted by the EXDEV regression which cannot be fixed by anything, even >> >> reverting to the previous ZFS -- the data in those files will remain >> damaged regardless. >> >> I cannot speak to the others who have had poudriere and other issues. I >> never had any problems with poudriere on top of the new ZFS. >> >> WRT reverting block_cloning pools to without, your only option is to >> backup >> your pool and recreate it without block_cloning. Then restore your data. >> >> > > All right, I interpret the answer that way, that I need a most recent source > tree (and > accordingly built and installed OS) AND a patch that isn't officially > commited? > > On a box I'm with: > > FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST > 2023 amd64 > > The box is crashing while trying to update ports with the well known issue: > > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > At the moment all alarm bells are ringing and I lost track about what has > been patched and > already commited and what is still as patch available but in the phase of > evaluation or > inofficially emmited here. > > According to the EXDEV issue: in cases of poudriere or ports trees on ZFS, > what do I have to > do to ensure that those datasets are clean? The OS should detect file > corruption but in my > case the box is crashing :-( > > I did several times scrubbing, but this seems to be the action of a helpless > and desperate man > ... ;-/ > > Greetings > Using block cloning is still not safe, but somewhere in this thread pjd had a patch to keep it operatinal for already cloned files without adding new ones. Anyhow, as was indicated by vishwin@ there was data corruption *unrelated* to block cloning which also came with the import, I narrowed it down: https://github.com/openzfs/zfs/issues/14753 That said now I'm testing a kernel which does not do block cloning and does not have the other problematic commit, we will see if things work. -- Mateusz Guzik From nobody Sat Apr 15 22:33:28 2023 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 4PzSlW1LKTz45Cp6 for ; Sat, 15 Apr 2023 22:33:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4PzSlV5DNBz4LVw for ; Sat, 15 Apr 2023 22:33:42 +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=1681598020; bh=85V/PKGt5V5ybBJVyXh4zGi5ejYzsZ5Py6tHUoKxHWM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qkCMbKqUYSd0JRDdE8/3UQwImGwSHh8LGIQxsAvVndBYw07FQBi6HSjwdg1FYORRwBRi513udmynKHF3o4Me/maXiRaedX9hQrCDcdFneGgUpLB8rf9cQEVolS7BebBvPQ4Rc9izastpFlZtpkfKLzXRo1cMqEPIDYAkk7zvpJ47EZKXhFb0Ha+rO0f+nc+m0SnE5dZHj6Gd+iGdfmsiYgKKcMmRnXXh/W6MujOjfjHRQruxc2kdc+fU0xnasX/JX8TQVS7lIHWwV1B5NhdoEq0MhOAhd7UfhWHIRnexwVjDQw0hRuoxmH7PnApCmJ4dL7iM1Ri/wN/Mzyd8TGqECA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681598020; bh=V1rYuhG5LZGX+IFHbptqLYGLMlX+3GwKW1WCNi76rvB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D9ZWEylAt7Q+0jArUGqg/GczR4vH5eprgPxt2EoYFdqlx9aPZ5aoB8QLZe+mIqQWTufOKomGWVR0Cl+ZJKCCrTCV2ZqHhsZAlxbVE50B7vapDOjqMmH1wKoWNkuD0e2NltDe3810Q+vsD158ZdIkeusD982HpVxOXg+K5IvUg9SLlML8MHZ3yyJcLbQoKmn6Edl3A7B/x2BFt0HOSdO6UuGCE2U1PfF5IhqdE6Jlp2dwSzDfEhAoD3ofvnu085FqfKhiPPwY7LixkjbbKfcnQOkUFwWRI2F5bevcDvQV2R2vKXZUwp2a9HEtRutYBMZJiIPMF9jHvk+ZYqJyHkCDpw== X-YMail-OSG: Nl6NyXkVM1kCO1iXCPjap0sJBNinSVHph7LOWnR6371MSjwjg0KjZ_rlv.cCPET aIr5N9bnCKtvbrf1afeQ5mBYTlAgzYTct7_6lGm14RirykjpVwyk73mOan.Yii8LlOUbrKoqfUCf b9JmS3pthmNecK9XBs7fSFvaRXDTdJvjCYFg8RVBT4evmUqgut_aMOQzUzhhjNiqoSxXXH40a3kv pT3QIP6Z6gE5pC.B.4Lp.J6VcH3N.czNVq72h3VSt1V_aFDZ9uL7jh3H0pxSuX07GYgVCGlfdklf nl310M4Dt8WR6obC5B3qHVZK_89ak5pmNOPM0_w8zIFRu4RpndlQSfIQ4brRp37D2UuOr2mRsCwu LGRtvjr3Bt4.pH4_rUUkziibKZnY07gGQEV8tpKiogjPgW19ZoqR.ZphIV9hibEsY62OeT2SVBaJ cy6_iVhdACUGETScuB.V6ivhk0hNQbeuN67XIuHq0RcwwYdBM5Mu7Xz91G4jamBf0DLdE3NoF56i ZJnLJykzuI.a5I1H1qT8LAWRFB0qvhd4VZI3gkVzc1gE0HEALlzVWfV9Gah7X2NQjQexw3UN4_Jr 6ofWsT5x43zmMS0vkJF0SiwWhXHFjB_i8M76EssE7CCUfBl598KdzCwGHjFKkkH4dBfomYmzgzY. bNogiot4QSjkjrt1Aq6A4LuAMFrfknw4EwwcpsZpXMi0EsPphLIG6G.minKsjjhkeogAzu1Jc03a YaomoGJXeoLmV7E02LJoGPuGNJRLfmRCfGNni6dCm2dw1qmzMpGTEmCZbQ5aDQztDO98_ANx.v3o zH5WHP4SSZUVaP_2IqcJu3SQGj1tRrzungIJQmHc_Pd8agUZJTa1yqXbFBmTE_OUh1viIhTcdveG PbVN8ts_BTh41CtZVWjoJ5MqwY1WipwKzOG3vb6jKnOukxB9RLnXUYFkJB3O8wftOzi4aAtEtDSL hGHPuE.0K9lnUuubjseRg5dGRrtVA4CsytgYiQ_MGG44c8Pf4hO6SUyervRbR64pksDIKYRpiC7Z VqX3vgh.3yb46QYVIp1WofjPC2Za3nmYXyVVMtwRs0nqWv_EfY4Zrj05mZlCe2OOVVMypH15B0ld 3ffKM5gwZUjpfXVCpc7NeRiTHAopXBsMoao4r80zxpQb5N8ePjMBuDs1ZxwO5C8ObKWMHFLn86dO WEa5QcKs3awuuJ7AodAa9KEsLcQ1e.C8LIzKUn7u9I3Z0PmCrWk9rwf4.rNQsKnojdRZaNotBCz7 u86bCPXmd7fwsxVdNAC67oDRgPQNO3bbFpnci6ADAe_Unno80H.7kT81rGhytjxi99bSs178lyR_ zhXTjUclVdBHLm46a25rSRZbuJgQxdBNDUOUBjjYIBrjD1KuNNJv5RfM6dRhuURlkfrI1cEWs3Vp f11QEiWkTQP9LmZ1s.CjPoQRD.wSxG.TNiCZ4o26K0JSIsToIpQCM.rw.pcsLLTM7r7yW8bliHK5 WvMCzgz0vEJAXET94ezP6c8GbuL0OPlKPmXeIjZJtmpvfYQ8LS8omHcfmATjdGUW_vY03Gf_F98P ENRNCs29mINmuhrXJanp8ZsQRjbr7jRrp2veale7AtlBZTku9RRyK.shepi73GnzLwVawIm90PDO TeiYULu2rH_VJrY3Geg8HahCF38_Njk2FTLJ_.7gOBhgWWVmtP.POpCGe6IwG0fBdIOePg77l2AO M1uBhqxBcx20JurPM78d_nRG9CTyohz6WxxnE_3Q70pVFKkaFy6pE8U_auwSHgovM40QyhbeE8v5 a9n37IzqbyzswH6c7dOJIkOd9Hqo1ZGII64wQ4ChNyqUyn5xeX0uht6wG4EhoZ2EgCX94DiYgxws 1Kxa.7NK7T65uO08tHFsTKCpP3gfxOMqUGmxFjBYyeAGoyy8VDI60ckMvbeJg8DONLZQpU2SprqB 9aNT7P5ikXXoU7u_Pu0Wri0CAoyXQaCcPj3B1Bi87G7boHB9YenvbWVTf2nj8p.irbuqgyUJmaXo icXBJ7gSbtpta.t4zerHPRwIgVOASB2gKVJ5nbt.g9JAAjaz0QS2qG9x1TO9WFKuNasS1oPzVB_k nt..86AexyWeUpVYkYI6vIu.bFbFF8HP_hij7GwRpnLpQoSHelw8JLUdWR4uc9TwHwWP9PnJIdqF kGx_kbds8BbsjsvpCjWhreVTWbG2UE.WT606Z5R358clsg8hKxZTMgJijDqerrmf3opYiZnQr2xE 2VkVHo8atpphPPrUNi.VoOu.rW1lkDf0xJOfyHE_KaobcrIwL0XWst.MTd0NDuviPcGdEZe6Mrso P6l0oU2OF X-Sonic-MF: X-Sonic-ID: 4ae83902-7143-49cd-a613-dd893f24f2d4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Apr 2023 22:33:40 +0000 Received: by hermes--production-gq1-546798879c-sq6s2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d9a580fb6ff9402335a56291fba522ef; Sat, 15 Apr 2023 22:33:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: Date: Sat, 15 Apr 2023 15:33:28 -0700 Cc: FreeBSD User , Cy Schubert , Charlie Li , Pawel Jakub Dawidek , dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <62F8DD62-8E09-4A07-926B-5DE3DB399609@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <20230413063321.60344b1f@cschubert.com> <20230413135635.6B62F354@slippy.cwsent.com> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> To: Mateusz Guzik X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PzSlV5DNBz4LVw X-Spamd-Bar: ---- 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] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 15, 2023, at 13:30, Mateusz Guzik wrote: > On 4/15/23, FreeBSD User wrote: >> Am Sat, 15 Apr 2023 07:36:25 -0700 >> Cy Schubert schrieb: >>=20 >>> In message <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de>, >>> FreeBSD Us >>> er writes: >>>> Am Thu, 13 Apr 2023 22:18:04 -0700 >>>> Mark Millard schrieb: >>>>=20 >>>>> On Apr 13, 2023, at 21:44, Charlie Li wrote: >>>>>=20 >>>>>> Mark Millard wrote: >>>>>>> FYI: in my original report for a context that has never had >>>>>>> block_cloning enabled, I reported BOTH missing files and >>>>>>> file content corruption in the poudriere-devel bulk build >>>>>>> testing. This predates: >>>>>>> https://people.freebsd.org/~pjd/patches/brt_revert.patch >>>>>>> but had the changes from: >>>>>>> https://github.com/openzfs/zfs/pull/14739/files >>>>>>> The files were missing from packages installed to be used >>>>>>> during a port's build. No other types of examples of missing >>>>>>> files happened. (But only 11 ports failed.) >>>>>> I also don't have block_cloning enabled. "Missing files" prior to >>>>>> brt_rev >>>> ert may actually >>>>>> be present, but as the corruption also messes with the file(1) >>>>>> signature, >>>> some tools like >>>>>> ldconfig report them as missing. >>>>>=20 >>>>> For reference, the specific messages that were not explicit >>>>> null-byte complaints were (some shown with a little context): >>>>>=20 >>>>>=20 >>>>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so = - not >>>>> found >>>>> =3D=3D=3D> Installing existing package = /packages/All/libxml2-2.10.3_1.pkg >>>>>=20 >>>>> [CA72_ZFS] Installing libxml2-2.10.3_1... >>>>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .......... done >>>>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxml2.so = - found >>>>>=20 >>>>> (/usr/local/lib/libxml2.so) . . . >>>>> [CA72_ZFS] Extracting libxslt-1.1.37: .......... done >>>>> =3D=3D=3D> py39-lxml-4.9.2 depends on shared library: libxslt.so = - found >>>>>=20 >>>>> (/usr/local/lib/libxslt.so) =3D=3D=3D> Returning to build of >>>>> py39-lxml-4.9.2 >>>>> . . . >>>>> =3D=3D=3D> Configuring for py39-lxml-4.9.2 >>>>> Building lxml version 4.9.2. >>>>> Building with Cython 0.29.33. >>>>> Error: Please make sure the libxml2 and libxslt development = packages >>>>> are in >>>> stalled. >>>>>=20 >>>>>=20 >>>>> [CA72_ZFS] Extracting libunistring-1.1: .......... done >>>>> =3D=3D=3D> libidn2-2.3.4 depends on shared library: = libunistring.so - not >>>>> found >>>>=20 >>>>>=20 >>>>>=20 >>>>> [CA72_ZFS] Extracting gmp-6.2.1: .......... done >>>>> =3D=3D=3D> mpfr-4.2.0,1 depends on shared library: libgmp.so - = not found >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - = not found >>>>> =3D=3D=3D> Installing existing package = /packages/All/gmp-6.2.1.pkg >>>>> [CA72_ZFS] Installing gmp-6.2.1... >>>>> the most recent version of gmp-6.2.1 is already installed >>>>> =3D=3D=3D> nettle-3.8.1 depends on shared library: libgmp.so - = not found >>>>>=20 >>>>> *** Error code 1 >>>>>=20 >>>>>=20 >>>>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 >>>>>=20 >>>>>=20 >>>>> checking for GNU >>>>> M4 that supports accurate traces... configure: error: no = acceptable m4 >>>>> coul >>>> d be found in >>>>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is >>>>> recommended. >>>>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems. >>>>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr = bug. >>>>>=20 >>>>>=20 >>>>> ld: error: /usr/local/lib/libblkid.a: unknown file type >>>>>=20 >>>>>=20 >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> marklmi at yahoo.com >>>>>=20 >>>>>=20 >>>>=20 >>>> Hello >>>>=20 >>>> whar is the recent status of fixing/mitigate this desatrous bug? >>>> Especially f >>>> or those with the >>>> new option enabled on ZFS pools. Any advice? >>>>=20 >>>> In an act of precausion (or call it panic) I shutdown several = servers to >>>> prev >>>> ent irreversible >>>> damages to databases and data storages. We face on one host with >>>> /usr/ports r >>>> esiding on ZFS >>>> always errors on the same files created while staging (using = portmaster, >>>> leav >>>> es the system >>>> with noninstalled software, i.e. www/apache24 in our case). = Deleting the >>>> work >>>> folder doesn't >>>> seem to change anything, even when starting a scrubbing of the = entire >>>> pool (R >>>> AIDZ1 pool) - >>>> cause unknown, why it affects always the same files to be = corrupted. >>>> Same wit >>>> h deve/ruby-gems. >>>>=20 >>>> Poudriere has been shutdown for the time being to avoid further = issues. >>>>=20 >>>>=20 >>>> Are there any advies to proceed apart from conserving the boxes via >>>> shutdown? >>>>=20 >>>> Thank you ;-) >>>> oh >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> O. Hartmann >>>=20 >>> With an up-to-date tree + pjd@'s "Fix data corruption when cloning >>> embedded >>> blocks. #14739" patch I didn't have any issues, except for email = messages >>>=20 >>> with corruption in my sent directory, nowhere else. I'm still >>> investigating >>> the email messages issue. IMO one is generally safe to run poudriere = on >>> the >>> latest ZFS with the additional patch. >>>=20 >>> My tests of the additional patch concluded that it resolved my last >>> problems, except for the sent email problem I'm still investigating. = I'm >>> sure there's a simple explanation for it, i.e. the email thread was >>> corrupted by the EXDEV regression which cannot be fixed by anything, = even >>>=20 >>> reverting to the previous ZFS -- the data in those files will remain >>> damaged regardless. >>>=20 >>> I cannot speak to the others who have had poudriere and other = issues. I >>> never had any problems with poudriere on top of the new ZFS. >>>=20 >>> WRT reverting block_cloning pools to without, your only option is to >>> backup >>> your pool and recreate it without block_cloning. Then restore your = data. >>>=20 >>>=20 >>=20 >> All right, I interpret the answer that way, that I need a most recent = source >> tree (and >> accordingly built and installed OS) AND a patch that isn't officially >> commited? >>=20 >> On a box I'm with: >>=20 >> FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 = 07:57:16 CEST >> 2023 amd64 >>=20 >> The box is crashing while trying to update ports with the well known = issue: >>=20 >> Panic String: VERIFY(!zil_replaying(zilog, tx)) failed >>=20 >> At the moment all alarm bells are ringing and I lost track about what = has >> been patched and >> already commited and what is still as patch available but in the = phase of >> evaluation or >> inofficially emmited here. >>=20 >> According to the EXDEV issue: in cases of poudriere or ports trees on = ZFS, >> what do I have to >> do to ensure that those datasets are clean? The OS should detect file >> corruption but in my >> case the box is crashing :-( >>=20 >> I did several times scrubbing, but this seems to be the action of a = helpless >> and desperate man >> ... ;-/ >>=20 >> Greetings >>=20 >=20 > Using block cloning is still not safe, but somewhere in this thread > pjd had a patch to keep it operatinal for already cloned files without > adding new ones. >=20 > Anyhow, as was indicated by vishwin@ there was data corruption > *unrelated* to block cloning which also came with the import, I > narrowed it down: https://github.com/openzfs/zfs/issues/14753 >=20 > That said now I'm testing a kernel which does not do block cloning and > does not have the other problematic commit, we will see if things > work. (Mostly written as I progressed but some material later inserted into/around previously written material.) Summary: As stands, it looks like reverting the dnode_is_dirty code is what fixes the corruptions that my type of test context produced via poudriere bulk activity . The details that lead to that summary . . . Using my my build environment for updating my temporary, experimental context, an environment running a world and and kernel that predate the import: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 (Note the "nondbg": I normally run non-debug main builds, but with symbols not stripped.) The kernel and world for this are what is in old-main-CA72: # bectl list BE Active Mountpoint Space Created main-CA72 R - 3.98G 2023-04-12 20:29 old-main-CA72 N / 1.08M 2023-02-06 19:44 (Most everything else is outside the BE's and so is shared across the BE's.) I updated to also have (whitespace details likely not preserved in this note): # git -C /usr/main-src/ diff = /usr/main-src/sys/contrib/openzfs/module/zfs/dnode.c diff --git a/sys/contrib/openzfs/module/zfs/dnode.c = b/sys/contrib/openzfs/module/zfs/dnode.c index 367bfaa80726..49a7f59c0da4 100644 --- a/sys/contrib/openzfs/module/zfs/dnode.c +++ b/sys/contrib/openzfs/module/zfs/dnode.c @@ -1772,17 +1772,7 @@ dnode_is_dirty(dnode_t *dn) { mutex_enter(&dn->dn_mtx); for (int i =3D 0; i < TXG_SIZE; i++) { - list_t *list =3D &dn->dn_dirty_records[i]; - for (dbuf_dirty_record_t *dr =3D list_head(list); - dr !=3D NULL; dr =3D list_next(list, dr)) { - if (dr->dr_dbuf =3D=3D NULL || - (dr->dr_dbuf->db_blkid !=3D DMU_BONUS_BLKID = && - dr->dr_dbuf->db_blkid !=3D DMU_SPILL_BLKID)) = { - mutex_exit(&dn->dn_mtx); - return (B_TRUE); - } - } - if (dn->dn_free_ranges[i] !=3D NULL) { + if (multilist_link_active(&dn->dn_dirty_link[i])) { mutex_exit(&dn->dn_mtx); return (B_TRUE); } I did my usual buildworld buildkernel sequence and then one of my normal install sequences into main-CA72 to update it to have the change, as well as the prior material involved in my first experiment that I'd reported on. I cleared the content of the jail that I use for temporary experiments, such as the prior testing that got the 11 builder failures: # poudriere pkgclean -jmain-CA72-bulk_a -A I then rebooted using the updated main-CA72 BE. Then I started the: # poudriere bulk -jmain-CA72-bulk_a -w -f ~/origins/CA72-origins.txt . . . [00:00:37] Building 476 packages using up to 16 builders [00:00:37] Hit CTRL+t at any time to see build progress and stats [00:00:38] [01] [00:00:00] Builder starting [00:00:40] [01] [00:00:02] Builder started [00:00:40] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.19.1_1 In the prior experiment it got: 476 =3D 252 success + 11 failed + 213 skipped and it reported the time for that as: 00:37:52. A normal from-scratch build takes many hours (multiple compiler toolchains and such) so my first report after this point will be for one of: A) It got to, say, 00:40:00 or beyond with, or without failures. vs. B) It got failures and stopped before that. . . . TIME GOES BY . . . At about 00:40:00 the status was: [00:40:00] [06] [00:00:00] Building x11/libXv | libXv-1.0.12,1 load: 30.73 cmd: sh 1508 [nanslp] 2400.88r 6.69u 11.90s 0% 3960k [main-CA72-bulk_a-default] [2023-04-15_14h47m19s] [parallel_build:] = Queued: 476 Built: 235 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 = Tobuild: 241 Time: 00:40:01 ID TOTAL ORIGIN PKGNAME = PHASE PHASE TMPFS CPU% MEM% [15] 00:07:44 devel/py-lxml@py39 | py39-lxml-4.9.2 = stage 00:00:08 40.00 KiB 0% 0% [01] 00:00:34 x11/libXxf86vm | libXxf86vm-1.1.4_3 = build-depends 00:00:03 56.00 KiB 2.3% 0% [16] 00:01:59 x11-toolkits/libXt | libXt-1.2.1,1 = configure 00:00:52 40.00 KiB 0.3% 0% [02] 00:01:40 devel/dbus | dbus-1.14.6,1 = configure 00:00:05 36.00 KiB 0.5% 0% [03] 00:02:20 x11/libXrender | libXrender-0.9.10_2 = configure 00:01:27 40.00 KiB 0% 0% [04] 00:00:44 graphics/libglvnd | libglvnd-1.6.0 = build-depends 00:00:13 52.00 KiB 20.3% 0.1% [05] 00:01:39 x11/xprop | xprop-1.2.6 = configure 00:00:45 56.00 KiB 0.7% 0.2% [06] 00:00:14 x11/libXv | libXv-1.0.12,1 = pkg-depends 00:00:03 52.00 KiB 3.6% 0% [07] 00:01:57 x11/libXfixes | libXfixes-6.0.0 = configure 00:00:42 40.00 KiB 0.1% 0% [08] 00:03:01 devel/glib20 | glib-2.76.1,2 = configure 00:01:26 40.00 KiB 4.3% 0.1% [09] 00:01:21 shells/bash-completion | bash-completion-2.11_2,2 = configure 00:00:13 32.00 KiB 5.7% 0% [10] 00:06:26 devel/qt5-buildtools | qt5-buildtools-5.15.8p157 = package 00:01:57 44.00 KiB 76.1% 0.1% [11] 00:01:20 print/psutils | psutils-1.17_5 = stage 00:00:03 40.00 KiB 0.2% 0% [12] 00:02:09 x11/libxkbfile | libxkbfile-1.1.0 = configure 00:01:22 44.00 KiB 0.1% 0% [13] 00:08:54 devel/cmake-core | cmake-core-3.25.1 = build 00:01:43 36.00 KiB 694.9% 5.2% [14] 00:01:20 x11/xcb-util-image | xcb-util-image-0.4.0_1 = configure 00:00:14 48.00 KiB 0% 0% [00:40:14] Logs: = /usr/local/poudriere/data/logs/bulk/main-CA72-bulk_a-default/2023-04-15_14= h47m19s [00:40:22] [11] [00:01:28] Finished print/psutils | psutils-1.17_5: = Success So no failures so far, 235 ports built and a bunch in process. Note: maximum observed ("MaxObs") load averages so far as shown below (for there being only 16 cores, i.e., 16 Cortex-A72 threads, one per core): load averages: 43.75, 34.32, 27.40 MaxObs: 45.03, 34.32, 27.40 I'll report again if it gets a corruption failure. Otherwise it will be many hours before it would complete without such failures (multiple compiler toolchain builds and such). =3D=3D=3D Mark Millard marklmi at yahoo.com