On Fri Feb 01, 2013 at 10:27:57 -0700, Chris Murphy wrote:

On Feb 1, 2013, at 6:34 AM, Robin Hill [off-list ref] wrote:

quoted

It'd also be useful to know whether sdg has been rewritten at
all since then (i.e. whether the testing was destructive or not), and
whether or not the array was written to at all since the failure of sdg.

OP needs to reply back.

Also I'd like to know what model disks these are, if they're AF or not.

quoted

quoted

Yes, if sdg still contains valid array data (and the array wasn't

written since then) then it would definitely make more sense to recreate
the array using it, leaving sdj out for now. That'll require more work
checking mdadm versions and data offset values though. That'll avoid the
issues with the unreadable blocks on sdj.

Here's an idea. One possibility is to use dd to read the sector on
sdg1 that error1.txt reported with the write error, to a file, and see
if there's a read error. If not, rewrite that data back to the same
sector and see if there's a write error. If not, attempt to force
assemble assume clean, get the array up in degraded mode, and do a
non-destructive fsck. If that's OK, just take a backup immediately.
Then sdj can be destructively written to, to force bad sectors there
to be removed for reserves, but still needs a smart extended offline
test to confirm; and then possibly reused and rebuilt.

That won't work. He's already lost the metadata on sdg1 by trying to
rebuild it in the first place, so a force assemble won't work. He'd need
to recreate the array instead. Otherwise yes, that would sound to be the
best option (assuming there's no other read errors on the other disks).

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        [off-list ref] |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |