User error

[GoogleCodeExporter]

Really not sure this is the right place to post this, if not then sorry for 
that. However, I need some help!

What steps will reproduce the problem?
1.  Upon rebooting the MacMini ZFS pool is gone
2.
3.

What is the expected output? What do you see instead?
Was working great, had 2 drives in the pool, moved over a number of files into 
the pool, then had to reboot the machine, and then i get a message that the 2 
drives are unreadable, eject ignore etc message pops up.
My fear is that I lost my data that I put on there as there does not see to be 
any way to bring back the pool.

What version of the product are you using? On what operating system?
Using 74.1.0 on 10.7

Please provide any additional information below.
I followed the GettingStarted commands to the letter, and created a simple pool 
with 2 external firewire drives.  All went great.  Everything was healthy.  
Copied files, all good.  Then rebooted and all was lost, :(.

Anyway I can recover the data/pool?

Thanks for any help.

Original issue reported on code.google.com by markanth...@med.ge.com on 24 Feb 2012 at 2:33

[GoogleCodeExporter]

If you do `diskutil list`, are the ZFS partitions still there?
Can you do a `zpool import <pool>` if the partitions exist?

Original comment by druro...@gmail.com on 24 Feb 2012 at 8:58

[GoogleCodeExporter]

Sadly no, I get this:

/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *999.5 GB   disk3
   1:                       0xEE                         999.5 GB   disk3s1

Looking around I got the tool gdisk (and hopefully am not doing stupid things)

i see this when i print out the GPT:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640      1951889367   930.5 GiB   BF01  %noformat%
 121  72057594172145664  576460752303423488   224.0 EiB   FFFF  
 122  7813586405489115136    431266031455   4.6 ZiB     FFFF  鎈鯞ꅼ턭
 123        16777216  2305843009230471168   1024.0 EiB  FFFF  祴数
 124  720575940396056576  8316288341928928303   3.3 ZiB     FFFF  
 125  576460752303453286        16777216   7.8 ZiB     FFFF  

I then decided to delete the crazy 121-125 partitions...(hope i didn't do 
something stupid).  I am hoping that my data is still secure in the correct 
partition 2.

Now what I see when I run diskutil list:

/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *999.5 GB   disk3
   1:                        EFI                         209.7 MB   disk3s1
   2:                        ZFS                         999.2 GB   disk3s2

seems to bring me back to a good state!  But not sure what to do next...

Original comment by markanth...@med.ge.com on 24 Feb 2012 at 10:49

[GoogleCodeExporter]

I tried the zpool import MediaHD and I get.

cannot import 'MediaHD': pool may be in use from other system
use '-f' to import anyway

If I reboot, I am back to square 1 with the corrupted GPTs...

My main concern is getting the data off the partitions, any tool to help me 
recover those files?

Super thanks for your help!

Original comment by markanth...@med.ge.com on 24 Feb 2012 at 10:55

[GoogleCodeExporter]

Partition type 0xEE is a composite type of MBR and GPT. Not sure why it's being 
labeled as that. Maybe someone else here has seen this before?

Did you try doing `zpool import -f MediaHD` to see if you could import the pool 
anyways? If you can make it mount, your data recovery will be much easier while 
you figure out why the partition table keeps freaking out.

Original comment by druro...@gmail.com on 25 Feb 2012 at 12:31

[GoogleCodeExporter]

Sadly no, it tells me that the pool is in use and won't let me.

Original comment by markanth...@med.ge.com on 25 Feb 2012 at 6:11

[GoogleCodeExporter]

I tried looking at standard tools to get data off drives, like disk drill, but 
it does not recognize the drives so i cannot even start to a deep scan or 
anything to get the data off.

I have a backup, but not sure of exactly whats missing from there and the 
"event" , but wanted to try anything i can before going that route to not lose 
that.

Original comment by markanth...@med.ge.com on 25 Feb 2012 at 8:05

[GoogleCodeExporter]

okay, I tried 'zpool import -f MeidaHD' and it works; but, now the disk is 
empty! :(

In my struggles, i did re-run the procedures in getting started without the 
format part, in hopes that recreating the pool would bring back the 
data...seems like its gone now!

Anyway to get the data off?

Thanks again for the help...

Original comment by markanth...@med.ge.com on 26 Feb 2012 at 11:36

[GoogleCodeExporter]

Recreating the pool recreates the four copies of the Uberblock, I'm pretty 
sure. At this point, you /might/ be out of luck, since ZFS' on-disk format is 
fairly complex (see PDF in download section if you want to know).

The problem is, without a good Uberblock, there is no easy or sure way of 
finding the root of the filesystem(s). The Copy-On-Write means that you could 
find a tree, but it may be out of date... worse, it could be from the new pool, 
and is a dead end.

Worst case: The pool recreation has clobbered the old data and there are large 
chunks of it that can't be recreated due to missing metadata.

Best case: The pool recreation has only clobbered the Uberblock, and data 
recovery involves sitting with a hex editor and something to take notes with to 
look for trees.

Original comment by druro...@gmail.com on 26 Feb 2012 at 9:31

[GoogleCodeExporter]

Actually, you might still have a good copy of the Uberblock you need, or 
something close to it. Just take the pool offline to ensure it doesn't get 
written to any more.

_TAKE_ _THE_ _POOL_ _OFFLINE_ _NOW_

Someone else here that knows about how zpool initializing works: Is the entire 
Uberblock array written to? or does it just write as needed?

Original comment by druro...@gmail.com on 26 Feb 2012 at 9:37

[GoogleCodeExporter]

> okay, I tried 'zpool import -f MeidaHD' and it works; but, now the disk is 
empty! :(
>
> In my struggles, i did re-run the procedures in getting started without the 
format
> part, in hopes that recreating the pool would bring back the data...seems 
like its 
> gone now!

Yes, the data is gone. When you did a 'zpool create' you overwrote all the 
uberblocks which pointed to the valid data. Ironically if you had done the 
format but not the pool create then you might have got the data back.

I am not aware of low-level block scanning blocks which will fix the problem at 
hand; the solution at this point is to restore from a backup/snapshot elsewhere.

The ZFS on-disk format is documented as per the download artifacts:

http://maczfs.googlecode.com/files/ZFSOnDiskFormat.pdf

The uberblock magic field is 0x00bab10c (or 0x0cb1ba00 depending on 
endianness), which I think you wrote over when you did your second zpool 
create. You might be able to write a program which would re-construct the 
uberblocks based on the pointer to the entry on disk.

The suggestion, as with any data recovery, is to take a bitwise copy of the 
disk first and then use the copy to do any data recovery from. That way you can 
always create more bit copies to work from instead of potentially corrupting it 
even further.

This isn't really an issue with MacZFS so I'm going to close this issue.

Original comment by alex.ble...@gmail.com on 7 Mar 2012 at 11:21

• Changed title: User error
• Changed state: Invalid