Red Hat Bugzilla – Bug 137128
e2fsck cannot correct badblocks
Last modified: 2007-11-30 17:10:53 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1 Description of problem: I have a partition I made with a fedora core 2 updated to fedora core 2 test 2. There are errors on that partition, as shown by smartctl: 196 Reallocated_Event_Count 0x0008 246 246 000 Old_age Offline - 7 197 Current_Pending_Sector 0x0008 252 251 000 Old_age Offline - 19 198 Offline_Uncorrectable 0x0008 234 234 000 Old_age Offline - 19 To clean the filesystem I run e2fsck from a fedora core 3 test 3, but every time I rerun it there are new errors. Every run doesn't give the same errors exactly, though. dmesg shows that errors happen for sectors located at the same place every run (with sometime little differences but mostly overlapping). Here is an excerpt of dmesg ide: failed opcode was: unknown end_request: I/O error, dev hda, sector 12583251 Buffer I/O error on device hda1, logical block 3145797 hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=12583431, sector=12583255 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. run e2fsck -f -c /dev/hda1 2. rerun e2fsck -f -c /dev/hda1 3. Actual Results: There were errors with the second e2fsck too Expected Results: badblocks taken into account and no more errors. Additional info: e2fsprogs-1.35-11.2
Created attachment 105754 [details] excerpt of an e2fsck run
Created attachment 105755 [details] the next e2fsck run
Created attachment 105756 [details] dmesg output during e2fsck
Created attachment 105757 [details] smartctl -a /dev/hda (after e2fsck, but before is similar)
I am sorry, but i think your harddrive has major problems. There is no overlap for blocks in the different e2fsck runs. Closing "NOT A BUG".
But many blocks overlap. Some blocks in both runs: 1540211 1572920 1310760 1474562 1474563-66 1572898-03 And in the dmesg output, I can see that about the same LBASect are systematically problematic, and there is considerable overlapping (I found 12 LBAsect like LBAsect=12583431 that are always in the dmesg messages) and are consistant with what samrctl give for defectuous blocks. Still the overlapping isn't perfect.