Option to skip some blocks with I/O errors during fsremap?

[schellingb]

Hi there

Sorry for the support request, but hopefully you can help me out.

I am in the process of converting a drive from jfs to ext4 and sadly after a few days of it chugging along nicely fsremap ended up encountering bad blocks and not getting over it. I retried a few times but it always aborts around the same sector.

I'm aware that the drive might be close to dying but at this point I am more curious if I can get anything out of this operation than really caring about the data (-:

Is there some option or way to get fsremap to skip the operations regarding the bad blocks or range of bad blocks? I don't mind if it would end up with a few hundred MB of unreadable data.

I thought of trying to forge a line in fsremap.persist to make fsremap think its further along but I'm not sure if that's a good idea. Also ideally I'd skip over only a few dozen MB and not GB.

Here's the error as reported by fsremap 2018-07-01 15:26:17 ERROR [io/io_posix.flush_copy_bytes(1089)] I/O error while copying from device to RAM, read({fd = 6, offset = 597347381248}, address + 44683264, length = 552960): Input/output error

And here's how the errors are reported in dmesg:

sd 32:0:1:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 32:0:1:0: [sdb] Sense Key : Medium Error [current]
sd 32:0:1:0: [sdb] Add. Sense: Unrecovered read error
sd 32:0:1:0: [sdb] CDB: 
Read(10): 28 00 45 8a 57 27 00 00 08 00
blk_update_request: critical medium error, dev sdb, sector 1166694183
Buffer I/O error on dev sdb1, logical block 145836765, async page read

Here are the full application logs: fstransform.log fsremap.log Would the other files (loop_extents.txt, free_space_extents.txt, fsremap.persist) be of any use here?

Thanks again for the tool and your time!

[cosmos72]

Hi @schellingb,

fsremap has no support to specify bad sectors, sorry.

Adding support for such a feature would be relatively straightforward, but it would require fsremap to know the bad blocks list at start or soon after starting; changing a (ipotetical) bad block list while running would break support for resuming an unfinished job.

Alternatively, you could hack io/io_posix.cc flush_copy_bytes() to ignore any read request (and maybe also any write request) in a certain range of the device - but this may cause a lot of missing data if part of that range happens to be used as "primary storage" (a kind of persistent buffer) by fsremap.

[schellingb]

I used dd to read around that area into /dev/null and figured a range of about 100mb that have bad blocks in it. Before and after that range dd was able to read quite large amounts of data with no issues. I'll try to add some kind of --skip-range=a-b option in flush_copy_bytes and see how that treats me. Should be fun :-) Thanks for the really quick response!

[cosmos72]

If the disk is not too badly damaged, I found by experience that writing zeroes with dd into the bad blocks often makes them readable and writeable again (after destroying whatever data was there), so that the disk can be used for a while more. It could be worth a try.

[schellingb]

I tried writing zeroes over the bad areas but it did not seem to resolve the read errors for me.

Here's the hack I am running for now:

err = ff_log(FC_ERROR, err, "I/O error while copying " CURRENT_OP_FMT, CURRENT_OP_ARGS);
if (read_dev && dev_offset >= 1166647304ULL*512ULL - length*5 && dev_offset <= 1166710592ULL*512ULL + length*5)
{
    ff_log(FC_ERROR, 0, "    Ignoring this read error due to being known bad sector");
    err = 0;
}
else break;

And so far only one error happened:

progress: 19.6% done,   1.4 terabytes still to remap
ERROR: I/O error while copying from device to RAM, read({fd = 5, offset = 597347381248}, address + 363536384, length = 552960): Input/output error
ERROR:     Ignoring this error due to being known bad sector

I'll close this issue for now. Now that I'm not afraid of code modifications I should find my way out of this one way or another :-)

Thanks again for the hints and infos!