Corrupt zfs pool after power failure

[RobD]

I recently had a power failure occur which my UPS was continuing to supply power however as I was attempting to cleanly shutdown my UPS lost power. I’m not sure why that happened because it passed the battery test. Never the less my FreeNAS server didn’t shutdown properly. When power was restored and when I restarted the FreeNAS server I got a “Panic: solaris assert: space_map_open……” after attempting to mount local file systems. I’ve spent quite amount of time going through this forum and Google searches to help with my issue but so far I haven’t had any luck fixing my issue. One thing is for sure reading through this forum is that there’s a lot of smart folks here and if my issue is fixable someone here would know the answer. All I’m hoping for at this point is getting my FreeNAS server to a point where I can mount the volumes and grab my data. I can always rebuild the FreeNAS and plug-ins.

My environment:

• ESXi 5.5
• 1GB RAM (yes I know that’s low and shame on me. After reading through this forum I should have been 4GB or higher)
• Free NAS 9.2
• 3 VM Disks – (4GB for system, 2TB and 950GB for data) 1 physical 3TB SATA drive Provisioned Thin
• ZFS Volume (combined the 2TB and 950GB to form one volume)

Issue Experienced:
FreeNAS goes through it’s boot process and appears to fail when attempting to mount the local file systems. The result is FreeNAS boots to a db> prompt

Root Cause:
I believe after reading other issues like mine, I’m experiencing a corrupt zpool

Trouble Shooting Measure:

1. Booting up with FreeNAS bootable ISO and going into the command line. From there I tried the following command
   • zpool status – Resulted in the message No Pools Found
   • zpool import – Resulted in the server performing a “boot” and going back into db> prompt
   • gpart – I was able to see all the drives
2. Removed (temporarily) the 4GB VM disk hosting the FreeNAS system partition and created a new 4GB drive
3. Ran through the FreeNAS 9.2 install process and installed on the new 4GB drive
4. Went into the Web GUI and attempted to perform an Auto Import which failed and caused FreeNAS to reboot

At this point I’m at a loss and I’m turning to the FreeNAS community for help on this one. Typically I’m able to work through issues and resolve them on my own when doing the research but this one has got me stumped. I'm not sure it this is a lost cause but I believe this forum is my best last chance before I concede the loss of my data and format the drive. Any help with resolving this issue is greatly appreciated.

 

[Ericloewe]

You're quite wrong, you should have at the very least 8GB of RAM.

The whole setup is a nightmare. ZFS only works correctly if it has access to the physical disks, which means you have to pass-through the controller. Allocating two virtual disks and then combining them in one ZFS pool? That's just crazy.

It's a miracle the thing survived long enough to go under because of power loss.

 

[RobD]

Hello Ericloewe and thank you for your reply. I understand that now after reading through many posts about ZFS that I completely had the wrong configuration and would now do things differently. With that being said, is there any hope? Anything else I can try? I just need to get the volumes to a state that I can retrieve the data off. Thanks.

 

[cyberjock]

This forum does not support anything related to FreeNAS in a VM, at all. More than likely your problem was that you:

1. Virtualized freenas, which we know is a recipe for disaster.
2. Didn't have the minimum 8GB of RAM.

This is all very well documented in the forums and the manual and you are welcome to search both for your answers.

In short however, you can consider your data lost for good. :(

 

[RobD]

Cyberjack, thank you for your response. I was thinking this was most likely the case that my data is trashed but thought I would give it a try and ask the community knowing that I would probably get a few lashings along the way. Just recently I read your noob guide which I found very informative. Good job with that. I'll defiantly refer to that on my next go at it.