Is there any way to recover the data within a zpool after a spool create -f was issued on the disks? We had a pool that contained two internal disks (mirrored) and we added a zvol to it our of an existing pool for some temporary space. After the reboot, the pool was not able to be imported because it could not find the zvol disk. Trying to import the pool and specifying a -d /dev/zvol/dsk/rpool actually found the zvol which contained the missing disk, but failed import with missing disks (the two internal). We then tried to recreate the pool, which was successful - but without data? Thanks ed
On 08/20/2012 08:55 PM, Ernest Dipko wrote:> Is there any way to recover the data within a zpool after a spool create -f was issued on the disks? > > We had a pool that contained two internal disks (mirrored) and we added a zvol to it our of an existing pool for some temporary space. After the reboot, the pool was not able to be imported because it could not find the zvol disk. Trying to import the pool and specifying a -d /dev/zvol/dsk/rpool actually found the zvol which contained the missing disk, but failed import with missing disks (the two internal).That''s because adding -d to import overrides the default search paths. You should have specified -d multiple times to point the machine to the two physical disks. The manpage explicitly states this.> We then tried to recreate the pool, which was successful - but without data?A zpool create overwrites all labels on a device (that''s why you had to add "-f", which essentially means "blame me if all goes wrong"). Since the vdev labels contain the root block pointer (which points to the root block of the entire pool object tree) and the value in this block pointer moves around as new data is added (due to COW semantics), your data is now toast. Sorry about that. -- Saso
On 08/20/2012 02:55 PM, Ernest Dipko wrote:> Is there any way to recover the data within a zpool after a spool create -f was issued on the disks? > > We had a pool that contained two internal disks (mirrored) and we added a zvol to it our of an existing pool for some temporary space. After the reboot, the pool was not able to be imported because it could not find the zvol disk. Trying to import the pool and specifying a -d /dev/zvol/dsk/rpool actually found the zvol which contained the missing disk, but failed import with missing disks (the two internal). > > We then tried to recreate the pool, which was successful - but without data? >Do this: Create a directory somewhere and make links (soft will work) to the devices that are in the pool, then pass the path to that dir to -d. -d expects a directory containing the devices, not the actual devices. Just learned this a week ago myself. :)
2012-08-20 23:39, Sa?o Kiselkov ?????:>> We then tried to recreate the pool, which was successful - but without data? > > A zpool create overwrites all labels on a device (that''s why you had to > add "-f", which essentially means "blame me if all goes wrong"). Since > the vdev labels contain the root block pointer (which points to the root > block of the entire pool object tree) and the value in this block > pointer moves around as new data is added (due to COW semantics), your > data is now toast. Sorry about that.As was recently discussed on the list, it is difficult to recreate the label for the disks. Not impossible, however, but quite an experiment - and an undocumented one AFAIK. You might be in a bit of luck, because your zvol-based component of the pool might have some important data (last known TXG number and address of the current three copies of the root block for ZFS data tree). Assuming that you did not write much to the pool disks after that forced creation of the new pool, recreation of labels for those disks (or one of them since they were mirrored) should theoretically be possible and help. Perhaps some bytes were overwritten and lost forever in the data area of the pool during creation of the new pool''s root dataset and other structures, but most data should be intact. Good luck, //Jim
On 08/20/2012 10:15 PM, Jim Klimov wrote:> 2012-08-20 23:39, Sa?o Kiselkov ?????: >>> We then tried to recreate the pool, which was successful - but >>> without data? >> >> A zpool create overwrites all labels on a device (that''s why you had to >> add "-f", which essentially means "blame me if all goes wrong"). Since >> the vdev labels contain the root block pointer (which points to the root >> block of the entire pool object tree) and the value in this block >> pointer moves around as new data is added (due to COW semantics), your >> data is now toast. Sorry about that. > > As was recently discussed on the list, it is difficult to recreate > the label for the disks. Not impossible, however, but quite an > experiment - and an undocumented one AFAIK.He described that he re-created zpool, so I take it he re-created it with all component vdevs (both the mirrored disks and the zvol), so there are no more labels left to coy.> You might be in a bit of luck, because your zvol-based component > of the pool might have some important data (last known TXG number > and address of the current three copies of the root block for ZFS > data tree). > > Assuming that you did not write much to the pool disks after that > forced creation of the new pool, recreation of labels for those > disks (or one of them since they were mirrored) should theoretically > be possible and help. Perhaps some bytes were overwritten and lost > forever in the data area of the pool during creation of the new > pool''s root dataset and other structures, but most data should be > intact.If he re-created it with only the mirrored disks, then maybe. If he re-created it with all vdevs, then the data really is gone. -- Saso