If you run
fsck
, the filesystem check and repair command, it might find data fragments that are not referenced anywhere in the filesystem. In particular, fsck
might find data that looks like a complete file but doesn't have a name on the system — an inode with no corresponding file name. This data is still using up space, but it isn't accessible by any normal means.
If you tell
fsck
to repair the filesystem, it will turn these almost-deleted files back into files. The thing is, the file had a name and location once, but that information is no longer available. So fsck
deposits the file in a specific directory, called lost+found
(after lost and found property).
Files that appear in
lost+found
are typically files that were already unlinked (i.e. their name had been erased) but still opened by some process (so the data wasn't erased yet) when the system halted suddenly (kernel panic or power failure). If that's all that happened, these files were slated for deletion anyway, you don't need to care about them.
Files can also appear in
lost+found
because the filesystem was in an inconsistent state due to a software or hardware bug. If that's the case, it's a way for you to find files that were lost but that the system repair managed to salvage. The files may or may not contain useful data, and even if they do they may be incomplete or out of date; it all depends how bad the filesystem damage was.
On many filesystems, the
lost+found
directory is a bit special because it preallocates a bit of space for fsck
to deposit files there. (The space isn't for the file data, which fsck
leaves in place; it's for the directory entries which fsck
has to make up.) If you accidentally delete lost+found
, don't re-create it with mkdir
, use mklost+found
if available.
Comments
Post a Comment