Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is the purpose of the lost+found folder in Linux and Unix? (2014)

unix.stackexchange.com

Post reply on HN
Print view View original

91–95 of 95 posts

Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)

#91

Post by josephcsible »

trumpdong wrote: post #84
JdeBP wrote: post #10

Earlier quoted context omitted.

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.

> No, that would be reverted for "violating the author's intent" if you edited an existing answer

Can you link to an example of when that happened when it shouldn't have?

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

No it wouldn't. They added a new answer sort called "trending" and made it the default specifically to fix that problem.

Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)

#92

Post by JdeBP »

Taniwha wrote: post #72
Taniwha wrote: post #71

Earlier quoted context omitted.

I used to port Unix for a living (V6 thru SysVr3) I know it was in Vr2, and I have a man page that says "(last mod. 1/15/87)" which would likely make it SysVr1 or earlier

(My guess is that it dates from the introduction of fsck which from memory was V7 or later)

My guess is that it was undocumented until Release 3 or 4, so the book authors simply never found out about it. Andrew Tanenbaum knew about it at the same time as the first Hunter and Fielding book, but likely this was word-of-mouth stuff.

* https://groups.google.com/g/comp.unix.wizards/c/bbCYhh7_r-8/...

Enjoy the obvious question asked about all this, way back in November 1981:

* https://groups.google.com/g/fa.unix-wizards/c/h5mFGIV91Io/m/...

That's the Dave Yost, still at RAND at the time, who went on to make the GRAND Editor.

* https://news.ycombinator.com/item?id=43734536

Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)

#93

Post by ericbarrett »

trumpdong wrote: post #83
bityard wrote: post #80

Earlier quoted context omitted.

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.

This is true of XFS too; I have run it in production on both RedHat and Debian/Ubuntu based distros for decades and have never had issues after an FS full event. I usually reboot a server that has had the root FS full because sometimes service logging will not recover from write failures, but I've never had to xfs_repair.

Re: What is the purpose of the lost+found folder in Linux and Unix? (2014)

#94

Post by pkaye »

ExoticPearTree wrote: post #78
pkaye wrote: post #28

Earlier quoted context omitted.

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.

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 wou…

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.
Post reply on HN