From owner-freebsd-stable Tue Dec 14 4: 0:48 1999 Delivered-To: freebsd-stable@freebsd.org Received: from waltz.rahul.net (waltz.rahul.net [192.160.13.9]) by hub.freebsd.org (Postfix) with ESMTP id 9B45E14EC0 for ; Tue, 14 Dec 1999 04:00:45 -0800 (PST) (envelope-from dhesi@rahul.net) Received: by waltz.rahul.net (Postfix, from userid 104) id 10BC021C; Tue, 14 Dec 1999 04:00:34 -0800 (PST) To: freebsd-stable@freebsd.org Subject: Re: how to rewrite the data field replaceable unit? References: X-Newsreader: NN version 6.5.1 (NOV) Message-Id: <19991214120034.10BC021C@waltz.rahul.net> Date: Tue, 14 Dec 1999 04:00:34 -0800 (PST) From: dhesi@rahul.net (Rahul Dhesi) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith writes: >> (da2:ahc0:0:2:0) Unrecovered read error - recommend rewrite the data field replaceable unit: 20 sks:80,a0 ... >That's two things, 'data' and 'field replaceable unit'. The FRU code >tells you which part of the drive is failing - in this case the vendor >code for the broken bit is '20'. Thanks. A suggestion to the Device Driver Gods: Please make error messages understandable to the rest of us. >...The drive will never forward a block if it >involves losing the data that it can't get out of the block. >Unrecovered read error -> return read error, do not forward block Which makes sense. Thanks. >In order to have the block forwarded (replaced), you need to put the drive >in a situation where it can guarantee that no data loss will occur. The >easiest way to do this is to work out which file contains the bad block, >and copy it somewhere else, then delete the original.... This confuses me. Even if I have deleted the file that contains the bad block, how is the disk hardware to know that? >You can also unmount the drive and write to the block manually (write a >small program that seeks to the bad block and then writes to it). This seems promising. If I succeed in writing to that bad block, and later cause a read from it, and a recoverable error occurs during the read, the disk will likely remap the block. One more question: fsck reports some unreadable block numbers. What is the block size assumed by fsck when it reports that block n is bad? Is it the same as the block size of the filesystem (in this case 8192 bytes)? And if so, then to rewrite the block, would I seek to (block no. * 8192) and then write 8192 bytes? And yet another question: When 'badsect' reports that a bad block cannot be attached because it is in a a non-data area, what does this mean? -- Rahul Dhesi See my UUNET spam mini-faq at: http://www.rahul.net/dhesi/uunet.faq.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message