zfs send -R | zfs recv aborted

[Derek (freebsd lists)]

On 17-07-18 05:19 PM, Frank Leonhardt wrote:
> On 18/07/2017 11:02, Derek (freebsd lists) wrote:
>> Thanks for the response.  Sorry I wasn't clear - those options 
>> aren't available in 10.2 - and this is the upgrade path for 
>> this machine (i.e. migrate to a new one).
>>
>> Other thoughts still welcome. 
> 
> I'm not 100% sure that datasets that appear to be good on a 
> failed send will be safe; I presume you've checked!
> 
> So your problem is that you need to free up broken dataset 
> snapshots on the receiver. I don't understand why this is a 
> problem - why not just "destroy" them?
> 

And here, you've gotten to the heart of the matter.  Perhaps the 
questions I mean to be asking are:

- How can I tell which datasets/snapshots were received in-tact, 
and which are only partial transfers?  (I *presume* some are 
in-tact, and they superficially appear to be so.)
- Can this be done using only properties/metadata of the zfs 
dataset + pool? (like a receive completed flag)

> You might want to consider a differential "send" (with a -I 
> (capital i) ) option, which will send the snapshot plus all the 
> missing intermediate ones.
> 

I tried this route, and it just spun the CPU for a day - perhaps 
meaningful output was coming, just not then.

> I've a dim idea that zxfer might be of some help here, but as you 
> say, the OpenZFS from 10.3 onwards has exactly the option you need.
> 

That's a good point.  I'll look there for some inspiration - and 
see how deep it goes.

> Am I right in thinking these two machines are colocated? Why not 
> just export the pool on one and import on the other? (Lack of 
> drive bays being one obvious reason - just get a load of 
> USB->SATA cables and a hub). Just a thought.
> 

The source machine is active in service.

Thanks for that!
Derek