Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

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)).

-- 
Charlie Li
…nope, still don't have an exit line.