Impossible de détruire l'instantané ZFS: l'ensemble de données existe déjà

J'ai un serveur (T5220, bien que je doute que cela soit important) exécutant Solaris 10 8/07 et j'ai un pool ZFS, "mysql", sur le disque interne. À l'intérieur, j'ai un système de fichiers "mysql / data / 4.1.12", que j'instantané toutes les heures avec un script de cron.

J'ai un instantané, créé comme l'un de ces instantanés horaires, qui ne détruit pas. Je l'ai renommé hors séquence pour être "mysql/data/4.1.12@wibble" afin que mon script n'essaye pas de ne pas le détruire, mais il était à l'origine dans la séquence, bien que je doute que cela compte. Il renomme avec succès. La capture instantanée peut être parcourue et lue avec succès via le répertoire .zfs / snapshots. Il n'a aucun clone basé sur lui.

Essayer de le détruire fait ceci:

(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:/# 

ce qui est apparemment absurde: bien sûr qu'il existe déjà, c'est le point!

Quelqu'un a-t-il déjà vu quelque chose comme ça avant? Les recherches sur le Web ne montrent rien de semblable.

Je peux fournir des correctifs installés si nécessaire.

Ce problème a maintenant été résolu, gracieuseté de Cindy Swearingen (cindys) ici: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0

Résumé: si vous effectuez des réceptions incrémentielles, il peut s'agir de CR 6860996:

Un clone temporaire est créé pour une réception incrémentielle et dans certains cas, il n'est pas supprimé automatiquement.

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

Après avoir mis à niveau vers des ensembles de correctifs plus récents, j'ai pu supprimer cet instantané avec succès. C'était clairement un bug quelque part que Sun a écrasé.

Je ne m'attends pas à ce que ce soit le problème (je pense que vous obtenez un message d'erreur différent), mais avez-vous des clones basés sur cet instantané?

Bien que cette solution ne soit probablement pas liée au problème de l'OP, j'ai également eu ce même message d'erreur cryptique lors de la tentative de suppression d'un zvol.

Dans mon cas, le zvol a été créé par une réception zfs interrompue, qui a été envoyée à l'aide de la fonction de reprise "-s". Le jeton de reprise l'empêchait d'être détruit.

Pour le réparer, j'ai couru zfs receive -A <pool/zvol> (sur FreeBSD 10.3)

J'ai également vu ce problème (nov 2009). Encore une fois, un seul instantané ne peut pas être détruit et je reçois le même message absurde

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

Et cet instantané n'est pas à l'origine du clone du système de fichiers. En fait, j'ai un système de fichiers cloné - mais une recherche récursive montre qu'il n'est pas basé sur l'instantané gênant

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

Jusqu'à ce que je le renomme, cet instantané va également bousiller les scripts que je lance pour contrôler la prolifération des instantanés.

Informations sur la version: il s'agit de Solaris sur x86 (5.10 Generic_141445-09 i86pc) Ce système exécute actuellement la version 15 du pool ZFS. Tous les pools sont formatés à l'aide de cette version.

Même problème sans aucun clone.

Le problème se produit alors que la version zfs était 10. Nous essayons de passer à 15 sans aucun changement

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

J'ai rencontré cela il y a longtemps et j'ai écrit ici: http://www.bitshop.com/Blogs/tabid/95/EntryId/101/ZFS-Destroy-dataset-does-not-exist-zdb-error-16.aspx

Cependant, cette fois n'est pas un problème lié à%. Je suis sur Illumus / Illumian 1.0, qui est la version 26 de zpool.

Il s'agit d'un très ancien serveur / instantané que j'essaie de supprimer.

Essayez de regarder l'ensemble de données avec zdb.

zdb -e -d tank

J'essayais de faire

zfs destroy -r tank/dataset

qui apparaît zfs listet obtenait cette erreur.

Ce que j'ai trouvé, c'est que zdb a vu

tank/dataset/dataset

qui ne se présentait pas zfs list. J'ai pu facilement

zfs destroy -r tank/dataset/dataset

puis

zfs destroy -r tank/dataset

sans erreurs.

Cela ressemble peut-être à un bug zfs list. FreeBSD 11.2-STABLE.