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

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:

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?



From: "Hetrick, Joseph P" <>
Reply-To: "" <>
Date: Wednesday, November 30, 2016 at 8:09 AM
To: "" <>
Subject: Re: [discuss] ZFS recv hangs

Thank you Paul!
From: Paul Dagnelie <>
Reply-To: "" <>
Date: Tuesday, November 29, 2016 at 5:15 PM
To: "" <>
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 
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

RSS Feed:
Modify Your Subscription:
Powered by Listbox:

Reply via email to