HN Debrief

What is the purpose of the lost+found folder in Linux and Unix? (2014)

  • Infrastructure
  • Open Source
  • Storage
  • Linux

The linked post answered a very old Unix question that still confuses people because the directory mostly sits there empty. `lost+found` is a recovery bucket used by filesystem check tools like `fsck` when they find files or directory entries after corruption but cannot reconstruct the original parent directory. On classic Unix and ext-family filesystems, that directory was often created in advance and even pre-sized so repair could work without needing to allocate fresh metadata on a damaged or nearly full disk.

If you run ext-family filesystems, `lost+found` is still part of your disaster path, not clutter. Do not delete it casually, and if you operate XFS or other newer filesystems, check how their repair tools handle orphaned files before you need them in production.

Discussion mood

Mostly practical and mildly nostalgic. People treated `lost+found` as an old but real recovery mechanism, with a lot of “you only notice it when things are already bad” energy, plus war stories from ext2, bad power, SD cards, and long `fsck` runs.

Key insights

  1. 01

    XFS creates it only during repair

    XFS does not normally ship with a permanent `lost+found` directory sitting at the root the way ext filesystems often do. `xfs_repair` creates one only when it has recovered orphaned entries that need somewhere to go, and after you inspect or move anything useful, that directory is usually meant to be deleted.

    Do not assume every Unix-like filesystem has the same steady-state layout. If you standardize on XFS, document `xfs_repair` behavior and post-recovery cleanup now, not during an outage.

      Attribution:
    • jcalvinowens #1
    • adrian_b #1
  2. 02

    Preallocation was part of the design

    Older implementations were built around the ugly reality that recovery might run on a damaged or nearly full filesystem. `mklost+found` pre-allocated directory space so `e2fsck` could attach recovered files without asking the filesystem for new blocks or new directory growth at exactly the worst moment.

    That odd empty directory exists for a reason tied to failure handling, not aesthetics. If you are cleaning up base images or filesystem templates, leave recovery structures alone unless you know the exact repair semantics.

      Attribution:
    • layer8 #1
    • JdeBP #1
  3. 03

    Full XFS volumes can turn recovery ugly

    One operator described XFS on RHEL8+ behaving badly when a boot-mounted volume fills completely, with blocked tasks, journal trouble, and a recovery path that can require dropping into initramfs or a live disk to run `xfs_repair`. A follow-up tip said truncating a file can free space without updating metadata, which may buy enough room for the log to start cleaning itself up.

    If you rely on XFS for critical boot-time volumes, test your “disk full” runbook instead of assuming journaling will save you. Keep emergency procedures for freeing space and offline repair close at hand.

      Attribution:
    • Tsiklon #1
    • esseph #1
  4. 04

    Journaling alone does not remove recovery buckets

    A commenter building ZeroFS said they almost needed a `lost+found` even with a write-ahead log, because the hard part is not just logging updates but guaranteeing the exact ordering between memory state and what reaches disk. They only avoided recovery through atomic, strictly ordered commits, which was much more invasive than “just add a journal.”

    Do not treat a journal or write-ahead log as proof that post-crash salvage is unnecessary. When evaluating storage systems, ask what corruption and crash consistency guarantees they actually provide beyond the presence of a log.

      Attribution:
    • Eikon #1
  5. 05

    Some old systems expected it to exist

    On older Unix variants, `lost+found` was not merely a convenience for later repair. It could be part of what `fsck` assumed would already be there, and removing it could make the next boot-time recovery fail in surprisingly messy ways.

    On legacy systems, avoid deleting unfamiliar top-level directories just because they look empty. Verify whether they are part of the filesystem’s repair path before cleaning them up.

      Attribution:
    • NelsonMinar #1
  6. 06

    Recovered trees can be more intact than expected

    One ReiserFS recovery story is a useful reminder that `lost+found` is not always just nameless fragments. `reiser_fsck` reportedly reconstructed most files with much of the original directory tree still intact, then anchored the salvage under `lost+found`.

    When you do end up with recovered files there, inspect carefully before writing them off as junk. Some repair tools preserve far more structure than the directory name suggests.

      Attribution:
    • zer0zzz #1

Against the grain

  1. 01

    Modern filesystems often make it irrelevant

    For many current Linux users, an always-empty `lost+found` is a sign that better recovery paths are doing their job. With journal or intent-log replay, some filesystems can either recover cleanly or reconstruct enough metadata that files go back where they belong, so the visible salvage bucket rarely comes into play.

    If your fleet runs newer filesystems and sane hardware, do not over-index on this directory as an operational signal. Focus more on the actual repair guarantees of your filesystem than on whether `lost+found` exists.

      Attribution:
    • FerretFred #1
    • JdeBP #1
  2. 02

    The old sizing requirement feels alien now

    The note that administrators once had to pre-size `lost+found` by creating and removing entries underlines how much manual filesystem housekeeping used to leak into normal operations. From a modern usability standpoint, that design looks crude and outdated even if it solved a real recovery problem at the time.

    Legacy filesystem behavior often reflects repair constraints that newer systems hide. When migrating old operational habits, separate what is still necessary from what is just historical baggage.

      Attribution:
    • valleyer #1

In plain english

ext2 ↩
An older Linux filesystem that lacked journaling, making long recovery checks after crashes more common.
fsck ↩
File system check, a utility that scans and repairs filesystem inconsistencies after crashes, power loss, or corruption.
initramfs ↩
An initial RAM filesystem used during Linux boot that can provide a minimal environment for repair before the main system starts.
journaling ↩
A filesystem technique that records intended metadata or data changes in a log so the system can recover more safely after a crash.
lost+found ↩
A special directory used by some Unix and Linux filesystem repair tools to store recovered files whose original location can no longer be determined.
metadata ↩
Data that describes filesystem structure, such as filenames, directory entries, permissions, and block locations.
ReiserFS ↩
An older Linux filesystem known for its tree-based design and now largely obsolete.
Ultrix ↩
A Unix operating system from Digital Equipment Corporation based on BSD Unix.
XFS ↩
A high-performance filesystem commonly used on Linux systems, with its own repair tool and recovery behavior.
xfs_repair ↩
The XFS-specific utility used to repair damaged XFS filesystems.
ZeroFS ↩
A filesystem project mentioned in the comments as an example of crash consistency design without needing a recovery bucket.

Reference links

Filesystem repair references

  • mklost+found(8) manual page
    Explains why `lost+found` was pre-allocated so recovery tools could use it without allocating new blocks during repair.

Crash consistency and filesystem design

  • ZeroFS repository
    Cited as an example of a filesystem that almost needed a `lost+found`-style recovery area despite having a write-ahead log.
  • ZeroFS write coordinator source
    Linked to show the atomic and strictly ordered commit logic used to avoid needing recovery.

Meta discussion on Stack Overflow