Bug #7247
closedzfs receive of deduplicated stream fails
100%
Description
The following script will cause the zfs receive operation to fail:
- clean
zpool destroy tank
zpool destroy tanker
rm -f /tank.img /tanker.img
- create pools
truncate -s 1g /tank.img
truncate -s 1g /tanker.img
zpool create tank /tank.img
zpool create tanker /tanker.img
- test case
zfs create tank/fs
echo blah > /tank/fs/blah
zfs snapshot tank/fs@base
echo grumble > /tank/fs/grumble
echo blah > /tank/fs/blah2
zfs snapshot tank/fs@snap2
echo grumble > /tank/fs/mumble
echo blah > /tank/fs/blah3
zfs snapshot tank/fs@snap3
zfs send -D -R tank/fs@snap3 > send.tank-new
zfs receive -v tanker/myfs < send.tank-new
There's some additional discussion of this issue in the Linux ZFS tracker here: https://github.com/zfsonlinux/zfs/issues/2210
There are two problems here:
1. When receiving onto an existing filesystem, a snapshot created during the receive process does not get added to the guid->dataset mapping for the stream in dmu_recv_end. This results in failed lookups for deduped streams when a WRITE_BYREF record referred to a snapshot received earlier in the stream. The new snapshot is now always added.
2. The newly created snapshot was also not set properly in dmu_recv_end_sync when receiving onto an existing filesystem, referencing the snapshot before the new receiving dataset rather than the existing filesystem. In that case, it's now properly set with respect to origin_head.
Updated by Electric Monk over 5 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit 2ad25b4055c18f39b3fb20bd5c8c61057e34f377
commit 2ad25b4055c18f39b3fb20bd5c8c61057e34f377 Author: Chris Williamson <chris.williamson@delphix.com> Date: 2016-09-01T17:49:56.000Z 7247 zfs receive of deduplicated stream fails Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com>