If a drive has reallocated sectors, did it lose data?

  • Thread starter Thread starter Guest
  • Start date Start date
Does it read the sector to verify it was written successfully?

That varys with the drive manufacturer.
What about a sector that hasn't been marked pending - the drive tries
to write to it and it fails. Does the drive read the sector immediately
after the write to find out that it failed (the data doesn't match)?

You can specify that behaviour.

Some drives even vary that auto with some of the Maxtors having auto
verify on by default for a manufacturer specified time after first use.
 
That varys with the drive manufacturer.

What an utter clueless answer. Rod the insightless at its best.

Of course it will verify. If it did not, then there would never
be a reallocation and in surface problems the sector would just
go bad again.

Generally no. The write will only fail if there is some problem
with locating the sector. Otherwise the write will succeed, but
the data will be bad (if there is a surface problem).
You can specify that behaviour.

Not generally. And it kills performance rather badly. The right
way to do this is to run regular long SMART selftests, which include
surface scans. Sectors are either obviously bad or the data
will take soem time to become unreadable. Running a full surface test
every 7-14 days prevents that from going unnoticed.
Some drives even vary that auto with some of the Maxtors having auto
verify on by default for a manufacturer specified time after first use.

Wich is something pretty historic and not relevant anymore. Also,
because it is not under user control, it is pretty irrelevant.

Arno
 
What an utter clueless answer. Rod the insightless at its best.

We'll see...
Of course it will verify. If it did not, then there would never
be a reallocation and in surface problems the sector would just
go bad again.

I wasn’t talking about what happens with pending sectors,
I was talking about writes in general.
Generally no. The write will only fail if there is some problem
with locating the sector. Otherwise the write will succeed, but
the data will be bad (if there is a surface problem).
Not generally.

Yes, generally.
And it kills performance rather badly.

That’s why its off by default. You can turn it on if
you prefer to see whether the write has failed or
not instead of just hoping for the best with the
write and don’t care about the performance hit.

The performance hit isnt necessarily that bad
with lots of activity on the drive with the drive
being able to reorder the sequence of sectors
it reads and writes etc and caching that so the
system doesn’t see that happening.
The right way to do this is to run regular long
SMART selftests, which include surface scans.

That’s just one way to do it. The other way
by turning the verify after write works fine
with modern high performance drives if you
don’t need the ultimate in write performance.

Few systems do need the ultimate in write
performance anymore and the security of
the data is much more important.
Sectors are either obviously bad or the data will take
soem time to become unreadable. Running a full surface
test every 7-14 days prevents that from going unnoticed.

Yes, but you don’t get notified on the first write failure.
Wich is something pretty historic and not relevant anymore.

Those drives are still being made, just not with that brand now.
Also, because it is not under user control, it is pretty irrelevant.

Pity that is under user control if the user wants to control that behaviour.
 
Generally no. The write will only fail if there is some problem
with locating the sector. Otherwise the write will succeed, but
the data will be bad (if there is a surface problem).

If the write succeeds but with bad data, can you tell there is a
problem when you try to read the data later? Does the data get
written with a CRC so that the read operation can tell there is a
mismatch and return an error to the OS?
 
If the write succeeds but with bad data, can you tell there is a
problem when you try to read the data later? Does the data get
written with a CRC so that the read operation can tell there is a
mismatch and return an error to the OS?

Yes, that's the whole point of the CRC.
 
Back
Top