Conversation
Notices
-
well, 395211 MB copied, out of about 1.1TB... no errors so far, but every now and then it... *pauses*, or seems to: that suggests it has trouble reading some sectors, though it ultimately succeeds. nothing I can do about that,and I doubt if increasing clustersize on input would make a difference. so, off to my #hammock I go! good night !tzaf !fediverse! #tomorrow... ddrescue will still be running (at least, I hope it doesn't give up!) ;-)
-
-
@mcscx I know it tells me about IO errors, but I've never seen anything about needing retries to successfully read
-
@mk I think I've seen messages when a drive is trying hard to reread a block, but not sure. Also interesting: smartctl -a /dev/...
-
@mcscx I remember low-level tools under DOS (MS or DR) could reveal these retries; for a floppy the standard was up to 5 attempts before the OS would get a signal: these tools would talk directly to the controller, I think. Then there were (still are) repair tools like SpinRite: often the cause of a bad sector is simply too weak magnetization, and this may be repaired by (repeated) rewrites - read a sector and then repeatedly write it back to 'refresh' the magnetization - of course, also at HW sector level. I had a copy of SpinRite and regularly used it on my dodgy HD. I wonder if I could reproduce something like that with Linux tools... Anyway, I doubt dmesg is low-level enough to reveal the re-reads.
-
@mcscx another last-resort technique can be used if the bad blocks are localized near each other: partition "around" them, by creating 2 or more partitions that avoid the bad area. That's another technique I've used successfully under DOS :) This should be possible under Linux as well - you just need to be able to calculate exactly where the bad areas are (or find a tool that shows this).
-
@mk you can partition around areas of bad blocks in Linux. But disks with bad blocks tend to get more bad blocks.
-
@mcscx you can do that in any partitioning tool on any OS - you just need to know where the bad blocks *are*. But given that bad blocks can have different causes, that may, or may not be sufficient - whether there will be more bad blocks depends on the cause
-
-
-
-
-
-
@mk by now (the next morning) ddrescue has made it past the data area (total data about 1.1TB, it's now copied 2389 GB); it also shows 'errsize: 3559 kB errors: 6'; more interesting, read speed has considerably slowed down: the *current* rate is around 25000 kb/s now, while it started at about 170 MB/s; current rate is also ch slower than average rate now (so the latter keeps decreasing). The old drive feels warmer than the new one...
-
@mk the first 'sweep' of ddrescue is now finished - still "6 errors" which (going by the log file) are 6 areas *between* the completely "finished" blocks. The next "sweep" will now try to "fill in" blocks inside those error areas (though I have little hope that'll actually make a difference). theoretically, this should complete faster than the first sweep - let's see...
-
@mk actually, that was super-fast: it merely "consolidated" the bad/unsplit areas into single bad blocks. So, now we let e2fsck loose on the 'rescued' result...
-
-
-
