LANで大きなファイルをコピーする高速な方法
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（そのファイルの構文を使用）と同様。
上記は問題なく動作しますが、ファイルとディレクトリは巨大です。ファイルの平均サイズは1片あたり約半ギガバイトで、ディレクトリはすべて15〜50ギガバイトです。
それらを転送するためにrsyncを使用しており、コマンド（192.168.1.2で）は
$ rsync -avxS /mnt/network1 ~/somedir
巨大なファイルをより適切に処理するためにNFS設定を微調整する方法があるかどうかはわかりませんが、rsyncデーモンを単純な古いTCPで実行しているかどうかを確認したいと思います。 NFSではrsyncよりもうまく機能します。
繰り返しますが、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
しかし、ここに朗報があります。静的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
これらの設定により、2つのネットブックはifupがなくても、起動後に直接pingを実行できます。
とにかく、私はncが実際に動作することを本当に望んでいるので、誰かがこのプロセスのデバッグを手伝ってくれることを願っています。
簡単な方法
変更が少ない場合を除いて、LAN経由でファイルを転送するquickestの方法は、おそらく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）を使用してtarをポート1234のraw TCP接続で送信します。暗号化、認証チェックなどがないため、非常に高速です。クロスコネクトがギガビット以下の場合は、ネットワークをペグします。それ以上の場合は、ディスクをペグします（ストレージアレイまたは高速ディスクがない場合）。tarへのvフラグを指定すると、ファイル名が表示されるときにファイル名が出力されます（詳細モード） ）大きなファイルの場合、これは実質的にオーバーヘッドがありません。大量の小さなファイルを実行している場合は、それをオフにします。また、pvなどをパイプラインに挿入して、進行状況インジケーターを取得できます。
user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv
もちろん、gzip -1のような他のものを挿入することもできます（受信側にzフラグを追加します。もちろん、GZIP環境変数を設定しない限り、送信側のzフラグは1より高い圧縮レベルを使用します）。データreallyが圧縮されない限り、gzipはおそらく実際には遅くなります。
本当にrsyncが必要な場合
変更されたデータのごく一部のみを実際に転送する場合は、rsyncの方が高速かもしれません。非常に高速なネットワーク（クロスコネクトなど）と同様に、-W/--whole-fileオプションを確認することもできます。
Rsyncを実行する最も簡単な方法は、sshを使用することです。チップにIntelのAESが搭載されているかどうかに応じて、AES、ChaCha20、またはBlowfish（Blowfishの64ビットブロックサイズにはセキュリティ上の懸念があります）のいずれかで、ssh暗号を試してみてください。 -NIの手順（および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では、暗号なしで実行することはできません。もちろん、-avPの代わりに、好きなrsyncオプションを使用できます。もちろん、反対方向に移動して、ソースマシン（プッシュ）ではなく宛先マシン（プル）から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
これは逆の方法でも行うことができます（もちろん、読み取り専用をnoに設定する必要があります）。認証などのオプションがあります。詳細はマンページを確認してください。
どうやって？またはTL; DR
私が見つけた最速の方法は、tar、mbuffer、sshの組み合わせです。
例えば。：
_tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
_これを使用して、1 Gbリンクで950 Mb/s以上の持続的なローカルネットワーク転送を実現しました。各tarコマンドのパスを、転送するものに適したものに置き換えます。
どうして？ mbuffer！
大きなファイルをネットワーク経由で転送する際の最大のボトルネックは、断然、ディスクI/Oです。その答えはmbufferまたはbufferです。これらはほとんど同じですが、mbufferにはいくつかの利点があります。デフォルトのバッファサイズは、mbufferの場合は2MB、bufferの場合は1MBです。バッファが大きいほど、空になることはありません。ターゲットと宛先の両方のファイルシステムでネイティブブロックサイズの最小公倍数であるブロックサイズを選択すると、最高のパフォーマンスが得られます。
バッファリングは、allの違いを生み出すものです！あれば、それを使用してください！お持ちでない場合は、入手してください！ _(m}?buffer_に加えて何でも使用することは、それ自体で何よりも優れています。ほぼ文字通り、遅いネットワークファイル転送の万能薬です。
複数のファイルを転送する場合は、tarを使用して、それらを1つのデータストリームにまとめます。単一のファイルの場合、catまたはI/Oリダイレクトを使用できます。 tarとcatのオーバーヘッドは統計的に重要ではないので、すでにtarballでない限り、常にtar（または、可能な場合は_zfs -send_）を使用します。これらのどちらもメタデータを提供することは保証されていません（特にcatは提供しません）。メタデータが必要な場合は、演習として残しておきます。
最後に、トランスポートメカニズムにsshを使用すると、安全でオーバーヘッドもほとんど発生しません。この場合も、sshとncのオーバーヘッドは統計的に重要ではありません。
TCPを使用する必要すらありません。 AoEはイーサネットを介したATA実装であり、レイヤー2であるため、TCP/IPスタックの知識がないオーバーヘッドの少ないアプローチです。最小限のオーバーヘッドで可能な限り高速な転送を提供します。***
https://en.wikipedia.org/wiki/ATA_over_Ethernet
***ネットワークがボトルネックになっている場合は、圧縮データを送信していることを確認してください。