Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Jul 2017 15:32:40 -0400
From:      "Derek (freebsd lists)" <482254ac@razorfever.net>
To:        freebsd-questions@freebsd.org
Subject:   zfs send -R | zfs recv aborted
Message-ID:  <ca6f887b-2c67-fbfc-303e-544827b97ed1@razorfever.net>

next in thread | raw e-mail | index | archive | help
Hiya!

Wondering if anyone can help give me pointers, or has a rough 
idea where to look next.

The situation is this:  I've got a 10.2-RELEASE sender, and a 
10.3-RELEASE receiver.  I'm trying so send a ~20TB recursive 
dataset over gig-e.  I've had a failed send because the ssh 
connection is torn down (for reasons unknown), and a second 
failed attempt because the zfs send command went <defunct> (a 
child of sudo).  Usually the transfer fails after a few days 
(14TB+) of copying.  I'm confident in the hardware.

My thinking is, most of the filesystems+snapshots that are 
already showing up on the receive side are successful.  If 
possible, I'd like to keep the correctly-received 
filesystems+snapshots, and free up the resources from the ones 
that haven't been correctly received.  Then I will transfer the 
rest by name (i.e. not recursively).

The send-resume in 10.3 would be fabulous here, but I'm running 
out of time, and I'd really rather avoid a restart.

I've been playing around with zdb to try to compare what's 
missing/incomplete, but the manual page doesn't really give me 
much information on how to understand the detailed information 
returned.

Does anyone have:
- an alternative approach
or
- a way to free the resources by an incomplete receive, without 
trashing the rest of the receive
or
- a resource that will help me grok zdb output such that I could 
write something that will be able to give me the value I seek


Thanks
Derek



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ca6f887b-2c67-fbfc-303e-544827b97ed1>