Destroying a Volume does not conform to the definition of destroy.

[matthewowen01]

From thread:
http://forums.freenas.org/showthrea...-....-need-a-help.&p=1579&viewfull=1#post1579


When you use the Gui to destroy a volume, it is impossible to retrieve the volume using 'zpool import -D' if you use 'zpool destroy' from the cli, the correct behavior is observed. i was able to replicate this in a virtual machine.

it looks like one of our users lost a pool due to this bug. by reading /var/log/messages, i can see that dd is being used to nuke the first section of the disks, this is not how destroy should operate. it should use the 'zpool destroy' command. if dd is the true intention of the 'destroy' button, a new name is needed as destroy is already in the zfs grammar and this causes very dangerous results.

 

[Leroy van Logchem]

"Four copies of the physical vdev label are written to each physical vdev within a ZFS storage pool. Aside from the small time frame during label update, these four labels are identical and any copy can be used to access and verify the contents of the pool. When a device is added to the pool, ZFS places two labels at the front of the device and two labels at the back of the device."

If these labels are untouched you can inspect the grouped/related vdevs using zfs import. Then chose the correct <id> as option to the import. So far this seems useful but when you want to create another zfs volume configuration using the same disks you just used, zfs will complain that the vdev's still belong to the former zpool. The two dd actions for each disk are required so you can reuse/reassign the clean and label free disks. Maybe the dd actions should be moved to the part where one creates new zpool's and must confirm a 'red' dialog indicating imminent the loss of former pools. Doing so the window for recovery of 'zpool destroy' is open until the user confirms the label destroy operation.

 

[matthewowen01]

as i understand it, the first 2 and the last 2 256K blocks on the block device are copies of the data. I'm to tired to want to mess with this now, but for anyone who wants it, here is the ZFS specifications, Page 7 documents the label redundancy.


http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf