On Mon, Apr 23, 2012 at 02:16:40PM +1200, Ian Collins wrote:
> If it were my data, I'd set the pool read only, backup, rebuild and  
> restore.  You do risk further data loss (maybe even pool loss) while the  
> new drive is resilvering.

You're definitely in a pickle.  The first priority is to try and
ensure that no further damage is done. Check and make sure you have
ample power supply. 

Setting the pool readonly would be a good start.  Powering down and
checking all the connectors and cables would be another. 

Write errors are an interesting result. Check the smart data on that
disk - either it is totally out of sectors to reallocate, or it has
some kind of interface problem.

If you can, image all the disks elsewhere, with something like
ddrescue.  Doing so sequentially rather than random IO through the
filesystem can sometimes have better results for marginal
disks/sectors.  That gives you scratch copies to work on or fall back
to, as you try other recovery methods. 

zfs15 is fairly old..  Consider presenting a copy of the pool to a
newer solaris that may have more robust recovery, as one experiment.

I wouldn't "zpool replace" anything at this point - the moment you do,
you throw away any of the good data on that disk, which might help you
recover sectors that are bad on other disks.  If you have to swap
disks, I would try and get as many of the readable sectors copied 
across to the new disk as possible (ddrescue again) with the pool
offline, and then just physically swap disks, so at least the good
data remains usable.

Try and get some clarity on what's happening with the hardware on a
individual disk level - what reads successfully (at least at the
physical layer, below zfs chksum).  Try and get at the root cause of
the write errors first; they're impeding zfs's recovery of what looks
like other 

> I would only use raidz for unimportant data, or for a copy of data from  
> a more robust pool.

Well, yeah, but a systemic problem (like bad ram or power or
controller) can manifest as a multi-disk failure no matter how many
redundant disks.


Attachment: pgpQQcIoIuOpx.pgp
Description: PGP signature

zfs-discuss mailing list

Reply via email to