[ZFS] Potential silent data corruption when receiving incremental stream with block size change on receiving side

[Fabian Keil]

The problem described in:
https://github.com/zfsonlinux/zfs/issues/6224
is reproducible on FreeBSD-based systems.

The reproducer script doesn't work as is, but a slightly modified
version of it does:
https://www.fabiankeil.de/tmp/reproduce-zfsonlinux-bug-6224.sh

I've reproduced the problem on a system based on 11-STABLE r322045
but suspect that CURRENT is affected as well.

While the Github issue is titled "Silent corruption in incremental
send without -L flag with large block pool" I only became aware
of the ZFSonLinux bug after discovering silent data loss after
receiving an incremental stream that was sent with the -L flag:

[fk at test-vm ~]$ hd /usr/test/src/sbin/camcontrol/camcontrol.c
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0003ea10
[fk at test-vm ~]$ sudo zdb -ddddddd -bbbbbbb rpool/test/src $(stat -f '%i' /usr/test/src/sbin/camcontrol/camcontrol.c)
Dataset rpool/test/src [ZPL], ID 550, cr_txg 67575, 704M, 78457 objects, rootbp DVA[0]=<0:254bfb000:1000> DVA[1]=<0:3803b7000:1000> [L0 DMU objset] sha256 uncompressed LE contiguous unique double size=800L/800P birth=67755L/67755P fill=78457 cksum=fb0fd08b71ffb3f8:e14c2e477498cdc4:4822440c7db2cccc:9fa4961bce0031b6

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
    100844    2   128K   251K      0   251K    0.00  ZFS plain file (K=inherit) (Z=inherit)
                                        168   bonus  System attributes
	dnode flags: USED_BYTES USERUSED_ACCOUNTED 
	dnode maxblkid: 0
	path	/sbin/camcontrol/camcontrol.c
	uid     1001
	gid     1001
	atime	Sat Jul  8 18:41:59 2017
	mtime	Sat Jul  8 18:41:59 2017
	ctime	Sat Jul  8 18:41:59 2017
	crtime	Sat Jul  8 18:41:59 2017
	gen	609632
	mode	100644
	size	256529
	parent	44643
	links	1
	pflags	40800000004
Indirect blocks:
               0 L1  HOLE [L1 ZFS plain file] size=20000L birth=67755L

		segment [0000000000000000, 000000000003ec00) size  251K

In case of my incremental /usr/src transfer the data corruption is only
reproducible when not setting the -L flag so blindly omitting the flag
is not a reliable workaround.

While I hope that this is a recent regression I didn't have time to
bisect it yet.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20170807/c52ce39f/attachment.sig>