Corruption in reiserfs partition

jorgepeixoto · Posted: Thu Sep 06, 2007 5:06 pm Post subject: Corruption in reiserfs partition

Hi. My computer crashed (probably due to hardware problems in my TV capture card) and when it was rebooting, it started the automatic fsck. Since the fsck was taking too long, and I was in a hurry to use the computer, I rebooted it and booted from another partition. AFAIK it is not dangerous to interrupt a fsck, unless of course you are in the middle of an operation like --rebuild-tree. The fsck was checking, not fixing.

From this other parition, I issued fsck and got:

Sadako · Posted: Thu Sep 06, 2007 5:33 pm Post subject:

All I can tell you is that I've used --rebuild-tree more than once, and have never incountered any problems with it (but I have heard about some horror stories when using it).

I'd backup whatever you can and then use --rebuild-tree, I wouldn't even consider continued use of the filesystem in it's current state an option at all.
_________________
"You have to invite me in"

Habbit · Posted: Thu Sep 06, 2007 5:34 pm Post subject:

ReiserFS is not precisely known for its armouring against on-disk corruptions, so if you have anything like that, it is extremely probable that you will lose some data. If you try to use the partition as it is, you risk that some day, reiser will just refuse to mount the partition at all, locking you away from your data. However, fsck --rebuild-tree is a very risky operation too, as the on-disk format of ReiserFS has nearly zero redundancy and thus, no backups. The whole B+ tree is rebuilt from scratch: if a leaf node is rendered unreadable, all its files will be lost and the filesystem will be nonethewiser. The result can be better if a non-leaf node is lost, as the nodes pointed to by it will be found and reassigned to another parent into the tree, but the risk is high nevertheless.
_________________

jorgepeixoto · Posted: Thu Sep 06, 2007 5:57 pm Post subject:

Will the rebuild tree at least tell me if the operation was not perfect? Or will I be left with the doubt that maybe there is some file out there that disapeared, which I may need later?

jorgepeixoto · Posted: Thu Sep 06, 2007 8:53 pm Post subject:

Is there a way to backup all the metadata? Since I can't backup the whole disk, I could backup the most important data, and all the metadata. Is that possible?

PS: What I refer as metadata is all the information that reiserfs stores about the disk, minus the actual data in the files. That is, file names, directory structure, where in the disk a file is located... I'm not sure the term "metadata" is accurate here, since I normally see people using this term to refer to file permissions and things like that, but here I mean not only file permissions, but also lower level stuff such as where in the media is a certain file located.

darkphader · Veteran Joined: 09 May 2002 Posts: 1217 Location: Motown

The only time --rebuild-tree didn't work for me was when the drive itself was defective.

Chris
_________________
WYSIWYG - What You See Is What You Grep

Habbit · Posted: Thu Sep 06, 2007 11:20 pm Post subject:

jorgepeixoto · Posted: Fri Sep 07, 2007 3:29 pm Post subject: Results

I got problems: see below.
I have saved parts of my home directory and the /etc directory to tarballs.
I have saved the output of the find command.

Then I issued reiserfsck --rebuild-tree.

after that I issued find again:

jorgepeixoto · Posted: Thu Sep 13, 2007 6:16 am Post subject:

Because of the forums outage, I asked for help on the gentoo-users mailing list. A guy named Volker Armin Hemmann thinks that I can use the partition; there will be no more filesystem damage, and once I fix the corrupted files, the system will be OK. Do you agree with him?
Also, it seems to me that there is no more I can do to save data from this partition. The zeroed files *are gone*. If there are any more corrupted files (aparted from the zeroed ones), *they are gone* too. So I should retrieve what I can from the backup, reemerge the affected packages, and go on with my life. Do you agree?

I realized that the damaged files were filled with nulls, so I made a script that detected null-filled files across my filesystem. There are some 250 files like this. The full list is in http://pastebin.com/m60f4ea6e
Here are some (the numbers following each file is the number of nulls):

