Re: Dealing with bad blocks on a hard disc
- From: Erik Trulsson <ertr1013@xxxxxxxxxxxxx>
- Date: Mon, 18 Dec 2006 21:00:05 +0100
On Mon, Dec 18, 2006 at 01:43:30PM -0500, Lowell Gilbert wrote:
Marc van Woerkom <marc.vanwoerkom@xxxxxxxxxxxxxxxx> 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
ertr1013@xxxxxxxxxxxxx
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- References:
- Dealing with bad blocks on a hard disc
- From: Marc van Woerkom
- Re: Dealing with bad blocks on a hard disc
- From: Lowell Gilbert
- Dealing with bad blocks on a hard disc
- Prev by Date: Re: Dealing with bad blocks on a hard disc
- Next by Date: Re: FreeBSD as VM host OS?
- Previous by thread: Re: Dealing with bad blocks on a hard disc
- Next by thread: /usr/ports/sysutils/lmon
- Index(es):
Relevant Pages
|
|
