BRT: Fix holes cloning

[amotin]

• When reading L0 block pointers handle buffers without ones and without dirty records as a holes. Those appear when dnode size was increased, but the end was never written, so there are no new indirection levels to store the pointers. It makes no sense to return EAGAIN here, since sync won't create new indirection levels until there will be actual writes.
• When cloning blocks set destination hole logical birth time to the current TXG. Otherwise if we are cloning over existing data, newly created holes may not be properly replicated later. Use BP_SET_BIRTH() when possible to not replicate its logic.

Closes: #15994

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[rrevans]

The fix looks good, though probably want a new test in the CI suite for both cases?

Would also suggest adding assertions for the existing hole pointers having zero physical birth time during dmu_read_l0_bps if that's not already covered elsewhere.

[amotin]

Would also suggest adding assertions for the existing hole pointers having zero physical birth time during dmu_read_l0_bps if that's not already covered elsewhere.

It don't think it is important in general to assert it. And doing it in dmu_read_l0_bps is even less useful, since it does not care, and wherever it could happen before, it already happened and we won't know where.

[amotin]

I've found that we do need to mess with physical birth time here, since previous block pointer could have zero there, thanks to BP_SET_BIRTH() logic. I've just rewritten it more explicitly using BP_SET_BIRTH() instead of incomplete local hack. Now I hope next set of tests to come clean aside of the infrastructure problems CI has.

[behlendorf]

Looks good. The cp_files_002_pos is known to be a bit racy, we need to add a retry there.

[implr]

There's still a lockup here for absurdly large sparse files. I found it with xfstests' generic/303, but the simplest reproducer I have is:

xfs_io -f -c "pwrite -S 0x61 9223372036854775806 1" file1
cp --reflink=always -p -f file1 file2

and the cp will never finish. perf indicates it spins in dbuf_find/dbuf_destroy/mutex_lock.

[amotin]

There's still a lockup here for absurdly large sparse files.

@implr I don't see how it is related to this PR. It can be considered a form of #16014 , or could be counted as separate issue, since we could think of adding signal handling to large zfs_clone_range() calls to be able to abort it.

[implr]

Oops, right, I didn't see that issue. Nevermind.

[behlendorf]

@amotin if you can rebase this and resolve the conflict I'll go ahead and merge this.