NFSに問題があり、一般的なTCPを試してみたいです。
しかし、どこから始めるべきかわかりません。
ハードウェア側では、イーサネットクロスオーバーケーブルを使用して2つのネットブックをネットワークに接続しました。
ネットワークに接続するには、次のように入力します。
$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start
最初のネットブックで
$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1
第二に
/mnt/network1/etc/fstabに次のように指定されています
192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0
そして/etc/exports（このファイルの構文を使用して）最初のネットブックから。
上記の方法はうまくいきますが、ファイルとディレクトリが大きいです。各ファイルの平均サイズは約0.5GB、ディレクトリサイズはすべて15〜50GBです。
rsync送信に使用するコマンドは次のとおり192.168.1.2です。
$ rsync -avxS /mnt/network1 ~/somedir
大容量ファイルをよりよく処理するためにNFS設定を調整する方法があるかどうかはわかりませんが、通常のrsync既存のTCPを介してデーモンを実行する方がrsyncNFSより優れていることを確認したかったです。
では、言い換えれば、TCPを使用して同様のネットワークをどのように構築しますか？
修正する:
それで、無知の泥沼から自分自身を引き出そうと数時間努力した最後に（または私が思うように最善を尽くして努力した最後に）いくつかの有用な事実を思い出しました。
しかし、まず、単に現在の最善の答えを受け入れるのではなく、私をこのウサギの道に導いたのはこれでした。これはnc信じられないほど素晴らしいプログラムですが、確かに私には適していません。私は試して梱包netcat-openbsdしnetcat-traditionalましたが、運がありませんでした。
受信コンピュータから受け取ったエラー（）192.168.1.2は次のとおりです。
me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
route以下を提供します。
me@netbook:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default dir-615 0.0.0.0 UG 0 0 0 wlan0
link-local * 255.255.0.0 U 1000 0 0 eth0
192.168.0.0 * 255.255.255.0 U 2 0 0 wlan0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
しかし、良いニュースは次のとおりです。 .netで静的IPアドレスを設定すると/etc/network/interfaces（nc起動しようとしたときに開始）、すべてのNFSの問題が解決され、NFSへの愛が再発しました。
私が使用した正確な設定（192.168.1.1もちろん最初のネットブック）は次のとおりです。
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
これらの設定を使用すると、両方のネットブックは起動後に直接pingを実行することなく互いにpingを送信できますifup。
それにもかかわらず、私はこれが実際に動作しているのを見たいncので、誰かがこのプロセスをデバッグするのを手伝ってくれることを願っています。
答え1
クイックメソッド
これ最速マイナーな変更がない限り、LAN経由でファイルを転送する方法はrsyncではありません。 rsync は、チェックサム、差分計算などを実行するのにかなりの時間を費やします。とにかく、ほとんどのデータが送信されることを知っている場合は、次のようにします（注：いくつかの実装があります。netcat特にマニュアルを確認してください。おそらく望ましくないでしょう-p）。
user@dest:/target$ nc -q 1 -l -p 1234 | tar xv
user@source:/source$ tar cv . | nc -q 1 dest-ip 1234
netcat（nc）を使用して、ポート1234の生のTCP接続を介してtarを送信します。暗号化、真偽確認などがないので、非常に高速です。クロス接続がギガビット以下で実行されるとネットワークに接続し、それ以上の場合はディスクに接続します（ストレージアレイや高速ディスクがない場合）。v実行時にファイル名を印刷するtarにフラグを付けます（詳細モード）。大容量ファイルの場合、オーバーヘッドはほとんどありません。小さなファイルがたくさんある場合は、この機能をオフにできます。あるいは、pvパイプラインに次の項目を挿入して進行状況インジケータを取得することもできます。
user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv
もちろん、他の項目も挿入できます（そしてgzip -1受信側にフラグを追加します。もちろん、GZIP環境変数を設定しない限り、送信側のフラグは1より高い圧縮レベルを使用します）。データがないとgzipが実際に遅くなることがありますが、zz本物圧縮。
本当にrsyncが必要な場合
変更されたデータの一部のみを転送する場合は、rsync が高速になる可能性があります。非常に高速なネットワーク（クロスコネクトなど）がはるかに高速になる可能性があるため、-W/オプションを確認することをお勧めします。--whole-file
rsyncを実行する最も簡単な方法はsshを使用することです。どちらが最速であるかを確認するには、SSH暗号化を試みる必要があります。チップにIntel AES-NIがあるかどうかに応じて、AES、ChaCha20、またはBlowfish（Blowfishの64ビットブロックサイズにいくつかのセキュリティ上の問題がある）があります。指示（そしてOpenSSLはそれを使用します）。新しいSSHでは、rsync-over-sshは次のようになります。
user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target
以前のssh / sshdの場合は、代わりにまたはaes128-ctrを使用してみてください。aes128-cbc[email protected]
ChaCha20は[email protected]（十分な新しいssh / sshdも必要です）、BlowfishはBlowfish-cbcです。 OpenSSHはパスワードなしでは実行できません。もちろん、必要なrsyncオプションを代わりに使用できます-avP。もちろん、別の方向に移動して、ソースマシン（プッシュ）の代わりにターゲットマシン（プール）でrsyncを実行することもできます。
rsyncをより速くする
rsyncデーモンを実行すると、暗号化オーバーヘッドを削除できます。まず、/etc/rsyncd.confたとえばソースマシンからデーモン設定ファイル（）を生成します（詳細についてはrsyncd.confのマンページを参照）。
[big-archive]
path = /source
read only = yes
uid = someuser
gid = somegroup
その後、ターゲットマシンで実行します。
user@dest:~$ rsync -avP source-ip::big-archive/ /target
これを反対方向に実行することもできます（もちろん読み取り専用をいいえに設定する必要があります）。認証などのオプションがあります。詳しくはマンページをご覧ください。
答え2
どのように？またはTL; DR
tar私が見つけた最速の方法はmbuffer、との組み合わせですssh。
たとえば、
tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
これを使用して、1Gbリンクで950 Mb / s以上の継続的なローカルネットワーク伝送を達成しました。転送する項目に合わせて、各 tar コマンドのパスを変更します。
なぜ？バッファー！
ネットワーク経由で大容量ファイルを転送する場合、最大のボトルネックはディスクI / Oです。答えはmbufferまたはですbuffer。一般的に似ていますが、mbufferいくつかの利点があります。デフォルトのバッファサイズは2MB mbuffer、デフォルトのバッファサイズは1MBですbuffer。バッファが大きいほど空になる可能性が高くなります。ターゲットファイルシステムとターゲットファイルシステムのデフォルトブロックサイズの最小公倍数であるブロックサイズを選択すると、最高のパフォーマンスが得られます。
バッファリングは許可するものですみんな違い！お持ちの方は活用してみてください！一つもないなら、それを手に入れよう！何でも(m}?buffer一人で使うよりも何でも使うことをお勧めします。遅いネットワークファイル転送のためのほぼ万病歯磨き粉です。
転送するファイルが複数ある場合は、tarそのファイルを単一のデータストリームとして「塊」として使用してください。単一ファイルの場合は、catI/O リダイレクトを使用できます。tarvsのオーバーヘッドはcat統計的に重要ではないので、すでに使用していない限り常に使用しますtar（またはzfs -send可能であれば）。アーカイブ。これらのどれもメタデータの提供を保証しません（特にcatそうではありません）。メタデータが必要な場合は練習用として残しておきます。
最後に、ssh使用される転送メカニズムは安全でオーバーヘッドがほとんどありません。繰り返しますが、sshANDのオーバーヘッドncは統計的に重要ではありません。
編集する
わかりました、みんな答えはこれです。十歳です。時代が変わりました。
- この質問は具体的にローカルエリアネットワークs、大陸の間ではない。
- mbuffered ssh と mbuffered nc は統計的に有意ではありません。 sshだけを使うのはncだけを使うのとは違います。 tcpとudpモードのNCは別の問題です。
- このアップデート（2022-01）現在、高速ファイル転送に対する最も一般的な答えはまだです（コメントで@derobertが述べたように）。
scp -c [email protected]
答え3
TCPを使用する必要さえありません。 AoEはイーサネットを介したATA実装であり、レイヤ2としてTCP / IPスタックの知識を必要としない低オーバーヘッドアプローチです。最小限のオーバーヘッドで最速の転送速度を提供します。 ***
https://en.wikipedia.org/wiki/ATA_over_Ethernet
***ネットワークにボトルネックが発生した場合は、圧縮データを転送していることを確認してください。