Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When you create some Linux filesystems like ext3 a 'lost+found' directory is created. According to this files will be placed there if files were damaged from some kind of system crash.

What happens if this directory is removed, and the system crashes. If the folder is removed can I just create a new directory with mkdir lost+found or are there attributes that can only be set when the filesystem is being created.

share|improve this question

6 Answers 6

up vote 24 down vote accepted

fsck will recreate the lost+found directory if it is missing.

On startup most distributions run fsck if the filesystem is detected as not being unmounted cleanly. As fsck creates the lost+found directory if it is missing, it will create it then and place anything that it finds into that directory.

share|improve this answer

If you have no lost+found, e2fsck (I have not inspected the code to other fsck implementations) will offer to create it for you. But, you can recreate it yourself if you want, too; there's nothing particularly special about that directory (at least not from inspecting the code).

share|improve this answer
2  
fsck should recreate lost+found if needed, no? –  David Schmitt May 10 '09 at 7:07
2  
Thanks, I've checked the code for e2fsck and indeed it does offer to recreate it for you. (This is not guaranteed to succeed though---which is why a pre-created lost+found is useful too.) Neat! –  Chris Jester-Young May 10 '09 at 14:54
1  
@ChrisJester-Young - Your answer is incorrect. lost+found is a special directory. It has pre-allocated disk blocks so that recovery tools don't need to allocate blocks during recovery. Tools like mklost+found exist specifically because mkdir won't create it properly. See linux.die.net/man/8/mklost+found –  aggregate1166877 Oct 3 '13 at 7:25

A pre-existing lost+found directory with a large enough size to contain a large number of unlinked files puts less of a burden on e2fsck to create the directory and grow it to the appropriate size.

It will still attempt to do so, but in the face of a corrupt filesystem, it can be more risky.

Very old fsck's for other filesystems on other platforms were not able to create /lost+found, nor were they able to grow it. This is the history for the rationale of /lost+found. But the current rationale is simply to make e2fsck's job easier.

share|improve this answer
1  
It isn't that they couldn't create the lost+found -- it is that it is a bad idea to create files / directories on a filesystem that's already screwed up. Instead, you just prebuild a directory that's already big enough to store the directory entries of whatever munched inodes you find in a screwed-up filesystem when you're trying to clean it up. –  chris Jul 23 '13 at 2:56

If you can't or don't want to run fsck, you can recreate the lost+found directories with mklost+found:

mklost+found pre-allocates disk blocks to the lost+found directory so that when e2fsck(8) is being run to recover a filesystem, it does not need to allocate blocks in the filesystem to store a large number of unlinked files. This ensures that e2fsck will not have to allocate data blocks in the filesystem during recovery.

share|improve this answer
    
At RHEL 6.4 nor fsck neither e2fsck where re-creating this for me, no matter if the directory was mounted or not. cd <root-dir-of-the-mount> && mklost+found did it. –  Luis Antolin Nov 18 at 19:11

You can create that directory just using mkdir. It should be owned by root, with a group of either root or wheel. Other than that there isn't anything especially special about it. In the event of a power failure or improper shutdown when the system boots it should automatically launch fsck. fsck will go through the system and try to recover any corrupt files that it finds. Any files that it comes across that are potentially corrupted will get moved there.

The other case for files to be moved there is if fsck finds a file whose's parent inode is missing. This is usually the case if a block gets corrupted on the disk in the specific location where a folder's inode is being stored. It will reassign their parent inode to be the lost+found folder.

Edit: I am unsure if the latter case will recreate the directory. I would leave it alone to be on the safe side. I can't think of any reason to delete it. Nothing bad will happen without it though.

share|improve this answer
    
Are you sure it is ok just to create with mkdir? –  Jack Douglas Feb 5 '13 at 0:50
    
Yes it is, the space allocation is not tied to the directories inode or even the path. The reserved space allocation is more a less a flag on some memory that requires root/kernel privileges and special calls to access which fsck is aware of, it just makes use of that space by copying potentially corrupt or broken files into that memory and creating a file with an inode pointing at the new memory. File operations will behave normally on those files but any changes such as moving or saving will pull the data out of the reserved memory. –  TrueDuality Apr 12 '13 at 15:05

e2fsck will recreate lost+found, and will also destroy any file that might be in the way with the same name to make sure it can create it as a directory.

Note that many older Unix filesystems demanded that lost+found be attached to inode number 2 specifically, hence a need to recreate the filesystem in most cases if the directory got lost. e2fsck simply does a search for any free inode, apparently not specifically needing inode 2, which makes recovery much simpler than the old days.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.