Formerly, if you interrupted a zfs receive, it would leave a clone with a % in 
its name, and you could find it via "zdb -d" and then you could destroy the 
clone, and then you could destroy the filesystem you had interrupted receiving.

That was considered a bug, and it was fixed, I think by Sun.  If the lingering 
clone was discovered laying around, zfs would automatically destroy it.  But 
now I'm encountering a new version of the same problem...

Unfortunately, now I have a filesystem where "zfs receive" was interrupted, and 
I can't destroy the filesystem or the snapshot of the filesystem on the 
receiving side.

sudo zfs destroy -R tank/Downloads
cannot destroy 'tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54': dataset 
already exists

sudo zfs destroy -R tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54
cannot destroy snapshot tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54: 
snapshot is cloned

sudo zfs list -t all | grep Downloads

sudo zdb -d tank/Downloads
Dataset tank/Downloads [ZPL], ID 139, cr_txg 31408, 3.91G, 30 objects
(Notice, I don't get any clones listed.)

I'm running openindiana 151.1.6 (the latest, fully patched a couple of weeks 

zfs-discuss mailing list
  • [zfs-discuss] Fai... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)

Reply via email to