On Fri Feb 01, 2013 at 10:27:57 -0700, Chris Murphy wrote:
>
> On Feb 1, 2013, at 6:34 AM, Robin Hill <robin@xxxxxxxxxxxxxxx> wrote:
> > 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.
>
> >> 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 <robin@xxxxxxxxxxxxxxx> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
Attachment:
pgpOZI3Dn9nGo.pgp
Description: PGP signature
