When e2fsck'ing an ext3 fs which was not closed (e.g. power fail etc) e2fsck always clears orphaned inodes.
I think these orphaned inodes may sometime contain useful information (e.g. previous copy of a file whose "new" copy is actually invalid because of the crash). So -
would it be possible for e2fsck to have an option to create a temp link in the directory for orphaned inodes instead of clearing them? So I can inspect them and decide.
So if this is a case where the application is incompetently written and not using fsync() to flush out the new file before deleting the old file, it's unlikely that it will be orphaned. A file will end up in the orphaned state most commonly when the application has deleted a file while keeping a file descriptor open on the file, and that's not commonly what goes on when the application is overwriting a file on a save command; if the file is closed the only time a file will be left on the orphaned list if it is in the middle of being deleted across a journal commit. So if you are deleting a very large file, and you crash in the middle of deleting that very large file, you might be able to recover part of that large file. But in the case of a relatively small (i.e. under a few hundred kilobyte) file, it's highly unlikely any such file will be what you will find on the orphaned list.
Most commonly, it will be some scratch/tmp file that the application has opened and then immediately deleted, precisely so that it will be automatically cleaned up if the application crashes or exits, or if the system crashes. More rarely, if you are deleting a huge ISO image, you might have a partially deleted large file on the orphaned file list, but in the case of someone who is composing an HTML file using a crappy text editor that doesn't use fsync() correctly, I want to make sure expectations are set that you're not going to have much luck in that case. Better that you use a properly written text editor (i.e., vi, emacs), and not a crappy one (i.e., one that ships with KDE or GNOME).
Just to add -- I'm not against adding such a feature, but it's not high on my priority list. If you'd like to add a feature like that, feel free to send me a patch. That is the open source way, you know. :-)
Thanks Theo. I should have probably used a different word than "corrupt" - I meant something more like "not usable" or "inconsistent with everything else (which was not yet updated)". I have occasionally found strange problems after e2fsck'ing a not-properly-closed ext3 and always wondered - maybe I could have restored one of those orphaned files.
It is a chicken and egg - In order to find out, I need that feature, and I need to find out in order to know if the feature is useful.
Certainly if they are always only scratch/tmp then it's not needed.
Fair enough that you don't want to do it - I might - how difficult would it be?
Well, I coded this up (against 1.41.13) and got it working, and a few days later had a crash to try it out on.
And you were (of course) quite right - all looked very much like temp files that had been unlinked while open.
Specifically, of the 6 orphaned inodes it rescued, all 6 were the same size (217016 bytes)
and content of each was mostly zeros with some occasional strings resembling network information (IP names and such).
So then I thought to see if, while running normally, lsof could find me some unlinked files, and it did :
lsof | fgrep deleted
nscd 13564 nscd 4u REG 8,19 217016 2032934 /var/run/nscd/dbgZwLAF (deleted)
nscd 13564 nscd 5r REG 8,19 217016 2032934 /var/run/nscd/dbgZwLAF (deleted)
nscd 13564 nscd 6u REG 8,19 217016 2032938 /var/run/nscd/dbgJeFHa (deleted)
nscd 13564 nscd 7r REG 8,19 217016 2032938 /var/run/nscd/dbgJeFHa (deleted)
nscd 13564 nscd 8u REG 8,19 217016 2032939 /var/run/nscd/dbEBoNOF (deleted)
nscd 13564 nscd 9r REG 8,19 217016 2032939 /var/run/nscd/dbEBoNOF (deleted)
So they are some kind of nameserver cache.
I did learn a few things while doing this - including one point I had not realized.
There are two kinds of orphaned inodes -
1. known to be orphaned before the crash (i.e. the pre-crash system has explicitly marked them as orphaned by placing them on a special "orphaned" list )
2. discovered to be orphaned by e2fsck during its passes (i.e. not marked in any way but also not referenced by any directory entry)
And the type this thread is referring to is type 1. I think e2fsck always saves type 2.
Maybe this is all documented somewhere?
If you think my patch might be useful, let me know and I'll send it in .
Log in to post a comment.