netcat
入力を受け取り、それをファイルにリダイレクトするサーバー上のプロセスをリモートで開くスクリプトを作成しています。
ssh $remote_upload_user@remote_upload_address "nc -l -p $remote_port > $remote_dir/$backup.gz&"
スクリプトは引き続きZFSスナップショットを圧縮し、データをpigz
入力として次に送信しますnetcat
。
netcat $remote_upload_address -u $remote_port < $(zfs send -R $zpool@label | pigz)
最後に追加すると|pv
(括弧内に)データが処理されていることを示しますが、データが渡されると、クライアントの標準出力に無限に歪んだデータストリームが表示されます。pigz
pigz
netcat
サーバーは、作成する必要があるファイルのサイズがゼロ増加したことを示します。なぜこれがうまくいかないのですか?
答え1
$(...)
コマンドの置換です。の出力が読み取るzfs send
ファイル名になることを望まない。の出力をに入力に送信し、その出力をに送信しようnc
とします。zfs send
pigz
pigz
netcat
zfs send -R "$zpool@label" | pigz | netcat "$remote_upload_address" "$remote_port"
UDPを使用しないでください。 TCPとは異なり、UDPは転送保証を提供しません。
リダイレクト演算子を使用するには、-styleを<
使用できます。ksh
プロセス交換(zsh
および江戸ありbash
):
netcat "$remote_upload_address" "$remote_port" < <(
zfs send -R "$zpool@label" | pigz)
ただし、これは標準ベースの同等製品に比べて利点はありません|
。そこからリダイレクト演算子に渡されるファイル名は、<
名前付きパイプまたは/dev/fd/x
パイプを指す特別なファイルです(pigz
パイプのもう一方の端に書き込まれます)。
これは同じですが、いくつかの追加のシステムコールが必要です。別の違いは、シェルがコマンドを待たないことですzfs send|pigz
(待ってもnetcat
出力を読み取る前に終了しない可能性があります)。pigz
または、yash
プロセスリダイレクト演算子を使用してください。
netcat "$remote_upload_address" "$remote_port" <(
zfs send -R "$zpool@label" | pigz)
ここでも、標準構文に比べて利点はありません。yash
プロセスリダイレクトは通常、コマンドの複数のfdを他のコマンドのパイプに接続する場合に使用されます。