Date: Sat, 1 Feb 2003 14:52:38 -0500 (EST) From: Joe O <joeo@cracktown.com> To: Marc Schneiders <marc@schneiders.org> Cc: questions@FreeBSD.ORG Subject: Re: How to map bad sectors on IDE? Message-ID: <20030201143148.C71938-100000@clubfoot.cracktown.com> In-Reply-To: <Pine.LNX.4.44.0301312140280.4225-100000@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
The older "wd" ide driver used to have "bad144" bad block re-mapping, you could scan a partition and the driver would remap hard error blocks at the time of the initial scan to a reservred area of known good blocks. Blocks that went bad from the time of that initial scan would need to be added to the list of bad blocks to re-map using the bad144 utility. The current ATA framework no-longer supports this with fairly good reasons. All IDE drives today (since the late 90's, in practice any ide drive over 2gig's in capacity) have their own on-board remapping mechanisms (SCSI drives have had this feature for a longer time, on some scsi drives the functionality had to be specifically enabled, many DEC supplied SCSI drives I've come across did not have this turned on). The drives, when propperly operating otherwise, will detect read errors and remap the block on their own, though the data in that block may be lost. A practical way of getting a drive with this functionality to "preen" itself is to occasionaly do a "dd" read of the entire partition or raw disk device. Look up "perfect media" in the list archives. Also, you can buy 20+ gigabyte drives from any of a number of retail outlets now for not a lot of money (under $100 US). On Fri, 31 Jan 2003, John Mills wrote: > Marc - > > On 31 Jan 2003, Lowell Gilbert wrote: > > > Marc Schneiders <marc@schneiders.org> writes: > > > > > I have searched Google to find a solution to mark off these two > > > blocks/inodes (or however I should call them), so that they will not > > > be used anymore. All I found is that this is not possible on > > > IDE. > > It is possible with some types of Linux filesystems (ext2 for one), and > 'e2fsck' can be told to run a block-by-block read-write test across the > disk (optionally preserving original data where possible), then add any > bad blocks to a suitably named file which exists just to keep bad blocks > out of circulation. 'apropos badblocks' and 'man fsck' failed to suggest > such a function in fBSD, but it might be worth more looking. Such an > operation would cost you only those files which are now corrupted - when > it happened to me I lost a block in a text file, 'fsck' moved the > fragments to 'lost+found', and I was able to reconstruct the file. That > was pure luck, naturally. > > > Why is it radical? After all, IDE disks already do bad-block > > remapping internally, so you've built up a *lot* of bad sectors > > already if they're starting to become visible to the operating > > system... > > Does fBSD's file system creation make sure that all blocks of a newly > created file system are in fact usable? I would be surprised if there were > no cross checks in the formatting/partitioning/fs-creation path. If the > bad blocks weren't linked in the new filesystem, they would have become > invisible for practical purposes. > > Bad side: This approach wipes the rest of your disk's contents. > > Maybe there are some starting points in there. > > - John Mills > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030201143148.C71938-100000>