← Back to context

Comment by amelius

13 hours ago

Why 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.

8 comments

amelius

Reply
JdeBP  4 hours ago

Chicken and egg problem.

On the UFS and suchlike filesystems, at the point that fsck is rescuing orphaned i-nodes, it still has not fully gone through the process of checking and correcting free list information, or indeed fully eliminating errors from the i-node table. Creating a directory involves allocating a new i-node from an unused slot, and free blocks off the free block list.

Ironically, because they are slightly or grossly different to Unix filesystem formats, on HPFS and FAT this is less of an issue. (FAT usually has unused slots in the root directory that it is sane to use at that point, for example.) CHKDSK on OS/2 did create its \FOUND.nnn files on the fly.

layer8  13 hours ago

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 blocks in the file system during recovery.

Pre-allocating space without making the directory visible would require more arcane file system magic.

[0] https://man7.org/linux/man-pages/man8/mklost+found.8.html

  • amelius  13 hours ago

    > 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.

    • dhosek  9 hours ago

      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.

      1 reply →

ivlad  12 hours ago

Because you need to pre-allocate space and indies for it in case things go wrong and the disk is almost full