[0] 備忘…と言うには検証不足。Linux上で異なるサイズ・同名の2ファイルをある同一のファイルに上書きしようとした場合-[Id of Radiance ver.5]





■ 備忘…と言うには検証不足。Linux上で異なるサイズ・同名の2ファイルをある同一のファイルに上書きしようとした場合

 …現象的になんとも言いかねる話でひょっとしたら世の中的に当たり前なのかもしれないけどなんか納得しかねるのでとりあえず備忘。

 Linux上のある2ヶ所に同名のファイルがあったとします。まあ最終的に同じ名称のファイルにコピーされればよいので別に同名でなくても良いのですが、話を簡単にするためにとりあえずそうしときます。
  例:
    /home/aaa/test.txt
    /home/bbb/test.txt
 ところがこの2ファイル、名前は同じだけども中身は全く別物で、例えば「~/aaa/test.txt」は1GB、「~/bbb/test.txt」は1KBだったとします。

 で、これをほぼ同時に、同一のパスとしてコピーします。ただし「サイズの大きい方を若干先に」実行し、その実行が完了する前に「サイズの小さい方を実行」します。
  例:
    cp /home/aaa/test.txt /home/ccc/
    cp /home/bbb/test.txt /home/ccc/  ←数秒後に実施(上書き実施)

 まあ多分何をしたいかは見ればお分かりかと思いますが同一ファイルに対する同時コピー時の排他制御はどー動くのかを確認したかったわけです。
 期待値としては「後からのコピーは拒否されて先にコピーされたファイルが残る」か「先のコピー終了後に後のコピーが実行されて入れ替わる」のどちらか…だったわけですが、コレがやってみると「先の(大きい)ファイルの先頭だけ後の(小さい)ファイルの中身が合成されたファイルが出来上がった」モノだからびっくり。
 より具体的には
  ・後から実行した小さいファイルのコピーが先に終了。
  ・最終的なファイルサイズは先に実行した大きいファイルのもの。
  ・小さいファイルの内容分、大きいファイルの先頭バイトが置き換わっている。
…とゆー状態。これがサイズがある程度近くなると発生せず、この場合後からコピーされた物が有効になってる様子(完全には未確認)。改めてmd5で比較したら別物になってました。

 まー内部的な挙動は想像できるのでそう不思議な話じゃないかもしれないけど、そんな同時コピーくらいでファイルが合成されるなんてのがしょっちゅう起きてたら世の中もっと騒いでてもいいんじゃないかなぁと思いつつ、そんな話は聞いたことないので実は大した話じゃない、既に解決策がある、実はオマエが無知なだけだpgr、って話だったりするのだろうか…うーむ。

 ちなみに環境としてはCentOS5.7上のext3、CentOS6.2上のext4どちらでも確認。
 更に言えば元々の発端は最近何度か話題に出してる「GlusterFS」で、異なるクライアントから同一ファイルに対し同時コピーしたらどうなるねん、という排他の確認が発端で、その際にわかりやすくするために極端にサイズが異なるのを使ってみた、ってだけだったわけですが。当然その際にもファイルが合成されたもんだから、うげ、GlusterFSって排他処理やってないのんか…と思ったら実は要因はそこではなかったという話。まあGlusterFSの要因ではないようなのでむしろ軽く安堵したわけですが。

 初期のext4には色々遅延系で問題があったらしいのでそれに起因したりしてるのかなぁ、と思ったらext3でもそうだし。いくらコピー時に「上書きしていいですか?→y」としたとしてもそーゆー「上書き」ではないよなぁ(苦笑)。世の中他の人はどうなってるんだろう。

関連タグ:Linux
2012-05-01 [技術]

関連記事: