11

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.

9 Answers 9

10

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
0
3

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

3

Whilst this solution is probably unrelated to the OP's issue, I also had this same cryptic error message when trying to delete a zvol.

In my case, the zvol had been created by an interrupted zfs receive, which was sent using the "-s" resumable feature. The resume token was preventing it from being destroyed.

To fix it, I ran zfs receive -A <pool/zvol> (on FreeBSD 10.3)

1
  • Useful to know; it's certainly possible this was the case.
    – Morven
    Jan 11, 2017 at 20:01
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?

1
  • No clones based on it; that's what I suspected at first, but that's not it.
    – Morven
    Sep 17, 2009 at 21:31
1

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.

1

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

1

I ran into this long ago and wrote here: http://www.bitshop.com/Blogs/tabid/95/EntryId/101/ZFS-Destroy-dataset-does-not-exist-zdb-error-16.aspx

However this time isn't a % related issue. I'm on Illumus / Illumian 1.0, which is zpool version 26.

This is a very old server/snapshot I'm trying to delete.

1

Try looking at the dataset with zdb.

zdb -e -d tank

I was trying to do

zfs destroy -r tank/dataset

which shows up on zfs list and was getting this error.

What I found was that zdb saw

tank/dataset/dataset

which was not showing up on zfs list. I was able to easily

zfs destroy -r tank/dataset/dataset

and then

zfs destroy -r tank/dataset

with no errors.

This seems like maybe a bug in zfs list. FreeBSD 11.2-STABLE.

1

12 years later on Solaris 11.4, none of the suggestions above worked.

What ended up working was doing a zfs rollback -r yourPool/yourDataset.

I was then able to send the latest incremental snapshots.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .