That's quite strange. What version of ZFS are you running? What does 'zdb -l /dev/dsk/c5t6006016031E0180032F8E9868E30DB11d0s0' show?
- eric On Thu, Mar 01, 2007 at 09:31:05AM +1000, Stuart Low wrote: > Hi there, > > We have been using ZFS for our backup storage since August last year. > Overall it's been very good, handling transient data issues and even > drop outs of connectivity to the iscsi arrays we are using for storage. > However, I logged in this morning to discover that the ZFS volume could > not be read. In addition, it appears to have marked all drives, mirrors > & the volume itself as 'corrupted'. > > >From what I can tell I'm completely unable to perform a zpool import and > the only solution according to SUN is to 'destroy and recreate the > volume from a backup'. That's not overly helpful considering this IS our > backup source AND the fact we thought we had redundancy covered through > the implementation of multiple mirrors. The arrays themselves are > configured in 5 x 880GB RAID5 LUNs per array. These 5 are then mirrored > to their matching 5 on the other array. > > To be honest, I'm pretty disappointed this occurred. I was of the > assumption that by setting up a set of mirrored volumes I would avoid > this exact problem. Now, for whatever reason (perhaps triggered by an > iscsi connection timeout) ZFS has decided all devices in the entire > array are corrupt. I guess that's why assumptions are the mother of > all ......s. :) > > While this data isn't mission critical it IS of significant use to us > for historical analysis purposes so my assistance would be greatly > appreciated. > > I've included a dump of the zpool import response below. > > Thanks for your help! > > Stuart > > ---- > > [EMAIL PROTECTED] ~]$ zpool import > pool: ax150 > id: 6217526921542582188 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > see: http://www.sun.com/msg/ZFS-8000-5E > config: > > ax150 FAULTED corrupted data > mirror FAULTED corrupted data > c5t6006016031E0180032F8E9868E30DB11d0 FAULTED corrupted data > c5t6006016071851800B86C8EE05831DB11d0 FAULTED corrupted data > mirror FAULTED corrupted data > c5t6006016031E01800AC7E34918E30DB11d0 FAULTED corrupted data > c5t600601607185180010A65FE75831DB11d0 FAULTED corrupted data > mirror FAULTED corrupted data > c5t6006016031E0180026057F9B8E30DB11d0 FAULTED corrupted data > c5t6006016071851800CA1D94EF5831DB11d0 FAULTED corrupted data > mirror FAULTED corrupted data > c5t6006016031E018005A9B74A48E30DB11d0 FAULTED corrupted data > c5t600601607185180064063BF85831DB11d0 FAULTED corrupted data > mirror FAULTED corrupted data > c5t6006016031E018003810E7AC8E30DB11d0 FAULTED corrupted data > c5t60060160718518009A7926FF5831DB11d0 FAULTED corrupted data > [EMAIL PROTECTED] ~]$ > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
