2TB（10 milファイル+ dirs）の移動、私のボトルネックは何ですか？

バックグラウンド

私はスペースを使い果たしたの/home/dataと移す必要/home/data/repoに/home/data2。

/home/data/repo1Mのdirsが含まれ、それぞれに11のdirsと10のファイルが含まれます。合計2TBです。

/home/datadir_indexが有効なext3にあります。 /home/data2ext4にあります。CentOS 6.4の実行。

これらのアプローチは、repo/その直下に100万個のdirsがあるという事実のために遅いと思います。

試行1：mv高速ですが、中断されます

これが終わっていれば、私はできました：

/home/data> mv repo ../data2

しかし、1.5TBが転送された後に中断されました。約1GB / minで書き込みを行っていました。

試行2：rsyncファイルリストを作成してから8時間後にクロールする

/home/data> rsync --ignore-existing -rv repo ../data2

「増分ファイルリスト」を作成するのに数時間かかり、100MB /分で転送しました。

より高速なアプローチを試すためにキャンセルします。

試行3a：mv文句を言う

サブディレクトリでテストする：

/home/data/repo> mv -f foobar ../../data2/repo/
mv: inter-device move failed: '(foobar)' to '../../data2/repo/foobar'; unable to remove target: Is a directory

私はこれが何についてのエラーであるかcpわかりませんが、多分私を救うことができます。

試行3b：cp8時間後に何も得られない

/home/data> cp -nr repo ../data2

ディスクを8時間読み取り、キャンセルしてrsyncに戻ることにしました。

試行4：rsyncファイルリストを作成してから8時間後にクロールする

/home/data> rsync --ignore-existing --remove-source-files -rv repo ../data2

--remove-source-files今すぐクリーンアップを開始すると、それが速くなるかもしれないと考えて使用しました。

ファイルリストの作成には少なくとも6時間かかり、100〜200MB /分で転送します。

しかし、サーバーには一晩で負担がかかり、接続は閉じられました。

試行5：移動するのに300GBしか残っていない理由

/home/data> rsync --ignore-existing --remove-source-files -rvW repo ../data2

再び中断されました。これ-Wにより、「増分ファイルリストの送信」が高速化されたように見えましたが、これは理にかなっていないはずです。とにかく、転送はひどく遅く、私はこれをあきらめています。

試行6： tar

/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -)

基本的に、すべてを再コピーしようとしますが、既存のファイルは無視します。1.7TBの既存のファイルを処理する必要がありますが、少なくとも1.2GB / minで読み取りを行っています。

これまでのところ、これは即座に満足を与える唯一のコマンドです。

更新：nohupでさえ、何らかの形で再び中断されました。

試行7：ハラキリ

まだこれを議論しています

試行8：スクリプト化された「マージ」 mv

宛先ディレクトリには約120kの空のディレクトリがあったので、実行しました

/home/data2/repo> find . -type d -empty -exec rmdir {} \;

Rubyスクリプト：

SRC  = "/home/data/repo"
DEST = "/home/data2/repo"

`ls #{SRC}  --color=never > lst1.tmp`
`ls #{DEST} --color=never > lst2.tmp`
`diff lst1.tmp lst2.tmp | grep '<' > /home/data/missing.tmp`

t = `cat /home/data/missing.tmp | wc -l`.to_i
puts "Todo: #{t}"

# Manually `mv` each missing directory
File.open('missing.tmp').each do |line|
  dir = line.strip.gsub('< ', '')
  puts `mv #{SRC}/#{dir} #{DEST}/`
end

できました。

大きなタスクを小さなタスクに分割することを聞いたことがありますか？

/ home / data / repoには1Mのディレクトリが含まれ、各ディレクトリには11のディレクトリと10のファイルが含まれます。合計2TBです。

rsync -a /source/1/ /destination/1/
rsync -a /source/2/ /destination/2/
rsync -a /source/3/ /destination/3/
rsync -a /source/4/ /destination/4/
rsync -a /source/5/ /destination/5/
rsync -a /source/6/ /destination/6/
rsync -a /source/7/ /destination/7/
rsync -a /source/8/ /destination/8/
rsync -a /source/9/ /destination/9/
rsync -a /source/10/ /destination/10/
rsync -a /source/11/ /destination/11/

(...)

コーヒーブレイク時間。

これは何が起こっているかです：

• 最初に、rsyncはファイルのリストを作成します。
• このリストの作成は、ファイルリストの最初の並べ替えのために、本当に遅いです。
• これを回避するには、ls -f -1を使用し、rsyncが使用するファイルセットを構築するためにxargsと組み合わせるか、ファイルリストを使用して出力をファイルにリダイレクトします。
• このリストをフォルダではなくrsyncに渡すと、rsyncがすぐに動作を開始します。
• 数百万のファイルがあるフォルダーに対するls -f -1のこのトリックは、この記事で完全に説明されています：http : //unixetc.co.uk/2012/05/20/large-directory-causes-ls-to-hang/

rsyncが遅い場合（なぜ遅いのですか？-zが役立つ場合があります）、多くのデータが移動したように聞こえるので、試してみてください：

--remove-source-filesを使用した場合は、空のディレクトリを削除してフォローアップできます。--remove-source-filesはすべてのファイルを削除しますが、ディレクトリはそこに残します。

ちょうどあなたが作るしないでください複数のパスを実行するために--deleteと--remove-ソース・ファイルを使用します。

また、速度を上げるために--inplaceを使用できます

サーバー上でこれをリモートで実行しようとしているために追い出された場合は、「スクリーン」セッション内で実行してください。少なくともその方法で実行できます。