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] _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"