Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 May 2020 20:11:19 +0500
From:      "Eugene M. Zheganin" <emz@norma.perm.ru>
To:        freebsd-stable@freebsd.org
Subject:   zfs receive -s: transfer got interrupted, but no token on the receiving side.
Message-ID:  <db413d1a-69db-bfab-2ed6-a0ea334f95ad@norma.perm.ru>

next in thread | raw e-mail | index | archive | help
Hello,


I have a ZFS dataset about 10T of actual size (may be more) that I need 
to send over a very laggy connection. So I'm sending it from the 
shell-script that reattempts to send it after a short timeout, 
retrieving the send token first. Like that:

===Cut===

#!/bin/sh

exitstatus=1
token=`ssh user@server zfs get receive_resume_token data/reference | 
grep -v SOURCE | awk '{print $3}'`
while ([ $exitstatus -ne 0 ])
do
 ššš zfs send -t $token | ssh -C user@server sudo zfs receive -Fus 
data/reference
exitstatus=$?
 ššš echo "Send interrupted/ended, sleeping for 5 secs."
 ššš sleep 5
done

===Cut===

Usually this goes just flawlessly. But this time, due to a low transfer 
speed and a very laggy connectivity, thus resulting in a send time of 
several weeks, I got a problem:

about one reattempt out of 200 fails with a situation when there's no 
snapshot on the receiving side (only an incomplete dataset which is 
definitely smaller than original one), thus meaning that the dataset is 
incomplete, but there's no token on this dataset. This happened already 
twice, each time on a different size.

How can this even be possible ?


Recieving side side:

[root@playkey-nas:~]# zfs list -t all
NAMEšššššššššššš USEDš AVAILš REFERš MOUNTPOINT
dataššššššššššš 4,67Tš 20,8Tšš 128Kš /data
data/referenceš 4,67Tš 20,8Tšš 128Kš /data/reference

(as you can see there's no snapshot)

Sending side and the snapshot:

[root@san1:/usr/src]# zfs list -t all | grep data/reference@ver2_5917
data/reference@ver2_5917 44,3Gššššš -š 7,73Tš -

Eugene.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?db413d1a-69db-bfab-2ed6-a0ea334f95ad>