On Mon, Dec 18, 2006 at 01:43:30PM -0500, Lowell Gilbert wrote:
> Marc van Woerkom <[EMAIL PROTECTED]> writes:
> 
> > Hi,
> >
> > my notebook's hard drive seems to be damaged:
> >
> > Dec 18 15:49:13 hokage kernel: ad0: FAILURE - READ_DMA
> > status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=9919567
> > Dec 18 15:49:13 hokage kernel:
> > g_vfs_done():ad0s1f[READ(offset=1360723968, length=32768)]error = 5
> > Dec 18 15:49:13 hokage kernel: vnode_pager_getpages: I/O read error
> > Dec 18 15:49:13 hokage kernel: vm_fault: pager read error, pid 1048 (cvsup)
> > Dec 18 15:49:17 hokage kernel: ad0: FAILURE - READ_DMA
> > status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=9919567
> > Dec 18 15:49:17 hokage kernel:
> > g_vfs_done():ad0s1f[READ(offset=1360723968, length=32768)]error = 5
> > Dec 18 15:49:17 hokage kernel: vnode_pager_getpages: I/O read error
> > Dec 18 15:49:17 hokage kernel: vm_fault: pager read error, pid 1048 (cvsup)
> > Dec 18 15:49:17 hokage kernel: pid 1048 (cvsup), uid 0: exited on signal 6
> >
> > Is it possible to check the disc for bad blocks and to mark them as
> > unusable, thus allowing me continue using the hard drive?
> 
> That happens automatically on a disk like this one.

Automatic remapping of bad blocks can only happen for *writes*. not reads.

When you are writing, the disk knows what data is supposed to reside in the
block - the data you trying to write - and can transparently write it to
another block instead.
When you encounter a bad block during a read the disk has no way of knowing
what data was supposed to be there and therefore can't transparently remap
the block since that would cause data loss.

(Some RAID controllers are supposed to be able to handle this by
reconstructing the data that was supposed to be in the bad block from the
other disks in the RAID array, and then writing this to the bad block, thus
triggering the disks transparent remapping of bad blocks.)

(If the disk does succeed in reading a block, but only after several tries,
it can of course also remap the block, but unrecoverable reads (which this
seems to be a case of) cannot be handled thus.)


> 
> > Or what would you recommend?
> 
> Try a manufacturer's utility, if you can find one, but generally when
> you reach the point where the OS is aware of disk block errors, it is
> continuing to lose them at a high (and accelerating) rate.

Usually, but not always.

> 
> Also consider the "SMART" utilities, but be prepared to buy a new
> disk.   

Also check the cables.  It might just be something so simple as a bad cable.

And if you haven't already done so, this is a very good time to start making
backups of everything on that disk. (A bit late most likely, but hopefully
not *too* late.)

> 
> > Funny, I use FreeBSD about 10 years, this is the first time I have
> > that problem and it seems not to be addressed in the handbook.
> 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/install.html#INSTALL-BAD-BLOCKS


-- 
<Insert your favourite quote here.>
Erik Trulsson
[EMAIL PROTECTED]
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to