web-dev-qa-db-ja.com

mvコマンドの奇妙な動作-おそらくオープンsys呼び出しの問題？

「open」システムコールに関連している（または関連していない）「mv」コマンドの非常に奇妙な動作に気づいています。 RedHatv5を実行しています。 2つの別々のストレージデバイスがあり、1つは「/ diskTo」にマウントされ、もう1つは「/ diskFrom」にマウントされます（この例の場合）。

通常の操作では、数千とは言わないまでも数百のファイルを/ diskFromから/ diskToに移動（mv'ing）しています。ファイルの大部分は正常に移動します。ただし、たとえば1000個のファイルのうち、1〜5個のファイルが失敗します。失敗は許可拒否エラーです。ファイルの宛先を確認すると、ファイルexistsですが、iノードの内容はごみです。たとえば、タイムスタンプはジャンク（ "1969"ですが、異なります）であり、アクセス許可は "0"です。

そのため、mvコマンドでstraceを実行し、失敗の出力をキャプチャする必要があると考えました。これが私が見つけたものです：

munmap(0x2b0328770000, 4096)            = 0
geteuid()                               = 31169
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90de9500) = -1 ENOTTY (Inappropriate ioctl for device)
stat("/diskTo/foo.dat", 0x7fff90de95d0) = -1 ENOENT (No such file or directory)
lstat("/diskFrom/bar.dat", {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0
lstat("/diskTo/foo.dat", 0x7fff90de9370) = -1 ENOENT (No such file or directory)
rename("/diskFrom/bar.dat", "/diskTo/foo.dat") = -1 EXDEV (Invalid cross-device link)
unlink("/diskTo/foo.dat") = -1 ENOENT (No such file or directory)
open("/diskFrom/bar.dat", O_RDONLY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0
open("/diskTo/foo.dat", O_WRONLY|O_CREAT|O_EXCL, 0400) = -1 EEXIST (File exists)
write(2, "mv: ", 4)                     = 4
write(2, "cannot create regular file `/diskTo"..., 76) = 76
write(2, ": File exists", 13)           = 13
write(2, "\n", 1)                       = 1

ご覧のとおり、nlinkが呼び出され、-1が返されます。これは、ファイルが存在しないことを示しています。次に、「mv」はファイルをopenしようとし、EEXISTエラーを受け取ります。しかし、ファイルはおそらく存在できません！ここではこれを示していませんが、このテストケースを作成しているスクリプトは、一意の番号を使用してディレクトリを構築しています。したがって、ファイルが実際に存在する可能性はほとんどありません（不可能ではないにしても）。言うまでもなく、nlinkは、ファイルが存在しなかったことを証明します。

これは、openがiノードのコンテンツをどのように作成しているかに関する問題でしょうか？この時点でどこを見ればよいのかわかりません。たぶん、「mv」をもっと調べたり、「オープン」システムコールを調べたりしますか？

fedorafilesystemsrhelrenameopen-files
2
Jmoney38

ディスク上で完全なfsck(8)を実行すると、混乱したiノードが浮かんでいる（またはオンザフライで作成されている）ように見えます。 badblocks(8)を実行して、ディスクに問題がないかどうかを確認します。ログ（または他のディスク診断）がそれについて何かを言っているかどうかを確認します。

すべてのソフトウェアは最新ですか？

これらはどのファイルシステムですか？ diskToで他に干渉している可能性のあるアクティビティはありますか？たまたまディスクがほぼいっぱいになっていますか（スペース、iノード）？ログに他のレポートはありますか？

また、マシンを徹底的にチェックします。メモリエラー可能性があります過熱する可能性があるため、このような原因になります。これは非常にありそうもない原因ですが、分解してファンをチェックしても問題はないので、正常に動作しており、中規模の農場に十分な土がありません。マシンがUPSなどに接続されていない場合、電圧変動によってランダムエラーが発生する可能性もあります。

1
vonbrand