glad to see that Stack Overflow (or stackexchange.com) is still a thing.
What is the purpose of the lost+found folder in Linux and Unix? (2014)
51–60 of 95 posts
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#52Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#53Why can't a filesystem create the lost+found folder only when it needs to store files in it? That would be a much cleaner approach, imho. Added benefit is that you'd immediately see it if something is wrong with a disk.
Because you need to pre-allocate space and indies for it in case things go wrong and the disk is almost full
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#54Earlier quoted context omitted.
XFS filesystems do not have a "/lost+found" directory in their normal state. In the very rare occasions when one has to run "xfs_repair", it will create a "/lost+found" directory, if it is required for recovered files. After the repair and after investigating whether the recovered files contain useful data or not (and after moving the useful files elsewhere), one should normally delete the "/lost+found" directory, be…
XFS as implemented in RHEL8+ (the only places i've used it in anger) tends to handle being full very badly, leading to system lockups and blocked tasks necessitating a hard reboot. Worse yet is when it's in this state the journal fills and nothing can be done with the volume. To recover from this on a volume mounted at boot mandates going to either a live disk, or stopping boot in initramfs and running xfs_repair the…
XFS tip:
If you truncate a file it doesn't update metadata. That's how you can get back space for the journal log to start cleaning up crap without rebooting the box and/or taking services down.
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#55Earlier quoted context omitted.
The occassional "Drive has not been checked in days, forcing check" message on bootup got annoying sometimes, yeah. It could easily take tens of minutes to finish, exactly when I wanted to use the computer! (At least this is what my memory is telling me. I could be mistaken, but that's what I remember.)
I had a largish raid back then, under ext2, may have been a massive 40G. I recall going to sleep and it still not being done when I woke up. Bleh.
One of several reasons to partition a large volume into smaller ones. At least, back then.
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#56Earlier quoted context omitted.
The occassional "Drive has not been checked in days, forcing check" message on bootup got annoying sometimes, yeah. It could easily take tens of minutes to finish, exactly when I wanted to use the computer! (At least this is what my memory is telling me. I could be mistaken, but that's what I remember.)
"check forced", as though the machine is advising me to go look at some daemon named forced.
Forced sounds like a systemd service for Jedi stuff.
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#57Earlier quoted context omitted.
I used to develop SSD firmware and one of things I worked on is making it robust to power failure. The power supplies have lots of capacitance so the voltage drop was slow so we would use a special test board that would disconnect from power and discharge fast to test it.
My main experience is with pre-scsi/ide systems :)
ESDI?
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#58I have a book on my bookshelf, Eric Foxley's Unix for Super-Users . It was published in 1985, and it answers this question on page 52, the first page listed for the entry 'lost+found' in its index. This is surely not the earliest book mention, is it? (It'll be in earlier man pages, of course.) Google Books does not give me an earlier one, although it does yield another 1985 book. Fun fact: Foxley cautioned that lost+…
How do you size a directory? Just by creating entries in it and then unlinking them?
Usually the filesystem driver provides an API call that sets the appropriate data structures so that the directory entry table is preallocated.
The ext-family filesystems provide the mklost+found command to tap into this call if you need to recreate the lost+found directory specifically.
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#59The lost+found folder saved our backs once way back when. We had a 1TB NAS running Linux, an enormous amount of storage back then. It was shut down unexpectedly and disorderly and ran a multi hour fsck upon reboot. The volume must have had a shot root inode, as after the machine booted and mounted the volume it was empty. All directories were luckily under lost+found with all their contents.
Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)
#60Earlier quoted context omitted.
As the submission explains, the lost+found folder has pre-allocated space for the directory entries. From the mklost+found man page [0]: mklost+found pre-allocates disk blocks to the lost+found directory so that when e2fsck(8) is being run to recover a file system, it does not need to allocate blocks in the file system to store a large number of unlinked files. This ensures that e2fsck will not have to allocate data…
> Preallocating space without making the directory visible would require more arcane file system magic. If those filesystem engineers had a manager that said: make this nice for the user, then it would have been done. But these developers had no managers and were OK eating their own unpalatable dogfood.
You greatly overestimate the capabilities of computers of the era that this originated in. Major limitations of disk space, speed and addressability combined with limited CPU power and RAM mean that your hypothetical, “it could have been done” would require a significant investment in development and runtime resources all to avoid having a directory in root that would be empty until after a post-crash recovery.
Also remember that these systems would have all been multi-user time-sharing systems, not desktop computers.