On Oct 26, 2007, at 3:21 AM, Matt Buckland wrote: > Hi forum, > > I did something stupid the other day, managed to connect an > external disk that was part of zpool A such that it appeared in > zpool B. I realised as soon as I had done zpool status that zpool B > should not have been online, but it was. I immediately switched off > the machine, booted without that disk connected and destroyed zpool > B. I managed to get zpool A back and all of my data appears to be > there, but I have a data error which I am unable to track. > Apparently it is: > > DATASET 0, OBJECT a, RANGE lvl=0 blkid=0
this was from 'zpool status -v', right? > > I have found this line from output of zdb: > > Dataset mos [META], ID 0, cr_txg 4, last_txg 1759562, 406M, 362 > objects > > Is anyone able to shed any light on where this error might be and > what I might be able to do about it? I do not have a backup of this > data so restoring is not an option. > > Any advice appreciated. So in general,if you can upgrade to more recent bits, then ZFS will happily just tell you what file that is, see: http://blogs.sun.com/erickustarz/entry/damaged_files_and_zpool_status If you cannot upgrade, then see: http://www.opensolaris.org/jive/thread.jspa?messageID=39450&tstart=0 But in your case, you've corrupted a piece of the metadata (object 0xa of the MOS). You can run 'zdb -dv <poolname>' to figure out what you've corrupted. For example: fsh-hake# zdb -dv d Dataset mos [META], ID 0, cr_txg 4, 120K, 34 objects Object lvl iblk dblk lsize asize type 0 1 16K 16K 32K 12.0K DMU dnode 1 1 16K 512 512 1.50K object directory 2 1 16K 512 512 0 DSL directory 3 1 16K 512 512 1.50K DSL props 4 1 16K 512 512 1.50K DSL directory child map 5 1 16K 512 512 0 DSL dataset 6 1 16K 512 512 1.50K DSL dataset snap map 7 1 16K 128K 128K 0 bplist 8 1 16K 512 512 0 DSL directory 9 1 16K 512 512 1.50K DSL props 10 1 16K 512 512 1.50K DSL directory child map 11 1 16K 16K 16K 4.50K packed nvlist 12 1 16K 16K 16K 48.0K bplist (Z=uncompressed) 13 1 16K 128K 128K 15.0K SPA history ... Object 0xa would be the " DSL directory child map" object on my pool. As you can guess, corrupting a core piece of metadata is a bad place to be. Your mileage may vary... If you can still access all your data, the best may be to copy the data (or send/recv) to a backup, destroy & re-create the pool. eric _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
