forked from openzfs/zfs
-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
When receiving an object in a send stream the receive_object() function must determine if it is an existing or new object. This is normally straight forward since that object number will usually not be allocated, and therefore it must be a new object. However, when the object exists there are two possible scenarios. 1) The object may have been freed and an entirely new object allocated. In which case it needs to be reallocated to free any attached spill block and to set the new attributes (i.e. block size, bonus size, etc). Or, 2) The object's attributes, like block size, we're modified at the source but it is the same original object. In which case only those attributes should be updated, and everything else preserved. The issue is that this determination is accomplished using a set of heuristics from the OBJECT record. Unfortunately, these fields aren't sufficient to always distinguish between these two cases. The result of which is that a change in the objects block size will result it in being reallocated. As part of this reallocation any spill block associated with the object will be freed. When performing a normal send/recv this issue will most likely manifest itself as a file with missing xattrs. This is because when the xattr=sa property is set the xattrs can be stored in this lost spill block. If this issue occurs when performing a raw send then the missing spill block will trigger an authentication error. This error will prevent the receiving side for accessing the damaged dnode block. Furthermore, if first dnode block is damaged in this way it will make it impossible to mount the received snapshot. This change resolves the issue by updating the sender to always include a SPILL record for each OBJECT record with a spill block. This allows the missing spill block to be recreated if it's freed during receive_object(). The major advantage of this approach is that it is backwards compatible with existing versions of 'zfs receive'. This means there's no need to add an incompatible feature flag which is only understood by the latest versions. Older versions of the software which already know how to handle spill blocks will do the right thing. The downside to this approach is that it can increases the size of the stream due to the additional spill blocks. Additionally, since new spill blocks will be written the received snapshot will consume more capacity. These drawbacks can be largely mitigated by using the large dnode feature which reduces the need for spill blocks. Both the send_realloc_files and send_realloc_encrypted_files ZTS test cases were updated to create xattrs in order to force spill blocks. As part of validating an incremental receive the contents of all received xattrs are verified against the source snapshot. OpenZFS-issue: https://www.illumos.org/issues/9952 FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233277 Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#6224
- Loading branch information
1 parent
b43a27f
commit 0974327
Showing
16 changed files
with
344 additions
and
39 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.