Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Apr 2023 11:28:09 -0700
From:      Cy Schubert <Cy.Schubert@cschubert.com>
To:        Mateusz Guzik <mjguzik@gmail.com>, Charlie Li <vishwin@freebsd.org>
Cc:        Rick Macklem <rick.macklem@gmail.com>, Martin Matuska <mm@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject:   Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Message-ID:  <F997F00F-4569-42D4-AE0D-4089619FA2A5@cschubert.com>
In-Reply-To: <CAGudoHHjpvRPAYJJnaENkxJotgsA9fm27aTZOO=h19G_-szLBQ@mail.gmail.com>
References:  <202304031513.333FD6qw014903@gitrepo.freebsd.org> <20230403235851.84C0467@slippy.cwsent.com> <CAM5tNy6TMoXAKyfWq_psEjK0zy9j%2B=7yzp1vRirAfTdXBxabSQ@mail.gmail.com> <CAM5tNy64HTeC8%2BOT_SHg1osnKKAH3_qQJkyWFuOy-LDAFVzu%2BA@mail.gmail.com> <20230404052811.DA2172C1@slippy.cwsent.com> <7c75b934-cb0a-b32e-bc19-b1e15e8cf3aa@freebsd.org> <20230409154042.0685a273@cschubert.com> <ba938b23-a6d0-f673-ffc8-b3d9d59e53a4@freebsd.org> <E3DD3607-887C-48C4-9031-5204DD84E6A5@cschubert.com> <a99a20b9-c348-89f6-db37-604f72002da4@freebsd.org> <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> <D62F34CB-69D0-46FE-89C9-9BD2536DBFC5@cschubert.com> <464cc8cd-2bf6-b7e5-3823-89227d842458@freebsd.org> <64e4af2a-5273-6219-c146-f867160f09ac@freebsd.org> <CAGudoHHjpvRPAYJJnaENkxJotgsA9fm27aTZOO=h19G_-szLBQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On April 12, 2023 10:28:26 AM PDT, Mateusz Guzik <mjguzik@gmail=2Ecom> wrot=
e:
>can you please test poudriere with
>https://github=2Ecom/openzfs/zfs/pull/14739/files
>
>On 4/12/23, Charlie Li <vishwin@freebsd=2Eorg> wrote:
>> Charlie Li wrote:
>>> Cy Schubert wrote:
>>>> On April 12, 2023 8:51:09 AM PDT, Charlie Li <vishwin@freebsd=2Eorg>
>>>> 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=2E Her=
e
>>>>>> are the results of my tests=2E
>>>>>>
>>>>>> Method:
>>>>>>
>>>>>> Initially I copied my /usr/obj from my two build machines (one
>>>>>> amd64=2Eamd64 and an i386=2Ei386) to my "sandbox" zpool=2E
>>>>>>
>>>>>> Next, with block_cloning disabled I did cp -R of the /usr/obj test
>>>>>> files=2E Then a diff -qr=2E They source and target directories were=
 the
>>>>>> same=2E
>>>>>>
>>>>>> Next, I cleaned up (rm -rf) the target directory to prepare for the
>>>>>> block_clone enabled test=2E
>>>>>>
>>>>>> Next, I did zpool checkpoint t=2E After this, zpool upgrade t=2E Po=
ol t
>>>>>> now has block_cloning enabled=2E
>>>>>>
>>>>>> I repeated the cp -R test from above followed by a diff -qr=2E Almo=
st
>>>>>> every file was different=2E The pool was corrupted=2E
>>>>>>
>>>>>> 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 th=
e
>>>>>> problem is fixed=2E
>>>>>>
>>>>> 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, create=
d
>>>>> and destroyed for each test=2E No corruption either way=2E However, =
my
>>>>> poudriere builds still output/package corrupted files (particularly
>>>>> those with null characters), probably after install(1) invocations
>>>>> (not cp(1))=2E
>>>>>
>>>>
>>>> You need to copy from/to the same dataset to reproduce the problem=2E
>>>> Copying from a source dataset to a different dataset will avoid
>>>> block_cloning=2E
>>>>
>>> Got the corruption now=2E
>>>
>> Clarify: no corruption without block_cloning, corruption with=2E
>>
>> What is still a mystery to me is how corruption happens even without
>> block_cloning in the poudriere scenario=2E cp(1)/install(1) always happ=
en
>> within the same dataset, as this test=2E
>>
>> --
>> Charlie Li
>> =E2=80=A6nope, still don't have an exit line=2E
>>
>>
>
>

I'll test this on my scratch pool later today or tomorrow as I'm afk atm=
=2E

(Bottom posted because the app is configured so=2E)


--=20
Cheers,
Cy Schubert <Cy=2ESchubert@cschubert=2Ecom>
FreeBSD UNIX:  <cy@FreeBSD=2Eorg>  Web:  https://FreeBSD=2Eorg
NTP:                     <cy@nwtime=2Eorg>    Web:  https://nwtime=2Eorg
                                                    e^(i*pi)+1=3D0

Pardon the typos=2E Small keyboard in use=2E



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F997F00F-4569-42D4-AE0D-4089619FA2A5>