Re: LUG: Zeroing out bad blocks on ext filesystem to reallocate? - Mon, 04 Oct 2010 13:51:11 -0400

Subject : Re: LUG: Zeroing out bad blocks on ext filesystem to reallocate?

From : Jack Neely <jjneely@ncsu.[redacted]>

Date : Mon, 04 Oct 2010 13:51:11 -0400

On Mon, Oct 04, 2010 at 01:18:07PM -0400, Edward Anderson wrote:
> I recently was experiencing random freezing when using Chrome on my laptop.
> Finally it occurred to me that I might be experiencing disk issues. Sure
> enough, my syslog revealed that there were I/O errors on my disk. In the
> end, I ran fsck to do a badblocks check, which marked the blocks bad, which
> I was able to see using dumpe2fs. Before I did that though, I wanted to see
> which files were being affected. I used the guide linked below to convert
> the sector on the disk to an inode number in the filesystem, which told me
> that the bad block was on my Chrome history file for September. Makes sense.
> Something that I really didn't get though was this:
>
> According to http://smartmontools.sourceforge.net/badblockhowto.html
>
> > To force the disk to reallocate this bad block we'll write zeros to the
> > bad block, and sync the disk:
> >
> > root]# dd if=/dev/zero of=/dev/hda3 bs=4096 count=1 seek=2269012
> > root]# sync
> >
> > Why would writing zeros directly to the block device cause the ext
> filesystem to reallocate that file? They don't explain that, but just say
> that it does.
>
> Edward

I think the article is referring to forcing the disk drive itself to
reallocate the block. HDs have a collection of spare space and are
smart enough to remap a handful of sectors when they go bad. Linux or
your PC doesn't really notice.

However, you can use the SMART tools to examine your HD
stats...including the number of bad blocks its remapped. If you OS has
seen bad blocks, that means your HD is probably running out of of spare
blocks and other defenses. You probably also want to purchase a new
one.

Jack
--
Jack Neely <jjneely@ncsu.[redacted]>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89