OSDN -- オープンソース・ソフトウェアの開発とダウンロード
日本語の翻訳状況 translation status for ja
編集 | ページ一覧 |  最近の更新  | 
  • ページの履歴を表示しています #40988
  • ページの履歴を表示しています #48211
  • ページの履歴を表示しています #24622

問題点など

  1. 移動元のディレクトリから削除したのちに、移動先のディレクトリへの 登録が行われるため、どこのディレクトリからも参照されななくなる 瞬間がある。このタイミングでシステムがダウンすると、このファイルは 失われることになる。
  2. rename処理(ext2_rename)の途中で落ちると、リンクカウントが 1の状態のまま二つのディレクトリに登録されてしまう可能性もある。 このタイミングでシステムクラッシュしても、 fsckにより、容易に修復可能である。 ただし、fsck前にこのファイルを削除すると、存在しないiノードを 指すディレクトリエントリが残る。
  3. rename処理により上書きされたファイルがリンクされたもので あった場合、そのiノードが持つリンク数は遅延書き込みと なっているため、このタイミングでシステムがクラッシュすると、 実際にディレクトリに登録されている数より一つ大きいリンク数を iノードが保持してしまう。 これは、fsckにより容易に修復可能である。 もしfsckを行わずに運用した場合でも、このファイルの削除時に 浮きブロックとなるだけであり、ファイルシステム構造破壊には 継らない。
  4. 移動先のディレクトリの拡張が発生した場合、ディレクトリサイズを 保持する移動先ディレクトリiノードを同期書き込みしていない。 このタイミングでシステムがクラッシュすると、 移動したファイルが参照できなくなる可能性がある。 ただし、ファイルシステム構造の破壊に継るものではない。
  5. ディレクトリのrename処理において、".." の更新が 遅延書き込みになっている。システムクラッシュが発生すると、 移動したディレクトリに古い親ディレクトリ情報が残る ことがある。これもfsckにより容易に修正可能である。 もし、fsckなしで運用した場合でも、パスサーチルーチンは ".." の解決をVFSレベルで行ってしまうため、現在の版の linuxのアルゴリズムでは正常に動作してしまう。 しかし、このディレクトリを再びrenameしようとすると、 ".." のエラーチェックを行っているため、renameが失敗する。

(NIS)HirokazuTakahashi
2000年06月11日 (日) 22時29分57秒 JST1