Project

General

Profile

Bug #8943

ZFS send fails to dump objects with size > 128PiB

Added by Ezomori Nozomu over 2 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2017-12-28
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

When dumping objects larger than 128PiB it's possible for do_dump() to miscalculate the FREE_RECORD offset due to an integer overflow: this prevents the receiving end from correctly restoring the dumped object.

Reproducer (panics DEBUG builds):

function is_linux() {
   if [[ "$(uname)" == "Linux" ]]; then
      return 0
   else
      return 1
   fi
}
# setup
POOLNAME='testpool'
if is_linux; then
   TMPDIR='/var/tmp'
   mountpoint -q $TMPDIR || mount -t tmpfs tmpfs $TMPDIR
   zpool destroy $POOLNAME
   rm -f $TMPDIR/zpool_$POOLNAME.dat
   fallocate -l 128m $TMPDIR/zpool_$POOLNAME.dat
   zpool create $POOLNAME $TMPDIR/zpool_$POOLNAME.dat
else
   TMPDIR='/tmp'
   zpool destroy $POOLNAME
   rm -f $TMPDIR/zpool_$POOLNAME.dat
   mkfile 128m $TMPDIR/zpool_$POOLNAME.dat
   zpool create $POOLNAME $TMPDIR/zpool_$POOLNAME.dat
fi
#
zfs create $POOLNAME/sendfs
zfs set recordsize=128K $POOLNAME/sendfs
dd if=/dev/zero of=/$POOLNAME/sendfs/overflow.bin bs=1 count=1 seek=0
dd if=/dev/zero of=/$POOLNAME/sendfs/overflow.bin bs=1 count=1 seek=$((1024*128)) conv=notrunc
dd if=/dev/zero of=/$POOLNAME/sendfs/overflow.bin bs=1 count=1 seek=$((1024*1024*128)) conv=notrunc
dd if=/dev/zero of=/$POOLNAME/sendfs/overflow.bin bs=1 count=1 seek=$((1024*1024*1024*1024*128)) conv=notrunc
dd if=/dev/zero of=/$POOLNAME/sendfs/overflow.bin bs=1 count=1 seek=$((1024*1024*1024*1024*1024*128)) conv=notrunc
obj=`ls -i /$POOLNAME/sendfs/overflow.bin | awk '{print $1}'`
sync
zdb -ddddddd $POOLNAME/sendfs/ $obj
zfs snap $POOLNAME/sendfs@snap
zfs send $POOLNAME/sendfs@snap | zfs recv $POOLNAME/recvfs
zdb -ddddddd $POOLNAME/recvfs/ $obj

This is from my OI devel box:

root@openindiana:/var/crash# mdb 0
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba uhci fctl mm stmf stmf_sbd lofs sata random idm sd cpc crypto fcip fcp ufs logindmux nsmb ptm smbsrv nfs sppp ]
> ::obey
No Language H here
> ::status
debugging crash dump vmcore.0 (64-bit) from openindiana
operating system: 5.11 master-0-gb3c0a3b184 (i86pc)
image uuid: 83639f86-463a-c7b7-8830-92ff4aaff3af
panic message: assertion failed: length != -1ULL, file: ../../common/fs/zfs/dmu_send.c, line: 217
dump content: all kernel and user pages
> $C
ffffff000ccfe760 vpanic()
ffffff000ccfe790 0xfffffffffbdff6c8()
ffffff000ccfe7f0 dump_free+0x190(ffffff032b105010, 8, fe00000000000000, 200000000000000)
ffffff000ccfe8a0 do_dump+0xea(ffffff032b105010, ffffff03380951f0)
ffffff000ccfea40 dmu_send_impl+0x587(fffffffff79652b3, ffffff0322fec500, ffffff032688f780, 0, 0, 0, ffffff0000000000, ffffff0300000000, ffffff0300000001, 0, 0, ffffff032f7a3500, ffffff000ccfeb88)
ffffff000ccfeb30 dmu_send_obj+0x1e8(ffffff0339a3b000, 2e, 0, 0, 0, 0, ffffff0300000001, ffffff032f7a3500, ffffff000ccfeb88)
ffffff000ccfebd0 zfs_ioc_send+0xf7(ffffff0339a3b000)
ffffff000ccfec70 zfsdev_ioctl+0x546(10e00000000, 5a1c, 8044c58, 100003, ffffff0331340ed0, ffffff000ccfee58)
ffffff000ccfecb0 cdev_ioctl+0x39(10e00000000, 5a1c, 8044c58, 100003, ffffff0331340ed0, ffffff000ccfee58)
ffffff000ccfed00 spec_ioctl+0x60(ffffff031b0c8d00, 5a1c, 8044c58, 100003, ffffff0331340ed0, ffffff000ccfee58, 0)
ffffff000ccfed90 fop_ioctl+0x55(ffffff031b0c8d00, 5a1c, 8044c58, 100003, ffffff0331340ed0, ffffff000ccfee58, 0)
ffffff000ccfeeb0 ioctl+0x9b(3, 5a1c, 8044c58)
ffffff000ccfef00 _sys_sysenter_post_swapgs+0x234()
> 

A possible fix has been provided here https://github.com/zfsonlinux/zfs/pull/6760.


Related issues

Related to illumos gate - Bug #2901: ZFS receive fails for exabyte sparse filesResolved2012-06-20

Actions

History

#1

Updated by Ezomori Nozomu over 2 years ago

  • Related to Bug #2901: ZFS receive fails for exabyte sparse files added

Also available in: Atom PDF