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

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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-questions" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to