From nobody Wed Apr 12 17:28:26 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PxV6h5x1yz457j1; Wed, 12 Apr 2023 17:28:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (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 4PxV6h3kvgz3JXj; Wed, 12 Apr 2023 17:28:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-18782426c4bso1405102fac.9; Wed, 12 Apr 2023 10:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681320507; x=1683912507; 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=k+0Qk0xsrFIA70Kobn0JBCexOxn1iYu2GFoU+FZ/Ytw=; b=EJ9SLW0HbgGv+f4i3ML5xJ9cAc6fow1tmNNfji9qbUKDJUCkAV69tazQ2kNjVLwX+r D7lPjeiHREiNlwXJTTBAlt3aCyww2O/MOLKgokAm9ZECLI3UU0rHqS4Iukr3erBvpfSg r2GG6Mpl7Jd6kI14IVij6NN+jsOFHV37gJxRurcEf6yjIXU8zkUTER1XMs6LeFMxx56P NGtWrAtrTb561Qi74x701Cez1cq5X8vFdPsZP6Wk8XQ6MkNq8d3KiPB1vdi757i8sah8 0Q5HE/Hly7arWfOpMFMzgaUvBixJT7VyRyBJMZkfKJUmWRq5xBaEqcCVe3Zn+9OKF21y j6gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681320507; x=1683912507; 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=k+0Qk0xsrFIA70Kobn0JBCexOxn1iYu2GFoU+FZ/Ytw=; b=VTNUqOF/L/nXd6rgEWRAZNyOLjRAABHbJQBEeuPcb/6Au08WlxuD8KOqA/V071fPp7 0DSNiOeWRmI/URsO4BMY9SrNx6X6RLaehoK6nI+hBK33mpTUpUNaIDArTVe/u5iazGUh iErZwAjvr1oLx5VFfHOCXcWdV1PdAPpIWO3dQDzMiq4/5N5mFYXlUYKwAh+dVBMshzGt FUuHWLxNvOKduIZKkS/hx47JlOQnyMPSwKfQq6XuT2LPmEEPcCxntW7WGIDmOMPxhjGc lQFT0AOAGsOo9dTdJn/KDmlBa4K9NZmVlMj3zUXylJ6hcs9OkD5Y/wVM992hFsKbftDV mAUQ== X-Gm-Message-State: AAQBX9enQkGG28wnf+pQsFNygZQJanJBeuJ3vKAmmtYjdNdtpTgIHmwJ +bq/kBNdIYuOM4mY+/FvZDciRIeHxutsvp/x05uZQofc X-Google-Smtp-Source: AKy350Zr4YaHIS2Wn1B1M9qzUFeEcO/cugOPE6OFDouuFj4zPNnIt2YhYrJ0ZhYJxltbc9z6B9CTj1jadGQ5PMXNZ+c= X-Received: by 2002:a05:6870:eca3:b0:184:48cc:62ef with SMTP id eo35-20020a056870eca300b0018448cc62efmr3406890oab.4.1681320507170; Wed, 12 Apr 2023 10:28:27 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Received: by 2002:a8a:28c:0:b0:49c:b071:b1e3 with HTTP; Wed, 12 Apr 2023 10:28:26 -0700 (PDT) In-Reply-To: <64e4af2a-5273-6219-c146-f867160f09ac@freebsd.org> References: <202304031513.333FD6qw014903@gitrepo.freebsd.org> <20230403232549.73E331A2@slippy.cwsent.com> <20230403235851.84C0467@slippy.cwsent.com> <20230404052811.DA2172C1@slippy.cwsent.com> <7c75b934-cb0a-b32e-bc19-b1e15e8cf3aa@freebsd.org> <20230409154042.0685a273@cschubert.com> <707e4671-d746-aa23-e340-6eb8f50f78c6@freebsd.org> <20230409205826.7802259d@cschubert.com> <4e85eb84-f0cc-2f8c-d3d9-1e016ede042a@freebsd.org> <20230410165406.51bcd958@cschubert.com> <70739834-4eea-db30-63be-556bcfd881a1@freebsd.org> <464cc8cd-2bf6-b7e5-3823-89227d842458@freebsd.org> <64e4af2a-5273-6219-c146-f867160f09ac@freebsd.org> From: Mateusz Guzik Date: Wed, 12 Apr 2023 19:28:26 +0200 Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 To: Charlie Li Cc: Cy Schubert , Rick Macklem , Martin Matuska , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4PxV6h3kvgz3JXj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.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 can you please test poudriere with https://github.com/openzfs/zfs/pull/14739/files On 4/12/23, Charlie Li wrote: > Charlie Li wrote: >> Cy Schubert wrote: >>> On April 12, 2023 8:51:09 AM PDT, Charlie Li >>> wrote: >>>> Cy Schubert wrote: >>>>> I have a "sandhbox" pool, called t, used for /usr/obj and ports >>>>> wrkdirs, and other writes I can easily recreate on my laptop. Here >>>>> are the results of my tests. >>>>> >>>>> Method: >>>>> >>>>> Initially I copied my /usr/obj from my two build machines (one >>>>> amd64.amd64 and an i386.i386) to my "sandbox" zpool. >>>>> >>>>> Next, with block_cloning disabled I did cp -R of the /usr/obj test >>>>> files. Then a diff -qr. They source and target directories were the >>>>> same. >>>>> >>>>> Next, I cleaned up (rm -rf) the target directory to prepare for the >>>>> block_clone enabled test. >>>>> >>>>> Next, I did zpool checkpoint t. After this, zpool upgrade t. Pool t >>>>> now has block_cloning enabled. >>>>> >>>>> I repeated the cp -R test from above followed by a diff -qr. Almost >>>>> every file was different. The pool was corrupted. >>>>> >>>>> I restored the pool by the following removing the corruption: >>>>> >>>>> >>>>> slippy# zpool export t >>>>> slippy# zpool import --rewind-to-checkpoint t >>>>> slippy# >>>>> >>>>> It is recommended that people avoid upgrading their zpools until the >>>>> problem is fixed. >>>>> >>>> As of af7624ed3145, I just did this with an md(4)-backed test pool, >>>> though with the second `cp -R` landing in a separate dataset, created >>>> and destroyed for each test. No corruption either way. However, my >>>> poudriere builds still output/package corrupted files (particularly >>>> those with null characters), probably after install(1) invocations >>>> (not cp(1)). >>>> >>> >>> You need to copy from/to the same dataset to reproduce the problem. >>> Copying from a source dataset to a different dataset will avoid >>> block_cloning. >>> >> Got the corruption now. >> > Clarify: no corruption without block_cloning, corruption with. > > What is still a mystery to me is how corruption happens even without > block_cloning in the poudriere scenario. cp(1)/install(1) always happen > within the same dataset, as this test. > > -- > Charlie Li > =E2=80=A6nope, still don't have an exit line. > > --=20 Mateusz Guzik