my company changed our SAN and I migrated our zpool to the new luns with
attach/detach while the zpool stayed online. Once finished we had a cluster
crash and the zpool (on new luns) get corrupted. No way to import it, zpool
import -fFX failed.
The old luns are detached and probably sane from
your point have only a rethoric meaning. System breaks regardless the ressource
you put to build it. Bad hardware, typo, human mistakes, bugs, This
mailing-list is full of examples. Having some tools like zdb, mdb, zfs import
-fFX and labelfix for analyzis and repair is always a good thing.
Hi,
labelfix http://www.opensolaris.org/jive/thread.jspa?messageID=229969 saved
already a lot of data as it makes dettached devices "importable".
A quick test today shows labelfix won't work anymore:
#uname -a
SunOs bigmama 5.11 snv_127 i86pc 386 i86pc Solaris
#./labelfix /dev/rdsk/c0d1s4
ld.so
Hi,
sometimes ago Jeff Bonwick provides source code and x86-binary for a tool to
recover detached disks.
Refs at http://www.opensolaris.org/jive/thread.jspa?messageID=229969 or
http://opensolaris.org/jive/thread.jspa?messageID=303895
Does someone have an binary for sparc at hand? I can´t comp
Hi,
since hostid is stored in the label, "zpool import" failed if the hostid dind't
match. Under certain circonstances (ldom failover) it means you have to
manually force the zpool import while booting. With more than 80 LDOMs on a
single host it will be great if we could configure the machine
Well, thanks your program, I could recover the data on the detach disk. Now I m
copying the data on other disks and resilver it inside the pool.
Warm words aren't enough to express how I feel. This community is great. Thanks
you very much.
bbr
This message posted from opensolaris.org
_
thanks for the quick reaction. I ve now a working binary for my system.
I don't understand why these changes should go through a project. The hooks
are already there so once the code is written no much work have to be done. But
it's an other story. Lets decode lzjb blocks now :-)
bbr
This
I 'm trying to decode a lzjb compressed blocks and I have some hard times
regarding big/little endian. I'm on x86 working with build 77.
#zdb - ztest
...
rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:e0c98e00:200>
...
## zdb -R ztest:c0d1s4:e0c98e00:200:
Found vdev: /dev/dsk/c
Hi,
Great stuff.
Does this change will make it into opensolaris? Looking at actual code I
couldn't find the modification.
I try to replace zdb.c in the opensolaris main tree before compiling with
nightly but the compiler wasn't happy with it. Can you write down the right
options?
bbr
Thi
it is on x86.
Does it means that I have to split the output from digest in 4 words (each 8
bytes) and reverse each before comparing with the stored value?
bbr
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensol
Hi,
while diving deeply in zfs in order to recover data I found that every
uberblock in label0 does have the same ub_rootbp and a zeroed ub_txg. Does it
means only ub_txg was touch while detaching?
Hoping it is the case, I modified ub_txg from one uberblock to match the tgx
from the label a
If I understand you correctly the steps to follow are:
read each sector (dd bs=512 count=1 split=n is enough?)
decompress it (any tools implementing the algo lzjb?)
size = 1024?
structure might be objset_phys_t?
take the oldest birth time as the root block
c
Jeff thank you very much for taking time to look at this.
My entire pool consisted of a single mirror of two slices on different disks A
and B. I attach a third slice on disk C and wait for resilver and then detach
it. Now disks A and B burned and I have only disk C at hand.
bbr
This messag
Hi,
my system (solaris b77) was physically destroyed and i loosed data saved in a
zpool mirror. The only thing left is a dettached vdev from the pool. I'm aware
that uberblock is gone and that i can't import the pool. But i still hope their
is a way or a tool (like tct http://www.porcupine.org/
14 matches
Mail list logo
