From what I googled XFS, Btrfs and ZFS don't use lost+found. It's a thing of the old not journaled filesystems and of the ext family.
Based on comments in the kernel source, it seems like the userspace fsck for JFS and F2FS will also sometimes create /lost+found. There might be more that do.
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, because it is no longer needed.
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 there, I've fruitlessly attempted to play back the journal on many separate occasions by attempting to mount the filesystem (again causing a lock up due to no space) in that state you have to drop the journal, run xfs_repair and then clean up the detritus from /lost+found (and then the location that caused the disk to fill altogether).
EXT4 has other issues certainly, but at least it reserves blocks for the root user explicitly so the system doesn't stop.
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.
ZeroFS ended up not needing recovery at all through atomic, strictly ordered commits [1], but it was far from trivial (and not just a matter of requiring a WAL).
[0] https://github.com/Barre/ZeroFS
[1] https://github.com/Barre/ZeroFS/blob/main/zerofs/src/fs/writ...
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+found must be pre-sized ahead of time, because the fsck of the time did not grow the directory to fit found files.
fsck on large hard drives was scary on how long it could take to finish.
(At least this is what my memory is telling me. I could be mistaken, but that's what I remember.)
I recall going to sleep and it still not being done when I woke up. Bleh.
But I think ext4 will only let things appear there if you change some default flags.
At one point, I had one where the directory structure was completely broken and had circles in it (broken SSD). To be fair, in that particular case, I did not look for lost+found and just wrote a tool to extract the data manually that I was looking for.
* Probably DEC Ultrix 2.2, a BSD 4.2 derivative.
That would be a much cleaner approach, imho.
Added benefit is that you'd immediately see it if something is wrong with a disk.
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.
[0] https://man7.org/linux/man-pages/man8/mklost+found.8.html
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.
https://sherwood.news/tech/stack-overflow-forum-dead-thanks-...
Fortunately I was using ReiserFS at the time and something about its murderous tree data structure made it trivial to undelete.
Reiser_fsck found ALL my stuff, mostly with full dir tree structure in tact and put it all in lost+found
In reallife I would rename this to "trash".
Thing is, any time I try to replicate something like that, I basically get a flippant response saying to go look elsewhere.
I also respect human responses over AI ones every day that ends in Y.