Author: Brad Campbell Date: To: dng Subject: Re: [DNG] Can this drive be saved?
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.
This message was posted to the following mailing lists: