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

"check forced", as though the machine is advising me to go look at some daemon named forced.

Forced sounds like a systemd service for Jedi stuff.

These are not the inodes you're fscking for.

I had a largish raid back then, under ext2, may have been a massive 40G.

I recall going to sleep and it still not being done when I woke up. Bleh.

One of several reasons to partition a large volume into smaller ones. At least, back then.

I always turned this off, and also, cursed myself when I forgot to turn it off.

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.

Thank you for your service!

My main experience is with pre-scsi/ide systems :)

ESDI?

SMD

You would flush the SSD memory to "disk", right?

When you have dirty writes in the kernel that have not yet been written to disk, in the old days of ext2 (before XFS was ported to Linux) if the power would go out, or you would have a bad disk, when fsck.ext2 would run, if files could not be matched to a directory, they would placed in the /lost+found as, and hopefully my memory is intact, as inode numbers, so you would have 1232342343, 123246564 etc and then you would have to look at each file to figure out what it was and where to move it if it was salvageable.

Brought back some memories.

The testing was at the drive level without an OS like ext2. The test was with no flush (with flush test is easy to pass). Without PLP, the pass criteria is that the data that was buffered can be either the older or newer data and not corrupted or previous data. All the other blocks on the SSD should remain unchanged. Its trickier that you think because MLC/TLC NAND could corrupt other blocks due to NAND structure and we had to deal with that. Then you also have to worry about system data in the NAND doesn't get corrupted.

And more concurrent writes.

But I think ext4 will only let things appear there if you change some default flags.

Umm .. how about a Raspberry Pi Zero 2W powered by a 2000MaH " lipstick style" powerbank?

Yeah, I think lack of any decent hardware RAID could be a prerequisite.

That's what the answers are missing, of course. In some filesystem formats, it's possible either to recover completely from a journal/intent log, or at least to recover everything to the point that recovered files can be placed into the correct directory.

Have to run fsck. This used to be forced about once a month but don’t remember it happening in the last decade or so.

Same here. And I had some pretty f**ed up file systems.

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.

My SD cards have always had stuff in that folder. It scares me. I try not to look

> In a couple of decades running Linux installations of all flavours, I have never seen anything in lost+found!

I saw it often. Running fsck on a crashed/failed partition usually does put some files in there. Maybe I kept using old hardware too long...