Status 4 simply means fsck didn't fix all the errors. Some errors can't be fixed automatically. Hence it simply gave you notice of that. It doesn't mean it died, or didn't fix everything it could have. The exit statuses are listed in the man page, I believe.
The issue with multiply claimed blocks is that you have several files pointing to the same location. Cloning them will make all the files point to separate locations, and you'll wind up with multiple copies of whatever data is in the affected inodes.
The downside is, cloning those blocks is something like order fn(O^n). So it's geometrically slow.
Most likely anything in those inodes is garbage. This looks like an inode corruption issue. It's possible the data is fine in those inodes. Cloning is the safe (preserve all data), method, the other method is to not clone and just delete the affected inodes. Get paper and pencil ready and record any filenames, so you know what you lost/preserved. Record the inodes also.
You can use "ls -i" to list the inode of a file. You can use "find -inum n" to find a file with a particular inode.
Curious which kernel and ext3 version you are running?
Regards, Jack
--- On Tue, 8/31/10, Oren Beck [email protected] wrote:
From: Oren Beck [email protected] Subject: Ubuntu 9.04 with file issues Cross posted by intent- we're supposed to compare notes on such problems - I hope. To: "KCLUG" [email protected], [email protected] Date: Tuesday, August 31, 2010, 2:50 PM Hi- I have a system in front of me with Ubuntu 9.04 on it- it was installed ext3. the part that is escapingmy understanding is recovering from a file corruption of some sort. Duplicate or bad blocks is the error message. The automatic run- in recovery mode- of fsck dies with exit status 4.
A manual run of fsck shows a list of what it calls multiply-claimed blocks in several inodes. and there's aprompt asking yor no about cloning them.
Needless to say- I am quite aware that my lack of understanding risks avoidable data loss. Any suggestions both on what to do and the best training document/s so I can understand why/how this issue happened in the first place will be appreciated. This is one of those gaps in my understanding of Linux admin skills. Either this is so drop dead simple that I will feel more of an idiot for not having "known" what is going on..Or it's going to be non-trivial to recover from.
My first suggested fix was using Puppy etc and an external drive to simply grab any unique personal files that are intact- then DBAN wipe that drive before starting over. Which is what I cal a "Last Resort First" tactic . I hate having to use them, but LRF type methods have become a major mental hygiene tool for me :)
Of course- I am deeply curious if my oft preached model for data protection- keeping the OS and Userdata on physically separate drives would have helped here -or not.. -- Oren Beck
816.729.3645 _______________________________________________ KCLUG mailing list [email protected] http://kclug.org/mailman/listinfo/kclug