Ext3のようなLinuxファイルシステムを作成すると、「lost + found」ディレクトリが作成されます。 this によると、何らかのシステムクラッシュによってファイルが破損した場合、ファイルはそこに配置されます。
このディレクトリが削除され、システムがクラッシュするとどうなりますか。フォルダーが削除された場合、mkdir lost + foundを使用して新しいディレクトリを作成するか、ファイルシステムの作成時にのみ設定できる属性がありますか? 。
fsckはlost + foundディレクトリがない場合、それを再作成します。
起動時に、ファイルシステムが正常にアンマウントされていないことが検出された場合、ほとんどのディストリビューションはfsckを実行します。 fsckはlost + foundディレクトリがない場合はそれを作成するので、それを作成し、見つかったものをそのディレクトリに配置します。
fsck
を実行できない、または実行したくない場合は、_ lost+found
を使用してmklost+found
ディレクトリを再作成できます。
mklost + foundは、ディスクブロックをlost + foundディレクトリに事前に割り当てます。これにより、e2fsck(8)を実行してファイルシステムを回復するときに、リンクされていない多数のファイルを格納するためにファイルシステムにブロックを割り当てる必要がなくなります。これにより、e2fsckがリカバリ中にファイルシステムにデータブロックを割り当てる必要がなくなります。
リンクされていない多数のファイルを格納するのに十分な大きさの既存のlost + foundディレクトリは、ディレクトリを作成して適切なサイズに拡大するためのe2fsckの負担を軽減します。
それでもそうしようとしますが、ファイルシステムが破損している場合は、さらにリスクが高くなる可能性があります。
他のプラットフォーム上の他のファイルシステム用の非常に古いfsckは、/ lost + foundを作成できず、拡張することもできませんでした。これは/ lost + foundの根拠の歴史です。しかし、現在の根拠は単にe2fsckの仕事を簡単にすることです。
ない場合lost+found
、e2fsck
(他のfsck
実装へのコードを検査していません)が、コードの作成を提案します。ただし、必要に応じて自分で再作成することもできます。そのディレクトリについては、特別なことは何もありません(少なくともコードの検査からは)。
e2fsckはlost + foundを再作成し、同じ名前の邪魔になる可能性のあるファイルも破棄して、ディレクトリとして作成できることを確認します。
多くの古いUnixファイルシステムでは、特にlost + foundをiノード番号2に接続するよう要求していたため、ほとんどの場合、ディレクトリが失われた場合にファイルシステムを再作成する必要がありました。 e2fsckは空きノードを検索するだけです。明らかにiノード2は特に必要ないため、昔よりもはるかに簡単にリカバリできます。
Mkdirを使用するだけでそのディレクトリを作成できます。ルートまたはホイールのいずれかのグループとともに、ルートによって所有されている必要があります。それ以外に特別なことは何もありません。システムの起動時に停電や不適切なシャットダウンが発生した場合、自動的にfsckが起動します。 fsckはシステムを通過し、検出した破損ファイルの回復を試みます。破損している可能性のあるすべてのファイルはそこに移動されます。
ファイルが移動されるもう1つのケースは、親のiノードが欠落しているファイルをfsckが見つけた場合です。これは通常、フォルダーのiノードが格納されている特定の場所にあるディスク上のブロックが破損した場合に発生します。親iノードをlost + foundフォルダーに再割り当てします。
編集:後者の場合にディレクトリが再作成されるかどうかはわかりません。安全のために、それはそのままにしておきます。削除する理由なんて考えられません。それなしでは悪いことは起こりません。
さらに、Debian 6およびUbuntu 12 LTSでは、cron
パッケージが/etc/cron.daily/standard
を出荷しました。これにより、ローカルファイルシステムのlost+found
ディレクトリが欠落していることに気づき、電子メールでそのことを毎日通知します。 mklost+found
の使用。
ただし、これは廃止されたため、それぞれDebian 7およびUbuntu 14 LTSの時点で削除されました。