"btrfs send" and interrupts
Hi,
root@data:/daten/backup/email/xmit# btrfs send foo | ssh wherever btrfs receive /mnt/mail/xmit/ At subvol foo At subvol foo [ some time passes and I need to do something else on that volume ]
^Z
[1]+ Stopped btrfs send foo | ssh -p50022 surf btrfs receive /mnt/mail/xmit/
root@data:/daten/backup/email/xmit# bg [1]+ btrfs send foo | ssh -p50022 surf btrfs receive /mnt/mail/xmit/ & root@data:/daten/backup/email/xmit# [ Immediately afterwards, this happens: ]
ERROR: crc32 mismatch in command.
At subvol foo
At subvol foo
ERROR: creating subvolume foo failed. File exists
[1]+ Exit 1 btrfs send foo | ssh -p50022 surf btrfs receive /mnt/mail/xmit/
root@data:/daten/backup/email/xmit#
Yowch. Please make sure that the simple act of backgrounding a data transfer doesn't abort it. That was ten hours in, now I have to repeat the whole thing. :-/
Thank you.
Signature · 1 line
-- Matthias Urlichs
Quoted 23 lines · Matthias Urlichs
Hi,
root@data:/daten/backup/email/xmit# btrfs send foo | ssh wherever btrfs receive /mnt/mail/xmit/ At subvol foo At subvol foo [ some time passes and I need to do something else on that volume ]^Z
[1]+ Stopped btrfs send foo | ssh -p50022 surf btrfs receive/mnt/mail/xmit/root@data:/daten/backup/email/xmit# bg [1]+ btrfs send foo | ssh -p50022 surf btrfs receive /mnt/mail/xmit/ & root@data:/daten/backup/email/xmit# [ Immediately afterwards, this happens: ]ERROR: crc32 mismatch in command.
At subvol foo
At subvol foo
ERROR: creating subvolume foo failed. File exists
[1]+ Exit 1 btrfs send foo | ssh -p50022 surf btrfs receive/mnt/mail/xmit/
root@data:/daten/backup/email/xmit#
Quoted 5 lines
Yowch. Please make sure that the simple act of backgrounding a data transfer doesn't abort it. That was ten hours in, now I have to repeat the whole thing. :-/
Thank you.
Interesting case. I'm not sure of the merits/workaround needed to do this. It appears even using cat into netcat (nc) causes netcat to quit if you background the operation.
A workaround for future: I *strongly* recommend using screen for long-lived operations. This would have avoided the problem. Perhaps you were sitting in front of the server and it wasn't much of a concern at the time - but most admins work remotely. Never mind ^z, what about other occurrences such as if the power/internet goes out at your office/home and the server is on another continent? Your session dies and you lose 10 hours of work/waiting. With a screen session, that is no longer true.
Signature · 4 lines
__________ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97
Quoted 3 lines · Brendan Hide
Interesting case. I'm not sure of the merits/workaround needed to do this. It appears even using cat into netcat (nc) causes netcat to quit if you background the operation.
Well, that netcat has a bug doesn't mean btrfs-progs should have one as well :) (though I didn't manage to reproduce this with my netcat using tar c ~ | netcat host discard). Neither ssh nor socat mind being suspended and foregrounded.
I imagine the fix is pretty trivial as well. Possibly a read - or a write - is short when it is assumed to be full, or possibly an EINTR is mishandled. (Though it could be more complicated if the operation is inside the kernel..)
While the reasons for using screen you list are good to take into account, the advantage of that is that it protects against an error; but job control no error but the standard way for controlling jobs within a single terminal, and for example in this kind of case actually suspending the transfer for a while can be a desirable operation, ie. to reduce system/network/io load for achieving another concurrent operation faster.
Signature · 4 lines
_____________________________________________________________________
/ __// /__ ____ __ http://www.modeemi.fi/~flux/\ \
/ /_ / // // /\ \/ / \ /
/_/ /_/ \___/ /_/\_\@modeemi.fi \/