🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.msdos.programmer
Article #1382

Re: help to fix bad sectors

#1382
From: Rod Speed
Date: Thu, 21 Sep 2000 00:00
226 lines
9932 bytes
Folkert Rienstra <folkert.rienstra@hccnet.nl> wrote in
message news:8qah7r$t3d$2@news.hccnet.nl...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Ian Staples <ianst@refer.to.sig.au.invalid> wrote
>>> phaywood@alphalink.com.au.REMOVE.THIS.BIT wrote
>>>> Steen Nielsen wrote

>>>>> Hi I need a dos program to repaer bad sectores on my harddrive
>>>>> can any one please tell me which program i should use.

>>>> You can't fix bad sectors. They're a fact of life.
>>>> There's really nothing you can do. Those sectors
>>>> have gone to the great bit bucket in the sky.

>>> Is everything so clearly black or white,
>>> or can we have a bit of grey here too?

>> If you insist, even a cane toad can have some grey.

>>> Up until 72 hours ago I may have unconditionally agreed with
>>> the "great bit bucket" concept, but I'm now wondering about it...

>> Its just plain wrong stated as absolutely as that.

>> It really depends on what produced what appears to be bad sectors.
>> It is possible for some software to decide that a particular sector is
>> bad at the OS level and just mark it as bad at the OS level, in the
>> FAT. That can happen not because there is a problem at the level
>> of the media layer on the platter but just due to errors higher in the
>> chain so the software sees what appears to be a bad sector but
>> which is fine at the level of the sector on the media.

>> Those can obviously be fixed just by a format at the OS level.

>> Even when a sector has gone bad on the physical platter,
>> most modern drives do have what is often called a low
>> level formatter but which in fact is just a ute which scans
>> for and adds new bad sectors to the bad sector list

> I think that is wrongly worded,

It isnt.

> see my other contrib.

Thats a singularly unhelpful way of referring to it when
there is more than one other post from you in this thread.

If you are referring to www.deja.com/threadmsg_ct.xp?AN=671009018.1
where you said

> he needs a way to get rid of the ones that APPEAR bad.

> The drivemakers have utilities to do that.

Those dont just APPEAR bad, they really are bad and
the ute just ads them to the list of bad sectors where they
become invisible to other than that sort of bad sector ute.

> On the other hand that is what we would like to have
> so we could get rid of the unrecoverable read errors that
> the automatic reallocation process is unable to replace.

That sentence makes no sense. The bad sector utes
provided by may drive manufacturers are quite capable
of finding new bad sectors and adding them to the bad
sector list so they arent seen with normal access to the drive.

All modern drives have bad sectors identified at manufacturing
time and the ute just adds any more that are produced by say
a power flick while writing the particular sector etc.

>> and makes the drive appear to be error free.
>> Clearly in that case the bad sector hasnt
>> actually been repaired, only mapped away,

> Technically and logically it is.

Wrong. The bad sector is still there, its just not used
anymore once its been added to the bad sector list.

> Technically that spot is not a sector anymore, just unused space.

Crap, its still a sector, just not a sector thats used anymore.

Sectors with no data in them are still sectors, even if unused space.

>> but thats the least common reason for bad sectors
>> because the original bad sector scan done at manufacturing
>> time is done at reduced signal levels to detect areas where
>>the media isnt good enough and that doesnt change over time.

> I'd say it does:

Doesnt change a thing.

> wear and tear.

The heads fly over the platter, no 'wear and tear'

They dont even land on the section of the platter
where the data is when the drive is turned off.

>> You can however sometimes get at bad sector due
>> to a power glitch while the sector is being written.

> That should actually be impossible but practice suggests it is not.

You're confusing two entirely separate issues here.

The media surface doesnt normally get physically damaged.
The magnetic information written there can be.

If the media surface does get physically damaged, the consequences
are normally a lot worse than just a few bad sectors showing up,
you normally end up with physical fragments flying around and
that is one way you can see whats claimed to be bad sectors
varying from bad sector scan to bad sector scan.

The other obvious way is with an electronic problem so that what
are good sectors on the media in the sense of whats magnetically
encoded on the media is good, but it aint read reliably.

>> And in the ultimate his statement is wrong with drives where
>> you can do a true low level format which rewrites the tracks.
>> Thats not that common at all anymore with embedded servo drives

> I dont think that is the main problem.

I never said it was. I said 'thats not that common at all anymore' for a reason.

Strictly speaking its very very uncommon now when hardly
anyone hard drives with stepper motor head actuators.

> The problem is that the low level format program
> needs to know what the number of notches is and what
> the number of sectors is per track within each notch.

