On Wed 10 Feb 2016 at 20:05:39 (-0800), Joseph Loo wrote:
> > On 9 February 2016 at 19:57, Ritesh Raj Sarraf <r...@researchut.com wrote:
> > On my RPi2, I saw the following reported by my kernel.
> >
> > [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result:
> > hostbyte=0x00 driverbyte=0x00
> > [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47
> > 00 00 08 00
> > [156278.831152] blk_update_request: I/O error, dev sdb, sector
> > 2587886663
> >
> > This got me worried so I ran an fsck on my drive. Following is the
> > report.
> >
> > 130 pi@pi:~$ sudo fsck -cvkv /dev/sdb1
> > [sudo] password for pi:
> > fsck from util-linux 2.25.2
> > e2fsck 1.42.12 (29-Aug-2014)
> > Checking for bad blocks (read-only test): done
> >
> > SEAGATE: Updating bad block inode.
> > Pass 1: Checking inodes, blocks, and sizes
> > Pass 2: Checking directory structure
> > Pass 3: Checking directory connectivity
> > Pass 4: Checking reference counts
> > Pass 5: Checking group summary information
> >
> > SEAGATE: ***** FILE SYSTEM WAS MODIFIED *****
> >
> > 20013 inodes used (0.02%, out of 122101760)
> > 8944 non-contiguous files (44.7%)
> > 53 non-contiguous directories (0.3%)
> > # of inodes with ind/dind/tind blocks: 0/0/0
> > Extent depth histogram: 16695/3216/62
> > 416471936 blocks used (85.28%, out of 488378008)
> > 0 bad blocks
> > 63 large files
> >
> > 17086 regular files
> > 2885 directories
> > 0 character device files
> > 0 block device files
> > 0 fifos
> > 0 links
> > 33 symbolic links (32 fast symbolic links)
> > 0 sockets
> > ------------
> > 20004 files
> > 1 pi@pi:~$
> >
> > From the report, it says that there are 0 bad blocks. So is this a
> > bug in e2fsprogs ?
Does one I/O error mean that you have a bad block necessarily?
> fsck checks primarily a directory structure not the hard drives. you
> might want to try
>
> badblocks -svn /dev/sdb
>
> Like always, backup your drive before you do this.
Reading man badblocks:
"Important note: If the output of badblocks is going to be fed to the
e2fsck or mke2fs programs, it is important that the block size is
properly specified, since the block numbers which are generated are
very dependent on the block size in use by the filesystem. For this
reason, it is strongly recommended that users not run badblocks
directly, but rather use the -c option of the e2fsck and mke2fs
programs."
I can't see any point in running badblocks and not putting any bad
blocks that it finds into the badblock inode. So running
sudo fsck -cvkv /dev/sdb1
seemed like a sensible course of action to me, even if it failed to
find any bad blocks. Here's an example of what can/may/should happen:
Script started on Tue 09 Feb 2016 08:58:13 AM CST
# e2fsck -c -k -v /dev/sda3
e2fsck 1.42.5 (29-Jul-2012)
Checking for bad blocks (read-only test):
0.00% done, 0:00 elapsed. (0/0/0 errors)
[... loads of progress lines ...]
99.98% done, 55:13 elapsed. (1/0/0 errors)
...........................................done
john03: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
john03: ***** FILE SYSTEM WAS MODIFIED *****
73793 inodes used (2.63%, out of 2809856)
23325 non-contiguous files (31.6%)
75 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 22365/1027/0
9234305 blocks used (82.22%, out of 11231443)
1 bad block
1 large file
68480 regular files
4853 directories
0 character device files
0 block device files
0 fifos
5 links
451 symbolic links (450 fast symbolic links)
0 sockets
------------
73789 files
# exit
Script done on Tue 09 Feb 2016 09:59:18 AM CST
Cheers,
David.
