| 1 |
On 08/11/2022 13:20, Michael wrote: |
| 2 |
> On Tuesday, 8 November 2022 03:31:07 GMT Grant Edwards wrote: |
| 3 |
>> I've got an SSD that's failing, and I'd like to know what files |
| 4 |
>> contain bad blocks so that I don't attempt to copy them to the |
| 5 |
>> replacement disk. |
| 6 |
>> |
| 7 |
>> According to e2fsck(8): |
| 8 |
>> |
| 9 |
>> -c This option causes e2fsck to use badblocks(8) program to do |
| 10 |
>> a read-only scan of the device in order to find any bad blocks. If any |
| 11 |
>> bad blocks are found, they are added to the bad block inode to prevent |
| 12 |
>> them from being allocated to a file or directory. If this option is |
| 13 |
>> specified twice, then the bad block scan will be done using a |
| 14 |
>> non-destructive read-write test. |
| 15 |
>> |
| 16 |
>> What happens when the bad block is _already_allocated_ to a file? |
| 17 |
>> |
| 18 |
>> -- |
| 19 |
>> Grant |
| 20 |
> |
| 21 |
> Previously allocated to a file and now re-allocated or not, my understanding |
| 22 |
> is with spinning disks the data in a bad block stays there unless you've dd'ed |
| 23 |
> some zeros over it. Even then read or write operations could fail if the |
| 24 |
> block is too far gone.[1] Some data recovery applications will try to read |
| 25 |
> data off a bad block in different patterns to retrieve what's there. Once the |
| 26 |
> bad block is categorized as such it won't be used by the filesystem to write |
| 27 |
> new data to it again. |
| 28 |
> |
| 29 |
> With SSDs the situation is less deterministic, because the disk's internal |
| 30 |
> wear levelling firmware moves things around according to its algorithms to |
| 31 |
> remap bad blocks. This is all transparent to the filesystem, block addresses |
| 32 |
> sent to the fs are virtual anyway. Bypassing the firmware controller to |
| 33 |
> access individual cells on an SSD requires specialist equipment and your own |
| 34 |
> lab, although things may have evolved since I last looked into this. |
| 35 |
|
| 36 |
Which is actually pretty much exactly the same as what happens with |
| 37 |
spinning rust. |
| 38 |
|
| 39 |
The primary aim of a hard drive - SSD or spinning rust - is to save the |
| 40 |
user's data. If the drive can't read the data it will do nothing save |
| 41 |
returning a read error. Think about it - any other action will simply |
| 42 |
make matters worse, namely the drive is actively destroying |
| 43 |
possibly-salvageable data. |
| 44 |
|
| 45 |
All being well, the user has raid or backups, and will be able to |
| 46 |
re-write the file, at which point the drive will attempt recovery, as it |
| 47 |
now has KNOWN GOOD data. If the write fails, the block will then be |
| 48 |
added to the *drive internal* badblock list, and will be remapped elsewhere. |
| 49 |
|
| 50 |
MODERN DRIVES SHOULD NEVER HAVE AN OS-LEVEL BADBLOCKS LIST. If they do, |
| 51 |
something is seriously wrong, because the drive should be hiding it from |
| 52 |
the OS. |
| 53 |
> |
| 54 |
> The general advice is to avoid powering down an SSD which is suspected of |
| 55 |
> corruption, until all the data is copied/recovered off it first. If you power |
| 56 |
> it down, data on it may never be accessible again without the aforementioned |
| 57 |
> lab. |
| 58 |
|
| 59 |
Seriously, this is EXTREMELY GOOD advice. I don't know whether it is |
| 60 |
still true, but there have been plenty of stories in the past about |
| 61 |
SSDs, when they get too many errors, they self-destruct on power-down!!! |
| 62 |
|
| 63 |
This imho is a serious design fault - you can't recover data from an SSD |
| 64 |
that won't boot - but the fact is it appears to be a deliberate decision |
| 65 |
by the manufacturers. |
| 66 |
> |
| 67 |
> BTW, running badblocks in read-write mode on an ailing/aged SSD may exacerbate |
| 68 |
> the problem without much benefit by accelerating wear and causing additional |
| 69 |
> cells to fail. At the same time you could be relying on the suspect disk |
| 70 |
> firmware to access via its virtual map the data on some of its cells. Data |
| 71 |
> scrubbing (btrfs, zfs) and recent backups would probably be a better strategy |
| 72 |
> with SSDs. |
| 73 |
> |
| 74 |
Yup. If you suspect badblocks have damaged your data, you need backups |
| 75 |
or raid. And then don't worry about it - apart from making sure your |
| 76 |
drives look healthy and replacing any that are dodgy. |
| 77 |
|
| 78 |
Just make sure you interpret smartmontools data correctly - perfectly |
| 79 |
healthy drives can drop dead for no apparent reason, and drives that |
| 80 |
look at death's door will carry on for ever. In particular, read errors |
| 81 |
aren't serious unless they are accompanied by a growing number of |
| 82 |
relocation errors. If the relocation number jumps, watch it. If it |
| 83 |
doesn't move while you're watching, it was probably a glitch and the |
| 84 |
drive is okay. But use your head and be sensible. Any sign of regular |
| 85 |
failed writes, BIN THE DRIVE. |
| 86 |
|
| 87 |
(I think my 8TB drive says 1 read error per less-than-two end-to-end |
| 88 |
scans is well within spec...) |
| 89 |
|
| 90 |
Cheers, |
| 91 |
Wol |
Archives