/media/hda2/bin/du: 59084
/media/hda2/bin/rm: 34100
/media/hda2/bin/tr: 27492
/media/hda2/bin/wc: 23108
/media/hda2/bin/dir: 79420
/media/hda2/bin/cut: 27048
/media/hda2/bin/env: 13436
/media/hda2/bin/seq: 17740
/media/hda2/bin/tty: 12800
/media/hda2/bin/yes: 12876
/media/hda2/bin/expr: 23336
/media/hda2/bin/head: 24516
/media/hda2/bin/sort: 65168
/media/hda2/bin/stty: 37380
/media/hda2/bin/sync: 12584
/media/hda2/bin/true: 12200
/media/hda2/bin/vdir: 79420
/media/hda2/bin/dirname: 13836
/media/hda2/bin/rmdir: 14684
/media/hda2/bin/sleep: 14772
/media/hda2/bin/touch: 34328
/media/hda2/bin/uname: 15316
/media/hda2/bin/chroot: 13500
/media/hda2/bin/mkfifo: 14644
/media/hda2/bin/readlink: 18988
/media/hda2/bin/basename: 13772
/media/hda2/etc/enlightenment/sysactions.conf: 2964
/media/hda2/etc/laptop-mode/laptop-mode.conf: 15916
/media/hda2/etc/laptop-mode/lm-profiler.conf : 1561
/media/hda2/etc/portage/package.keywords/wanted~: 796
/media/hda2/var/lib/scrollkeeper/scrollkeeper_docs: 1812
/media/hda2/usr/lib/aspell-0.60/nroff-filter.info: 232
/media/hda2/usr/lib/aspell- 0.60/iso-8859-1.cset: 13848
/media/hda2/usr/lib/aspell-0.60/iso-8859-2.cset: 14133
/media/hda2/usr/lib/aspell-0.60/cp1250.cmap: 31404
/media/hda2/usr/lib/aspell-0.60/cp1252.cset: 14039
/media/hda2/usr/lib/aspell- 0.60/cp1253.cset: 13682
/media/hda2/usr/lib/aspell-0.60/iso-8859-8.cmap: 27758
/media/hda2/usr/lib/aspell-0.60/iso-8859-8.cset: 12557
/media/hda2/usr/lib/aspell-0.60/cp1255.cmap: 35133
/media/hda2/usr/lib/aspell- 0.60/cp1256.cset: 13307
/media/hda2/usr/lib/aspell-0.60/cp1257.cmap: 31235
/media/hda2/usr/lib/aspell-0.60/cp1258.cset: 13920
/media/hda2/usr/lib/aspell-0.60/context-filter.so: 26976
/media/hda2/usr/lib/aspell- 0.60/iso-8859-10.cmap: 31046
/media/hda2/usr/lib/aspell-0.60/iso-8859-10.cset: 14259
/media/hda2/usr/lib/aspell-0.60/texinfo-filter.info: 914

Except for stuff in /bin, these files are not essential, so it does seem that the system is fixable.

One more question: this backup that I made after the screwup but before rebuild-tree, do you think it is reliable?
I have no prior backups... the *only* information I have came from the filesystem after the screw up...
The "backup" I have was made *after* the screw up but before the rebuild-tree.
I'm asking if this backup is reliable.

I have chosen one of the files that were zeroed in my filesystem and the corresponding file from the backup was OK. So at least in this case, *it was the rebuild-tree that corrupted the file*. This suggests that the *backup is reliable*.

Oh, and I found useful information in the output of rebuild-tree. Turns out that the output was huge because it prints status information in the screen and erases it with ^H. So the information that stays on the screen is far smaller than total information that is printed on the screen. In http://pastebin.com/m319aa81a you find the information that stays in the screen. You can see that the corrupted files are mentioned.

And thank you all for your attention!

Rob1n · Posted: Thu Sep 13, 2007 8:06 am Post subject:

jorgepeixoto · Posted: Thu Sep 13, 2007 8:23 am Post subject: