Cy Schubert wrote:
On April 12, 2023 8:51:09 AM PDT, Charlie Li <vish...@freebsd.org> 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. -- Charlie Li …nope, still don't have an exit line.
OpenPGP_signature
Description: OpenPGP digital signature
