Re: How to map bad sectors on IDE?
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 [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
Re: How to map bad sectors on IDE?
On Sat, Feb 01, 2003 at 02:52:38PM -0500, Joe O wrote: 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. I haven't been following this thread closely so pardon me for butting in. I do not believe the old bad144 system had anything to do with ATA. It originated with VAX hardware. Bad144 managed spares in the disklabel. To this day, disklabel(5) still supports spare blocks. Over and above the low level ATA stuff. Problem is that SCSI specified how to manage bad block lists, how to list and edit the bad blocks. ATA/IDE didn't for a long time and as a result the only prayer you have of managing a bad block list on an ATA drive is with the manufacturer's utility. If even then. If somehow a bad block gets past the ATA built-in controller, that indicates the ATA drive is out of spares and begging for replacement. But if you want to continue there is a badsect(8) utility in FreeBSD which will create a file on top of the bad block. So from then on you simply stay out of that file. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Multiple solutions for a problem (Re: How to map bad sectors on IDE?)
On Sat, Feb 01, 2003 at 05:17:45PM -0500, Lowell Gilbert wrote: Stephen Hovey [EMAIL PROTECTED] writes: This has been an open question - I dont believe IDE's do much of their own bad block marking - They do, probably because the chances of manafacturing a totally error free disk are pretty low. Same with CD's by the way, they mark off bad areas up to a point. Which is why making copies of CD's that are themselves copies sometimes does not work, since you inherit the bad track markings from the copied CD plus your new ones, and there is a limit to how much of a CD can be marked bad. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: How to map bad sectors on IDE?
On 1 Feb 2003, at 11:19 [=GMT-0500], Lowell Gilbert wrote:
John Mills [EMAIL PROTECTED] writes:
out of circulation. 'apropos badblocks' and 'man fsck' failed to suggest
such a function in fBSD, but it might be worth more looking.
badsect(8)
I tried that with the bad sector numbers (with both ranges
mentioned in the messages, since I wasn't sure which are the
true ones):
nud# badsect BAD 99107103 83247423
block 99107103 out of range of file system
block 83247423 out of range of file system
Don't forget to run ``fsck /dev/ad0h''
nud# badsect BAD 27000944 19071104
block 27000944 in non-data area: cannot attach
block 19071104 in non-data area: cannot attach
Don't forget to run ``fsck /dev/ad0h''
After I ran fsck it refused to mark the partition as clean. That was
not nice, since /usr was on it.
Since there was quite a bit of space on the /home partition, I decided
to move the content of the affected partition to that. So /usr moved
to /home/usr (minus 99% of src and obj and ports).
So I thought a new fs ('reformat') and everything is OK. I could even
move /usr back then.
Alas, bad luck again, because:
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.
newfs doesn't make any such attempts any more, *because* the hardware
has already done it for them.
You are very right. I tried it. newfs didn't tell me anything about
bad sectors, so I guess it either missed them on purpose or
accidently. Also I noticed it did not take much time to do 17GB. So a
media check sort of seemed unlikely. It did freeze my console for a
few seconds, while the only serious other thing it was doing was make
buildworld.
--
[16] Do it today.
http://logoff.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: How to map bad sectors on IDE?
On Mon, Feb 03, 2003 at 12:59:50AM +0100, Marc Schneiders wrote: On 1 Feb 2003, at 11:19 [=GMT-0500], Lowell Gilbert wrote: John Mills [EMAIL PROTECTED] writes: out of circulation. 'apropos badblocks' and 'man fsck' failed to suggest such a function in fBSD, but it might be worth more looking. badsect(8) I tried that with the bad sector numbers (with both ranges mentioned in the messages, since I wasn't sure which are the true ones): As a last desperate measure, and if everything is backed up somewhere you could use the manafacturer's test disk to do a low level format -- may or may not help, but sounds like you do not have a lot to lose ! -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Multiple solutions for a problem (Re: How to map bad sectors on IDE?)
Marc Schneiders [EMAIL PROTECTED] writes: Your advise sounds perfectly sound for IBM and Microsoft and the Pentagon. But for a home or small office situation, there might be another way to deal with it? Especially since we are not talking about something 10 years old or heavily used in a mailserver. The disk is *already* suffering from massive failure. You are more or less *guaranteed* that it's going to get worse, quickly. badsect(8) is still part of FreeBSD, but on disks less than (coincidentally) about 10 years old, it's pretty much useless, because sectors are going to continue going bad so quickly. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: How to map bad sectors on IDE?
John Mills [EMAIL PROTECTED] writes: out of circulation. 'apropos badblocks' and 'man fsck' failed to suggest such a function in fBSD, but it might be worth more looking. badsect(8) 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. newfs doesn't make any such attempts any more, *because* the hardware has already done it for them. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Multiple solutions for a problem (Re: How to map bad sectors on IDE?)
Stephen Hovey [EMAIL PROTECTED] writes: This has been an open question - I dont believe IDE's do much of their own bad block marking - The manufacturers claim otherwise; do you know something the rest of us don't? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
How to map bad sectors on IDE?
Recently a cvsup failed because of an input/output error in the directory /usr/src/contrib/perl5/h2pl. I tried deleting the content of the directory, and found out there were hardware problems with the disk. For it says: ls: eg: Input/output error And in the console messages: Feb 1 00:50:10 zeist /kernel: ad0s1h: hard error reading fsbn 99107103 of 27000944-27000959 (ad0s1 bn 99107103; cn 6169 tn 33 sn 39) status=59 error=40 Similar messages appear for this physical address and another one when the filesystem is checked daily at 03:00 h. This is happening for some time now (since January 18), but did not give any problems. Jan 30 03:05:54 zeist /kernel: ad0s1h: hard error reading fsbn 99107103 of 27000944-27000959 (ad0s1 bn 9 9107103; cn 6169 tn 33 sn 39) status=59 error=40 Jan 30 03:06:01 zeist /kernel: ad0s1h: hard error reading fsbn 83247423 of 19071104-19071119 (ad0s1 bn 8 3247423; cn 5181 tn 232 sn 42) status=59 error=40 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. Advise: Throw away the disk. Now this I find a bit radical :-) Esp. since the disk is about 3 years old. Any advise other than throw away the disk (or claim a new one)? Is there really no way to tell FreeBSD to discard these sectors? One more detail: Last time the machine booted it thought this of the drive: Jan 8 12:28:58 zeist /kernel: ad0: 39083MB Maxtor 5T040H4 [79408/16/63] at ata0-master UDMA100 Thanks! -- [14] I am not a lawyer. http://logoff.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: How to map bad sectors on IDE?
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. Advise: Throw away the disk. Now this I find a bit radical :-) Esp. since the disk is about 3 years old. 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... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: How to map bad sectors on IDE?
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
