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 always turned this off, and also, cursed myself when I forgot to turn it off.
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…
You are going to have a bad time when your / filesystem fills up, regardless of the filesystem type. This is one of the reasons for separate /usr, /var, /home, etc that many seem to have forgotten. Smaller blast radius when there is a problem. The reserved space in ext4 doesn't do you any good if root is the user that filled up the disk in the first place, which is far and away the most common thing I see.
On servers I've usually had a bad time when / fills up. But using Linux as a desktop with ext4 I regularly fill the file system up (laptop with a too small SSD, so this happens quickly when batch downloading) and nothing bad happened so far. Which is approximately the same experience I have on Windows
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…
You are going to have a bad time when your / filesystem fills up, regardless of the filesystem type. This is one of the reasons for separate /usr, /var, /home, etc that many seem to have forgotten. Smaller blast radius when there is a problem. The reserved space in ext4 doesn't do you any good if root is the user that filled up the disk in the first place, which is far and away the most common thing I see.
On ext4 things will start failing with -ENOSPC but recovery is as simple as deleting files that are taking up space - which may or may not require a reboot into single-user mode depending on how badly the running system is borked - but the filesystem remains intact, you don't have to drop the journal, you don't have to run fsck or any other repair tool. You can just delete files and get the space back.
It is StackExchange. So in theory someone could modernize it at any time.
No, that would be reverted for "violating the author's intent" if you edited an existing answer, and if you posted a new answer it'd be permanently at the end of the list because it would never attract many votes due to being at the end of the list.
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…
Sorry, but I just don't believe all this. We're talking about hiding a folder. Of course the developers could do that.
It's at the root level, no user came near that back then so it was kinda hidden.
rmdir /lost+found is always my first step after creating and mounting a new file system. Reserving a user-visible directory just so that a 0.00001% chance recovery is slightly easier just doesn't make any sense.
I have recovered files several times after fsck on a failed partition. I may have a 75 percent success rate with this... did not keep statistics obviously.
Though it could be less, cause I also remember recovering files with foremost on a dd copy of a disk.
rmdir /lost+found is always my first step after creating and mounting a new file system. Reserving a user-visible directory just so that a 0.00001% chance recovery is slightly easier just doesn't make any sense.
I have recovered files several times after fsck on a failed partition. I may have a 75 percent success rate with this... did not keep statistics obviously. Though it could be less, cause I also remember recovering files with foremost on a dd copy of a disk.
You'll still be able to recover files - fsck will just recreate the directory. There is a slight chance that if the free list is fucked that this will loose you a couple of more blocks of data but then you're already well into fubar territory anyway.
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…
Sorry, but I just don't believe all this. We're talking about hiding a folder. Of course the developers could do that.
well sure, they could have named it .lost+found instead of lost+found, but you’re overestimating the value of hiding it.