[kwlug-disc] Media errors on a USB disk

[Khalid Baheyeldin]

So I ran the command that Andrew Cant suggested.

Since this is on a USB connected drive, it took from noon till sometime in
the early morning (was running overnight).

Here is the output:

# e2fsck -c -y /dev/sdb1
e2fsck 1.40.8 (13-Mar-2008)
Checking for bad blocks (read-only test): done
/dev/sdb1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one
inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 24584: 22130688 22130721 22130722
22130723 22130724 22130725 22130726 22130727 22130729 22130730 22130731
22130732 22130733 22130734 22130735 22130737 22130738 22130739 22130740
22130741 22130742 22130743 22130745 22130746 22130747 22130748 22130749
22130936 22130974 22131744 22131747 22131928 22133456 22133467 22135184
22135188 22135376 22135425 22135608 22135662 22135663
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 1 inodes containing multiply-claimed blocks.)

File blahblah (inode #24584, mod time Sun Oct 17 03:33:27 2010)
  has 41 multiply-claimed block(s), shared with 1 file(s):
        <The bad blocks inode> (inode #1, mod time Wed Oct 20 13:14:45 2010)
Clone multiply-claimed blocks? yes

Error reading block 22130726 (Attempt to read block from filesystem resulted
in short read).  Ignore error? yes

Force rewrite? yes

Error reading block 22130727 (Attempt to read block from filesystem resulted
in short read).  Ignore error? yes

Force rewrite? yes

.... repeated for more blocks

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #1 (30161, counted=30120).
Fix? yes

Free blocks count wrong for group #675 (65501, counted=6).
Fix? yes


/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 41454/61054976 files (1.5% non-contiguous), 86353980/244190008
blocks

The file that is mentioned in the output is the previous backup, so
eventually it will be overwritten. If that procedure got all the bad blocks,
then the problem should go away.

During that time, dmesg shows messages like these:

[2731049.634591] Buffer I/O error on device sdb1, logical block 22130726
[2731049.634602] Buffer I/O error on device sdb1, logical block 22130727
[2731049.634609] Buffer I/O error on device sdb1, logical block 22130728
[2731049.634615] Buffer I/O error on device sdb1, logical block 22130729
[2731049.634621] Buffer I/O error on device sdb1, logical block 22130730
[2731049.635133] Buffer I/O error on device sdb1, logical block 22130731

And this:

[2731055.768360] sd 13:0:0:0: [sdb] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[2731055.768365] sd 13:0:0:0: [sdb] Sense Key : Medium Error [current]
[2731055.768368] sd 13:0:0:0: [sdb] Add. Sense: Unrecovered read error
[2731055.768371] end_request: I/O error, dev sdb, sector 177083401
[2731056.763272] sd 13:0:0:0: [sdb] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[2731056.763277] sd 13:0:0:0: [sdb] Sense Key : Medium Error [current]
[2731056.763280] sd 13:0:0:0: [sdb] Add. Sense: Unrecovered read error
[2731056.763283] end_request: I/O error, dev sdb, sector 177085297
[2731057.667254] sd 13:0:0:0: [sdb] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[2731057.667259] sd 13:0:0:0: [sdb] Sense Key : Medium Error [current]
[2731057.667263] sd 13:0:0:0: [sdb] Add. Sense: Unrecovered read error
[2731057.667265] end_request: I/O error, dev sdb, sector 177085305

Any comments?
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20101021/badf473b/attachment.htm>