On nexenta.org, it works now after the upgrade to the latest unstable: r...@nexenta:~# zfs destroy tank/ncp2/hardy-unsta...@previous r...@nexenta:~#
Probably gnusolaris.org needs to be upgraded too. I also suspecting that pool's version is somehow related: r...@nexenta:~# zpool get version tank NAME PROPERTY VALUE SOURCE tank version 3 local r...@nexenta:~# zpool upgrade -v This system is currently running ZFS pool version 14. But at any rate, the issue seems fixed in latest putbacks... On Fri, 2009-01-23 at 09:01 -0500, Tim Spriggs wrote: > Hi All, > > Initially reported by Corwin on #nexenta... I see this on nexenta.org as > well (NCP2) > > cannot destroy 'tank/ncp2/hardy-unsta...@previous': dataset does not exist > no snapshots destroyed > cannot rename 'tank/ncp2/hardy-unsta...@latest': dataset does not exist > cannot create snapshot 'tank/ncp2/hardy-unsta...@latest': dataset does > not exist > > however: > > # zfs list -tall -r tank/ncp2/hardy-unstable > NAME USED AVAIL REFER MOUNTPOINT > tank/ncp2/hardy-unstable 34.1G 180G 32.8G > /tank/ncp2/dists/hardy-unstable > tank/ncp2/hardy-unsta...@hardy-testing 1.21G - 27.7G - > tank/ncp2/hardy-unsta...@previous 78.0M - 32.8G - > tank/ncp2/hardy-unsta...@latest 42.9M - 32.8G - > > seems there is something bad about the current zfs bits/ON base. If > anyone else has seen this (upstream or not) I'd be interested to know. > This is also affecting Corwin's ability to use apt-clone under NCP2. > > Thanks, > -Tim > _______________________________________________ > gnusol-devel mailing list > gnusol-devel@lists.sonic.net > http://lists.sonic.net/mailman/listinfo/gnusol-devel > _______________________________________________ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel