zfs discuss - Oct 2007 - data error in dataset 0. what''s that?

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

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.

Thanks,

Matt
 
 
This message posted from opensolaris.org

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