Nope, the problem with modern embedded servo drives is that you
cant just erase the entire track and rewrite it, even its known how
many sectors should be written on that track coz without the
embedded servo information, the head cant even be positioned.

Some of the older servo drives did have an entire platter surface
entirely devoted to the tracks used by the servo system, no data
on that surface, but thats a rather expensive approach with drives
that only have a small number of platters and isnt seen much now.

Some of the higher capacity SCSI drives did use that
approach and you could often do a true low level format
and that allowed the drive to be reformatted with different
sized sectors which some systems did require.

Modern embedded servo drives are formatted at the factory
as part of the manufacturing process and its just not possible
to rewrite the entire track anymore. A bad sector that does
turn up because of say a power glitch etc is just added to the
bad sector list by a bad sector ute. Often very misleadingly
called a low level formatter even by the drive manufacturer.

> All this ofcourse based on the old Format Track
> command that was abandoned along time ago (ATA-3).

Yep, coz the drive cant even do a track format anymore, not possible.

But not for the reason you said, knowing how many sectors to write.

> I don't think it is that impossible to make such a program.

It is, there is nothing for the servo to use to position the heads
if the track is wiped prior to writing the track from scratch again.

> I just think that with the automatic reallocation of bad sectors
> in place the drivemakers just dont bother to have such a program.

You've got that backwards. The drive cant do a track format.
And a drive shouldnt be developing more than a trivial number
of new bad sectors unless its failing, so its perfectly viable to
just add an occasional one that turns up to the bad sector list.

>> but was very common with the earlier stepper motor
>> drives that got a phenomenon called sector jitter due to thermal
>> effects. A low level format would certainly fix bad sectors with them.

>>> You see, a bloke who clearly knows more than I do about such
>>> things in general (he's a PC support professional) recently told
>>> me that  one of the ways some modern demo programs "know"
>>> whether they've been installed previously is to mark a sector bad.

>> Yeah, thats been used for many years. Strictly speaking
>> thats not a bad sector tho, just one thats been marked bad.

>>> [And, presumably, put a bit of stuff in that sector to
>>> confirm that they've done it when they look again later?]

>> Can be done that way or just keep track of
>> where that phantom bad sector is on the drive.

>>> If this is so, then maybe there would be a way to recover such lost space?

>> Yep, in that case just an OS level format will do it.

> But not the standard one.

Maybe you mean the default one.

> That would recognize an existing format and only clear directories.

Yes, you do need to do an unconditional format with Win9x/DOS.

That aint the only OS around tho.

>>> Whether it would be worth the effort is another issue
>>> -- I guess it depends whether this scenario is real;
>>> and, if so, how many demos you trial. ;-)

>> You can get a situation where there is some problem in the
>> hard drive subsystem that sees lots of sectors marked as bad
>> at the OS level, say when you run scandisk etc. Once you fix
>> the cause of those bad sectors, an OS level format will recover
>> what has been marked as bad but which arent in fact bad at all.

> Format /u

Duh.
Technical Details
Message-ID: <SScy5.676$O7.19203@ozemail.com.au>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <39BDFD51.B7E5F82A@city.dk> <39c053b9.5158254@news.alphalink.com.au> <8q78tu$3m1$2@bunyip.cc.uq.edu.au> <SFQx5.21094$cr3.540937@ozemail.com.au> <8qah7r$t3d$2@news.hccnet.nl>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10d683,29c0a58112325f87
X-Google-Attributes: gid10d683,public
X-Google-Thread: 102bfa,4005d2dce8b95d07
X-Google-Attributes: gid102bfa,public
From: "Rod Speed" <rod_speed@yahoo.com>
Subject: Re: help to fix bad sectors
Date: 2000/09/21
Message-ID: <SScy5.676$O7.19203@ozemail.com.au>
X-Deja-AN: 672269191
Distribution: world
References: <39BDFD51.B7E5F82A@city.dk> <39c053b9.5158254@news.alphalink.com.au> <8q78tu$3m1$2@bunyip.cc.uq.edu.au> <SFQx5.21094$cr3.540937@ozemail.com.au> <8qah7r$t3d$2@news.hccnet.nl>
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Trace: ozemail.com.au 969497138 210.84.49.239 (Thu, 21 Sep 2000 11:45:38 EST)
Organization: OzEmail Ltd, Australia
X-MSMail-Priority: Normal
NNTP-Posting-Date: Thu, 21 Sep 2000 11:45:38 EST
Newsgroups: alt.msdos.programmer,aus.computers.ibm-pc