Ahh, but, options are better than no options!
 
 I will try the latter; in our case upgrading the receivers is the more 
challenging prospect than patching senders.
 
 J
 
 From: Paul Dagnelie <p...@delphix.com>
 Reply-To: "discuss@lists.illumos.org" <discuss@lists.illumos.org>
 Date: Thursday, December 1, 2016 at 1:53 PM
 To: "discuss@lists.illumos.org" <discuss@lists.illumos.org>
 Subject: Re: [discuss] ZFS recv hangs
 
 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<mailto: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 09/2016.
 
 Any other info I can pull for anyone?
 
 Thanks,
 
 Joe
 
 From: "Hetrick, Joseph P" 
<joseph-hetr...@uiowa.edu<mailto:joseph-hetr...@uiowa.edu>>
 Reply-To: "discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>" 
<discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>>
 Date: Wednesday, November 30, 2016 at 8:09 AM
 To: "discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>" 
<discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>>
 Subject: Re: [discuss] ZFS recv hangs
 
 Thank you Paul!
 
 Joe
 
 From: Paul Dagnelie <p...@delphix.com<mailto:p...@delphix.com>>
 Reply-To: "discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>" 
<discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>>
 Date: Tuesday, November 29, 2016 at 5:15 PM
 To: "discuss@lists.illumos.org<mailto:discuss@lists.illumos.org>" 
<discuss@lists.illumos.org<mailto: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> 
[https://www.listbox.com/images/feed-icon-10x10.jpgaed2fe2.jpg?uri=aHR0cHM6Ly93d3cubGlzdGJveC5jb20vaW1hZ2VzL2ZlZWQtaWNvbi0xMHgxMC5qcGc]
 <https://www.listbox.com/member/archive/rss/182180/28533586-617f1285> | 
Modify<https://www.listbox.com/member/?&;> Your Subscription
 
 
[https://www.listbox.com/images/listbox-logo-small.pngaed2fe2.png?uri=aHR0cHM6Ly93d3cubGlzdGJveC5jb20vaW1hZ2VzL2xpc3Rib3gtbG9nby1zbWFsbC5wbmc]<http://www.listbox.com>
 



-------------------------------------------
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

Reply via email to