1

When a hard drive is writing to the disc, how does it know if a sector is bad when it's writing to it, if it was known previously as good? As far as I know it doesn't read back the data it has written, it just lays it down, correct?

Does it just get feedback that the magnetic field strength isn't high enough? Or would it only be detected during the next read process of that sector?

HTWingNut
  • 461
  • 2
  • 8
  • 25
  • 3
    I believe most are detected on next read, when the sector's data is found to be different than the ECC code describes. I am sure that it doesn't reread the data when calculating the ECC (because then the ECC would describe the broken data, not its correct state), but I'll admit I don't know if it will attempt to reread after the ECC is written. – Frank Thomas Apr 20 '22 at 19:31

1 Answers1

2

When a hard drive is writing to the disc, how does it know if a sector is bad when it's writing to it, if it was known previously as good?

It doesn't.
A HDD write operation is performed without any feedback. Whether or not the sector data (with its ECC) was actually written correctly can only be verified by waiting a revolution of the platter, and then performing a read operation of that sector/LBA.

A bad block/sector is only detected on a read, and not on a write. The only error when writing would be if the sector/LBA could not be found. Once the proper sector is located, the write operation commences blindly. There is no measurement of the "magnetic field strength". When the R/W head is busy engaged in write mode, it cannot also perform a read operation.

As far as I know it doesn't read back the data it has written, it just lays it down, correct?

Correct, for a conventional HDD and its typical operation.
If a concurrent read operation were to be performed, that would require an additional read head far away from the write head so as to not be affected. That would either require increasing the size, weight, and geometry of the R/W head assembly, or another, separate read head assembly. Either solution implies increased cost and complexity, while decreasing overall reliability.

The realtime cost of performing a read-after-write to verify the write operation on a conventional HDD would be the time to wait for one revolution of the platter(s). Typically this delay is considered an unacceptable performance reduction when compared to the reliability of HDD writes. Overall the cause of data loss is probably more likely to be due to some other form of drive failure.

Or would it only be detected during the next read process of that sector?

The typical definition of a bad block/sector is a block that has uncorrectable errors when read. The cause of bit errors (e.g. head flying too high, surface wear or damage) is irrelevant (even if it could be determined).
A filesystem or embedded controller might apply additional criteria (such as a subsequent write still fails to produce a correctable read) to avoid flagging a one-off failure.
A block that has correctable errors when read is still considered good.
The maximum number of bits that can be corrected (in the read block) is an intrinsic property of the ECC, error (detection &) correction code, employed.

sawdust
  • 17,383
  • 2
  • 36
  • 47
  • Thank you for taking the time for that detailed response. That is what I assumed. So if data has been written to a "bad" block or sector it could sit there for a while until that block is actually read again by a surface scan or file read operation? Also, when you go to full format a disk (say Windows format command) it looks like it is purely a write operation, it could format successfully but still have bad sectors then, so a subsequent surface scan should be completed? – HTWingNut Apr 21 '22 at 14:48
  • "*So if data has been written to a "bad" block ...*" -- One more time: errors can be detected when the ECC is applied to validate the read data. The number of bit errors can be correctable or uncorrectable. See https://superuser.com/questions/1554322/why-there-is-no-ecc-ram-type-device-invented-to-bypass-bad-sectors-in-hdd/1554342#1554342 The definition or criteria for a "bad block" is implementation specific. It would make more sense IMO to perform a surface scan (e.g. SMART extended test) *before* a format & putting it to use. – sawdust Apr 21 '22 at 18:25