[ please reply on-list, so that others can help too ]
On Thu, 16 Nov 2006, Bogdan Scintee wrote:
Buffer I/O error on device sdc8, logical block 512
sd 4:0:0:0: SCSI error: return code = 0x8000002
sdc: Current: sense key: Medium Error
Additional sense: Unrecovered read error
end_request: I/O error, dev sdc, sector 1134514
So, it really is the device generating the errors, the filesystem can't
do much here :(
I got finally a img file. Running the e2fsck on this image I got
e2fsprogs-1.39/e2fsck/e2fsck -v -d sdc8.img
Very good, but I forgot one thing: if you have enough space, make a
backup of sdc8.img, then try e2fsck. If e2fsck screws up, you still have
the backup, even if the device (your CF card) fails completly.
e2fsck 1.39 (29-May-2006)
Superblock has an invalid ext3 journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock doesn't have has_journal flag, but has ext3 journal inode.
Clear<y>? yes
sdc8.img was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data. Clear<y>? yes
Pass 2: Checking directory structure
Directory inode 2, block 0, offset 0: directory corrupted
Salvage<y>? yes
Missing '.' in directory inode 2.
Fix<y>? yes
Setting filetype for entry '.' in ??? (2) to 2.
Missing '..' in directory inode 2.
Fix<y>? yes
Setting filetype for entry '..' in ??? (2) to 2.
Pass 3: Checking directory connectivity
'..' in / (2) is <The NULL inode> (0), should be / (2).
Fix<y>? yes
Unconnected directory inode 4097 (/???)
Connect to /lost+found<y>? yes
/lost+found not found. Create<y>? yes
Unconnected directory inode 61441 (/???)
Connect to /lost+found<y>? yes
Unconnected directory inode 8193 (/???)
Connect to /lost+found<y>? yes
Unconnected directory inode 28673 (/???)
Connect to /lost+found<y>? yes
Unconnected directory inode 30721 (/???)
Connect to /lost+found<y>? yes
Unconnected directory inode 57345 (/???)
Connect to /lost+found<y>? yes
Pass 4: Checking reference counts
Inode 4097 ref count is 3, should be 2. Fix<y>? yes
Inode 8193 ref count is 5, should be 4. Fix<y>? yes
Inode 28673 ref count is 3, should be 2. Fix<y>? yes
Inode 30721 ref count is 7, should be 6. Fix<y>? yes
Inode 57345 ref count is 3, should be 2. Fix<y>? yes
Inode 61441 ref count is 9, should be 8. Fix<y>? yes
Pass 5: Checking group summary information
Block bitmap differences: -(276--8192) -(8454--8761)
Fix<y>? yes
Free blocks count wrong for group #0 (65535, counted=7917).
Fix<y>? yes
Free blocks count wrong for group #1 (4763, counted=5071).
Fix<y>? yes
Free blocks count wrong (285521, counted=293747).
Fix<y>? yes
sdc8.img: ***** FILE SYSTEM WAS MODIFIED *****
1051 inodes used (0%)
125 non-contiguous inodes (11.9%)
# of inodes with ind/dind/tind blocks: 405/68/0
140196 blocks used (32%)
0 bad blocks
0 large files
967 regular files
74 directories
0 character device files
0 block device files
0 fifos
-6 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
1035 files
I tried different options during the recovery of the image but
unfortunately the result wasn't
as expected. At the end part of the files where recovered but the
parent folders names where replaced by
inode number (I guess) and attached to lost+found directory.
I tried different options during the recovery of the image but unfortunately the result wasn't
as expected. At the end part of the files where recovered but the parent folders names where replaced by
inode number (I guess) and attached to lost+found directory.
Yes, when you had a lot of small files, even 1 GB of data in lost+found
is a pain to reconstruct :(
As I said in my previous e-mail the windoze application (Nucleus Kernel Linux) is very fast and seems to recover
more information from CF.
I too came across some win32 tools to recover b0rked filesystems: one is
called "R-Linux", the other one "Stellar Phoenix Linux", demos
available.
I have a question now: The journal is kept only on the primary superblock or it has also copies on every alternative
superblock?
I don't know...
My feeling is that the CF got a badblock exactly on the journal and the e2fsck can't correct the information, therefore
can't complete the job.
Do you have any knowledge about a application which is able to handle such situation?
Dunno, maybe somebody else will have a look on this...
Christian.
--
BOFH excuse #453:
Spider infestation in warm case parts
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
