41–50 of 95 posts
Earlier quoted context omitted.
You need to use worse hardware and bad power :)
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.
Earlier quoted context omitted.
XFS does use /lost+found, it calls it the "orphanage directory" and xfs_repair reparents children of corrupt directories there. 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.
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…
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.
That would be a much cleaner approach, imho.
Added benefit is that you'd immediately see it if something is wrong with a disk.
I 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+…
Earlier quoted context omitted.
Yea, run an old kernel with ext2 on a busy system writing a bunch of small files and have a power supply fail and you'll end up with something there. fsck on large hard drives was scary on how long it could take to finish.
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.)
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.
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
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.
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.
Earlier quoted context omitted.
Yea, run an old kernel with ext2 on a busy system writing a bunch of small files and have a power supply fail and you'll end up with something there. fsck on large hard drives was scary on how long it could take to finish.
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 recall going to sleep and it still not being done when I woke up. Bleh.
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.
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…
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.