Reinstate raw receive check when truncating

[tcaputi]

This patch re-adds a check that was removed in 369aa50. The check
confirms that a raw receive is not occuring before truncating an
object's dn_maxblkid. At the time, it was believed that all cases
that would hit this code path would be handled in other places,
but that was not the case.

Signed-off-by: Tom Caputi tcaputi@datto.com

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)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.

[ahrens]

At the time, it was believed that all cases
that would hit this code path would be handled in other places,
but that was not the case.

Could you describe in the comment how we get into the case where this is not handled?

[codecov]

Codecov Report

Merging #8857 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #8857      +/-   ##
==========================================
+ Coverage   78.64%   78.68%   +0.03%     
==========================================
  Files         382      382              
  Lines      117771   117771              
==========================================
+ Hits        92624    92663      +39     
+ Misses      25147    25108      -39

Flag	Coverage Δ
#kernel	79.24% <100%> (-0.08%)	⬇️
#user	67.53% <100%> (+0.55%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8e91c5b...6db0b05. Read the comment docs.

[tcaputi]

@ahrens I still don't have a reproducer, but my current theory is that this can happen if you write some data to the last block of a file and then later replace that data with zeros with compression on. I believe that this will cause the block to be replaced with a hole, even though its not technically a truncation. The receive side will still just get an aggregated DRR_FREE record that includes the hole, so without this check it will attempt to do a real truncation.

@kpande What test case? I'm sorry I don't remember.

[ahrens]

@tcaputi That makes sense. The way you've described it sounds straightforward to reproduce. Could you verify and then add a comment explaining this? E.g. something like Usually, the last FREE record will be at the maxblkid, because the source system sets the maxblkid when truncating. However, if the last block was freed by overwriting with zeros and being compressed away to a hole, the source system will generate a FREE record while leaving maxblkid after the end of the FREE record. In this case we need to leave the maxblkid as indicated in the OBJECT record, so that it matches the source system, so that the cryptographic hashes will match.

[tcaputi]

@ahrens I will add the comment. I verified that this problem can occur, but i needed to use pv to slow down the zfs receive rate enough to ensure that a txg sync happened between the DRR_OBJECT record and the DRR_FREE record. I'm not sure how to add that to a ZTS test case.

[tcaputi]

For documentation, this is the script I used to reproduce the issue:

zpool create -f pool sdb
echo password | zfs create -o compression=on -o encryption=on -o keyformat=passphrase pool/test

yes | dd of=/pool/test/yes.txt bs=128k count=4 iflag=fullblock
zpool sync pool
zdb -e -ddddddd pool/test 2
cat /dev/zero | dd of=/pool/test/yes.txt bs=128k seek=3 count=1 iflag=fullblock
zpool sync pool
zdb -e -ddddddd pool/test 2

zfs snap pool/test@1
zfs send -w pool/test@1 | pv -L 400 | zfs recv pool/recv
echo password | zfs mount -l pool/recv

[rjhind]

but i needed to use pv to slow down the zfs receive rate enough to ensure that a txg sync happened between the DRR_OBJECT record and the DRR_FREE record

I'm generally using pv between send/receive as well when I've been hitting this.