Wow... I just took another look at the source. Apparently, setting that flag doesn't actually change the behavior of the send stream at all, except to not set the flag in the BEGIN record. My mistake, I thought it did more than that.
In that case, the only fix is to upgrade your receiving systems to work around the bug in ZFS receive, or to add another patch to your sending system that looks something like this: https://gist.github.com/pcd1193182/fcb9f8d43dcbcf32ba736ea7ef600658 . I'm aware that neither of these options is exactly ideal. On Thu, Dec 1, 2016 at 7:46 AM, Hetrick, Joseph P <joseph-hetr...@uiowa.edu> wrote: > 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 > 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 > -- Paul Dagnelie ------------------------------------------- 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
