On 5/9/20 10:38 pm, Simon Walter wrote:
On 9/5/20 12:50 PM, Gregory Nowak wrote:
On Sat, Sep 05, 2020 at 12:26:21PM +0900, Simon Walter wrote:
Reallocation, to my knowledge, should happen in the background. It's
*possible* that the reallocation event and the FS corruption are unrelated.
My understanding is that the drive won't attempt to reallocate a
sector until that sector is written to. So, if the e2fsck -f did try
to write to that sector, the drive did reallocate it in the
background. I do stand to be corrected as always.
Interesting. I think reallocation also happens as part of SMART self checks and
reads.
It really doesn't. It'll mark a sector as "pending" (as in, I can't read from
it so I'll mark it for later).
You can try reading from the sector repeatedly and if you get a good read,
write it back. Spinrite does that and it has about an even-odds success rate.
It's old, clunky, slow and it's capabilities are very over-sold however. It's
really a one trick pony.
A drive will absolutely not re-allocate a sector until it is written to. Then
it will first try and re-write the sector in case the error is due to something
like a power loss or other transient. Failing a good write it'll then
reallocate and write the data to another (transparent) location.
The issue with a SMART long test (or any SMART media test in fact) is it'll abort on the
first bad sector. If you really want to read every sector and mark *all* the duds as
pending then you need something like dd conv=noerror with a blocksize of whatever the
smallest sector the disk supports (4k for most SATA spinners). That'll chew through the
sectors and the drive will flag every bad read as "pending".
I have drives that have > 70,000h on them with one or two reallocated sectors.
I've also had drives grow them at a rapid rate. SMART isn't all that good at
actually predicting pending failure. Analysis of the raw data on a large
population of the same disk is better, but the best is to avoid the worry with
up-to-date backups.
Regards,
Brad
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
