Problem with thin provisioned volume mount

[jax157]

I have FreeNAS-9.2.1.3 installed as VM in VMware ESX environment. I have a problem with one of the volumes that is vmdk disk. The problem is that it was thin provisioned disk and after some period of time, probably after reboot freenas is unable to mount it.

There is an error in the gui/storage related with that volume:
error getting available space
error getting total space

I'm sure that this is a problem with thin provisioning because other volumes (all thick) are fine.
I converted that disk to thick but it did not help.

Need a help with:
- how to mount it manualy?
- or how to mount it manualy to the different OS (ubuntu, knopix etc.)?

 

[zambanini]

use your backup, vmware might have killed the virtual disk. read the forum faq.

 

[depasseg]

Step 1: consult the vmware forums to figure out why a vmdk got borked. If not successful, proceed to step 2.
Step 2: Since this looks like it was a single disk pool, and therefore there is no disk protection, the only option if you've gotten this far is to restore from backups.

 

[Mlovelace]

You're using vmdks as storage disks for freeNAS?!?

You've got some, and by some I mean a lot, of reading to do. Luckly you'll have time while the backup of the failed virtual disk is restoring.

 

[jax157]

It turns out that repairing that pool was quite easy.
ZFS has functionality for repairing corrupted files or whole pool.
In my case there was a problem with the metadata.
During those steps I was worned that i lose only last 7 secconds of the data.
After succesfully import, the scrup process check the pool for any errors.
There was no single error.

Posting few simple commands how to do that:

Code:

zpool import (list pools for import and show potential problems with the pools)

zpool import pool_name (import pool)

zpool import -F pool_name (import pool with recovery option)

zpool status (status of the mounted pools)

 

[Ericloewe]

It turns out that repairing that pool was quite easy.
ZFS has functionality for repairing corrupted files or whole pool.
In my case there was a problem with the metadata.
During those steps I was worned that i lose only last 7 secconds of the data.
After succesfully import, the scrup process check the pool for any errors.
There was no single error.

Posting few simple commands how to do that:

Code:

zpool import (list pools for import and show potential problems with the pools)

zpool import pool_name (import pool)

zpool import -F pool_name (import pool with recovery option)

zpool status (status of the mounted pools)

Repairing damage is very different from throwing out the last few transactions.