Home / server / Questions / 66414
Accepted
Morven
Asked: 2009-09-18 12:23:11 +0800 CST

Cannot destroy ZFS snapshot: dataset already exists

  • 772

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.

solaris

9 Answers

  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
    • 10
  2. Best Answer

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

    • 3

  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)

    • 3

  4. 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?

    • 2

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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.

    • 1