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