Nie można zniszczyć migawki ZFS: zestaw danych już istnieje

Mam serwer (T5220, choć wątpię, żeby to miało znaczenie) z systemem Solaris 10 8/07 i mam pulę ZFS „mysql” na dysku wewnętrznym. Mam w nim system plików „mysql / data / 4.1.12”, który co godzinę robię migawką za pomocą skryptu z crona.

Mam jedną migawkę, utworzoną jako jedna z tych godzinnych migawek, która nie zniszczy. Zmieniłem nazwę poza sekwencją na „mysql/data/4.1.12@wibble”, aby mój skrypt nie próbował go zniszczyć, ale pierwotnie znajdował się w sekwencji, choć wątpię, żeby to miało znaczenie. Zmienia nazwę z powodzeniem. Z migawką można z powodzeniem nawigować i czytać w katalogu .zfs / snapshots. Na tej podstawie nie ma klonów.

Próbując go zniszczyć, robi to:

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

co jest pozornie bezsensowne: oczywiście już istnieje, o to chodzi!

Czy ktoś widział coś takiego wcześniej? Wyszukiwania w sieci nie pokazują niczego oczywiście podobnego.

W razie potrzeby mogę dostarczyć zainstalowane łatki.

Odpowiedź na ten problem została już udzielona dzięki uprzejmości Cindy Swearingen (cindys) tutaj: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0

Podsumowanie: jeśli wykonujesz operacje przyrostowe, może to być CR 6860996:

Tymczasowy klon jest tworzony dla przyrostowego odbioru, aw niektórych przypadkach nie jest usuwany automatycznie.

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

Po aktualizacji do nowszych zestawów poprawek mogłem pomyślnie usunąć tę migawkę. Najwyraźniej był gdzieś błąd, który zmiażdżyło Słońce.

Nie sądzę, że to jest problem (myślę, że pojawia się inny komunikat o błędzie), ale czy masz jakieś klony oparte na tej migawce?

Chociaż to rozwiązanie prawdopodobnie nie ma związku z problemem PO, miałem również ten sam tajemniczy komunikat o błędzie podczas próby usunięcia pliku Zvol.

W moim przypadku zvol został utworzony przez przerwany odbiór zfs, który został wysłany przy użyciu funkcji wznawiania „-s”. Żeton wznowienia zapobiegał jego zniszczeniu.

Aby to naprawić, uruchomiłem zfs receive -A <pool/zvol> (na FreeBSD 10.3)

Widziałem także ten problem (listopad 2009 r.). Znów tylko JEDNA migawka nie może zostać zniszczona i otrzymuję ten sam bezsensowny komunikat

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

Ta migawka nie jest początkiem ani klonowaniem systemu plików. W rzeczywistości mam jeden sklonowany system plików - ale wyszukiwanie rekurencyjne pokazuje, że nie jest on oparty na kłopotliwej migawce

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

Dopóki nie zmienię jego nazwy, ta migawka zepsuje również skrypty, które uruchamiam, aby kontrolować rozprzestrzenianie się migawek.

Informacje o wersji: To jest Solaris na x86 (5.10 Generic_141445-09 i86pc) W tym systemie działa obecnie pula ZFS w wersji 15. Wszystkie pule są formatowane przy użyciu tej wersji.

Ten sam problem bez klonowania.

Problemy występują, gdy wersja ZFS miała 10. Staramy się uaktualnić do 15 bez żadnych zmian

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

Natknąłem się na to dawno temu i napisałem tutaj: http://www.bitshop.com/Blogs/tabid/95/EntryId/101/ZFS-Destroy-dataset-does-not-exist-zdb-error-16.aspx

Jednak ten czas nie jest związany z% problemem. Używam Illumus / Illumian 1.0, czyli wersji 26 zpool.

To jest bardzo stary serwer / migawka, którą próbuję usunąć.

Spróbuj spojrzeć na zestaw danych za pomocą zdb.

zdb -e -d tank

Próbowałem to zrobić

zfs destroy -r tank/dataset

który pojawia się zfs listi pojawia się ten błąd.

Znalazłem to, że widziałem zdb

tank/dataset/dataset

który się nie pojawiał zfs list. Byłem w stanie łatwo

zfs destroy -r tank/dataset/dataset

i wtedy

zfs destroy -r tank/dataset

bez błędów.

To może być błąd zfs list. FreeBSD 11.2-STABILNY.