Well I managed to get my pool back up, unconventionally though... I got to thinking about how my data was fine before the replace so I popped the cable off of the new disk and walla! The spare showed back up and the pool imported in a degraded state.
Something must have gotten botched in the replace process. I'm not complaining though - I'm just happy to have my data back! I'm pumping it off to some other systems as I write this. Thanks for the troubleshooting help Rob! On Tue, May 20, 2008 at 11:30 PM, <[EMAIL PROTECTED]> wrote: > > hmm, we don't need the spare to import... why can't it > find all the replicas ? > > > 22 % zpool status t > pool: t > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > t ONLINE 0 0 0 > /tmp/t/1 ONLINE 0 0 0 > /tmp/t/2 ONLINE 0 0 0 > /tmp/t/3 ONLINE 0 0 0 > spares > /tmp/t/4 AVAIL > > errors: No known data errors > > [EMAIL PROTECTED]:20am]/tmp/t > 23 % zpool export t > > [EMAIL PROTECTED]:20am]/tmp/t > 24 % zpool import -d /tmp/t > pool: t > id: 17399716211509349258 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > t ONLINE > /tmp/t/1 ONLINE > /tmp/t/2 ONLINE > /tmp/t/3 ONLINE > spares > /tmp/t/4 > > [EMAIL PROTECTED]:21am]/tmp/t > 25 % rm 4 > > [EMAIL PROTECTED]:21am]/tmp/t > 26 % zpool import -d /tmp/t > pool: t > id: 17399716211509349258 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > t ONLINE > /tmp/t/1 ONLINE > /tmp/t/2 ONLINE > /tmp/t/3 ONLINE > spares > /tmp/t/4 > > [EMAIL PROTECTED]:21am]/tmp/t > 27 % zpool import -d /tmp/t t > > [EMAIL PROTECTED]:21am]/tmp/t > 28 % zpool status t > pool: t > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > t ONLINE 0 0 0 > /tmp/t/1 ONLINE 0 0 0 > /tmp/t/2 ONLINE 0 0 0 > /tmp/t/3 ONLINE 0 0 0 > spares > /tmp/t/4 UNAVAIL cannot open > > errors: No known data errors > > > [EMAIL PROTECTED]:28am]/tmp/t > 29 % zdb t > version=10 > name='t' > state=0 > txg=59 > pool_guid=17399716211509349258 > hostid=412362551 > hostname='nas' > vdev_tree > type='root' > id=0 > guid=17399716211509349258 > children[0] > type='file' > id=0 > guid=15245170032604671105 > path='/tmp/t/1' > metaslab_array=18 > metaslab_shift=19 > ashift=9 > asize=62390272 > is_log=0 > children[1] > type='file' > id=1 > guid=9290417401797660415 > path='/tmp/t/2' > metaslab_array=16 > metaslab_shift=19 > ashift=9 > asize=62390272 > is_log=0 > children[2] > type='file' > id=2 > guid=15670568631977390655 > path='/tmp/t/3' > metaslab_array=14 > metaslab_shift=19 > ashift=9 > asize=62390272 > is_log=0 > Uberblock > > magic = 0000000000bab10c > version = 10 > txg = 61 > guid_sum = 2265640056760416585 > timestamp = 1211344095 UTC = Wed May 21 00:28:15 2008 > > Dataset mos [META], ID 0, cr_txg 4, 96.0K, 21 objects > Dataset t [ZPL], ID 5, cr_txg 4, 18.0K, 4 objects > > Traversing all blocks to verify checksums and verify nothing leaked ... > > No leaks (block sum matches space maps exactly) > > bp count: 32 > bp logical: 344064 avg: 10752 > bp physical: 43520 avg: 1360 compression: 7.91 > bp allocated: 121344 avg: 3792 compression: 2.84 > SPA allocated: 121344 used: 0.06% > > capacity operations bandwidth ---- errors ---- > description used avail read write read write read write cksum > t 119K 178M 152 0 1.91M 0 0 0 0 > /tmp/t/1 42.5K 59.5M 80 0 650K 0 0 0 0 > /tmp/t/2 33.5K 59.5M 31 0 653K 0 0 0 0 > /tmp/t/3 42.5K 59.5M 41 0 650K 0 0 0 0 > > > -- Christopher Gibbs Programmer / Analyst Web Integration & Programming Abilene Christian University _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
