Finally had time to test this; root@openindiana:/home/jtest# uname -a SunOS openindiana 5.11 illumos-7588687 i86pc i386 i86pc
root@openindiana:/home/jtest# echo "zfs_send_set_freerecords_bit::print" | mdb -k 0x1 root@openindiana:/home/jtest# echo " zfs_send_set_freerecords_bit /W0" | mdb -kw zfs_send_set_freerecords_bit: 0x1 = 0x0 root@openindiana:/home/jtest# echo "zfs_send_set_freerecords_bit::print" | mdb -k 0 create a snapshot, send stream to file; get file on: SunOS test-hw 5.11 oi_151a7 i86pc i386 i86pc Solaris Which is reasonably elderly, but representative of several possible receivers. Recvs still “hang” on the geriatric version; These are basically empty datasets with 1 child (the snapshot I’m testing with) I have systems that are in some interim period: illumos-a7317ce illumos-f83b46b That have zfs_send_set_freerecords_bit = 1, with no problems sending/receiving. We only began to see the issue in systems kept current sometime after 09/2016. Any other info I can pull for anyone? Thanks, Joe From: "Hetrick, Joseph P" <joseph-hetr...@uiowa.edu> Reply-To: "discuss@lists.illumos.org" <discuss@lists.illumos.org> Date: Wednesday, November 30, 2016 at 8:09 AM To: "discuss@lists.illumos.org" <discuss@lists.illumos.org> Subject: Re: [discuss] ZFS recv hangs Thank you Paul! Joe From: Paul Dagnelie <p...@delphix.com> Reply-To: "discuss@lists.illumos.org" <discuss@lists.illumos.org> Date: Tuesday, November 29, 2016 at 5:15 PM To: "discuss@lists.illumos.org" <discuss@lists.illumos.org> Subject: Re: [discuss] ZFS recv hangs Hey all, I sent this email on the 21st, but I apparently was not subscribed to the mailing list, so it got silently dropped. Here it is again! Sorry for the delay in getting to this, I had some other stuff I was working on. I've confirmed that the patch that fixes this issue and causes it is 6393 zfs receive a full send as a clone. As part of that patch, we started sending all the holes in files again, and all the FREEOBJECTS records in the dataset. This results in a DRR_FREEOBJECTS record from the last object in the dataset to a very large object, so that all objects after that one will be freed when receiving. This patch also contains a fix for a bug in receive_freeobjects; prior to this, the loop in receive_freeobjects doesn't check the return value of dmu_object_next, so if it cannot find an object in the range provided, it will go through the loop drr_numobjs times. In this case, that's 36,028,797,018,870,144 times, which understandably presents as a hang. In addition, that loop doesn't check for signals, so you can't ctrl-c the process either. There are two possible solutions to this issue: First, upgrade your receiving system to include the fix for receive_freeobjects. Second, upgrade your sending system to include the fix for 6536 zfs send: want a way to disable setting of DRR_FLAG_FREERECORDS and set zfs_send_set_freerecords_bit to B_FALSE. If you have r151018, then you already have that commit, so setting that tunable should make your streams receivable again. illumos-discuss | Archives | Modify Your Subscription ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
