Cannot destroy ZFS snapshot: dataset already exists

Question

I have a server (T5220, though I doubt it matters) running Solaris 10 8/07 and I have a ZFS pool, "mysql", on internal disk. Within it I have a filesystem "mysql/data/4.1.12", which I snapshot hourly with a script from cron.

I have one snapshot, created as one of those hourly snaps, that will not destroy. I have renamed it out of sequence to be "mysql/data/4.1.12@wibble" so that my script will not try and fail to destroy it, but it was originally within the sequence, though I doubt that matters. It renames successfully. The snapshot can be successfully navigated and read from through the .zfs/snapshots directory. It has no clones based on it.

Trying to destroy it does this:

(265) root@web-mysql4:/# zfs destroy mysql/data/4.1.12@wibble
cannot destroy 'mysql/data/4.1.12@wibble': dataset already exists
(266) root@web-mysql4:/#

which is apparently nonsensical: of course it already exists, that's the point!

Anyone seen anything like this before? Web searches show nothing obviously similar.

I can provide patches installed if necessary.

Answer 1

This issue has now been answered, courtesy of Cindy Swearingen (cindys) here: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0

Summary: If you do incremental receives, this might be CR 6860996:

A temporary clone is created for an incremental receive and in some cases, is not removed automatically.

1. Determine clone names:

# zdb -d <poolname> | grep %

2. Destroy identified clones:

# zfs destroy <clone-with-%-in-the-name>

It will complain that 'dataset does not exist', but you can check
again(see 1)

3. Destroy snapshot(s) that could not be destroyed previously

Answer 2

I don't expect this is the issue (I think you get a different error message), but do you have any clones based on that snapshot?

Answer 3

After having upgraded to more recent patch sets, I could delete this snapshot successfully. Clearly was a bug somewhere that Sun squashed.

Answer 4

I have also seen this problem (nov 2009). Again just ONE snapshot can not be destroyed and I get the same nonsensical message

# zfs destroy blue/viss02_backup/46home1f@200910211357
cannot destroy 'blue/viss02_backup/46home1f@200910211357': dataset already exists

And this snapshot is not the origin for and filesystem clone. In fact I have one cloned filesystem - but a recursive search shows that it is not based on the troublesome snapshot

# zfs get -H -o value -r origin blue | uniq
-
blue/viss02_backup/zones/puppis@200902031605
-

Until I rename it this snapshot will also screw up the scripts which I run to control the proliferation of snapshots.

Version information: This is Solaris on x86 (5.10 Generic_141445-09 i86pc) This system is currently running ZFS pool version 15. All pools are formatted using this version.

Answer 5

Same problem without any clone.

The problems occurs while the zfs version was 10. We try to upgrade to 15 without any changes

 zfs destroy -rR zpool/mailboxes
 cannot destroy 'zpool/mailboxes@bug': dataset already exists