zfs send -R | zfs recv aborted

Ultima ultima1252 at gmail.com
Mon Jul 17 22:52:57 UTC 2017


Have you looked into the recv -s options, and the send -t option?
These options are for restarting an interrupted data stream.

I'm of the opinion that this should be a default recv option and add
the option to disable it, but there must be a good reason for this
option not on by default.

On Mon, Jul 17, 2017 at 12:32 PM, Derek (freebsd lists) <
482254ac at razorfever.net> wrote:

> 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
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe
> @freebsd.org"
>


More information about the freebsd-questions mailing list