Brendan Hide <bren...@swiftspirit.co.za> writes:
> 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.
--
_____________________________________________________________________
/ __// /__ ____ __ http://www.modeemi.fi/~flux/\ \
/ /_ / // // /\ \/ / \ /
/_/ /_/ \___/ /_/\_\@modeemi.fi \/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
