Date: Wed, 30 Jun 2004 18:35:22 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: Tuc <tuc@ttsg.com> Cc: freebsd-questions@freebsd.org Subject: Re: Disk about to fail Message-ID: <20040630182527.D615@localhost.my.domain> In-Reply-To: <200406302200.i5UM0tdv073144@himinbjorg.tucs-beachin-obx-house.com> References: <200406302200.i5UM0tdv073144@himinbjorg.tucs-beachin-obx-house.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tuc wrote to freebsd-questions@freebsd.org: > Hi, > > Looks like my disk is about to fail YET AGAIN on my laptop : > > ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=25937067 > ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=25937067 > ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=25937067 > ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=25937067 > > > The last 2 times however I found it was the /var partition, I > newfs'd it again, it happened again, re-newfs'd it, now its happening again. > How do I find out whats stored at that LBA, and either fix it, or do something > so it doesn't use that block or any bad block anymore? /var is typically quite a volatile filesystem; many reads/writes; usually nothing stays for long. If you're getting those errors, it means the failure is occurring in a portion of the disk you're actually using. (i.e., blocks that are actually allocated to files). Try a recursive grep of the entire filesystem and see which file(s) croak as unreadable. :-) Once, I had this happen, and actually found a 50MB file that was using the bad region of the disk. The file wasn't essential to anything, so I left it there. The rest of the disk still works fine. Needless to say, I don't trust it very much, but at least the immediate problem is confined. If the bad space *isn't* actually used by a file, it's a bit tricker. If you really want to track it down in that case, you could try filling up your disk with files some multiple of blocksize and read them back in, until you either get a hard error, or a consistency failure. Then, delete all of the files that you created, except for the one(s) spanning the bad blocks. Note that *none* of these strategies are recommended where any data that you care about is concerned. Best? Get your data off the disk *yesterday*, in descending priority order, and use the platters for wind chimes. - Ryan -- Ryan Thompson <ryan@sasknow.com> SaskNow Technologies - http://www.sasknow.com 901-1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040630182527.D615>