У меня есть сервер (T5220, хотя я сомневаюсь, что это имеет значение), работающий под Solaris 10 8/07, и у меня есть пул ZFS, mysql, на внутреннем диске. В нем есть файловая система mysql / data / 4.1.12, которую я ежечасно снимаю с помощью скрипта из cron.
У меня есть один снимок, созданный как один из тех ежечасных снимков, который не разрушится. Я переименовал его вне последовательности в «mysql/data/4.1.12@wibble», чтобы мой сценарий не пытался и не смог его уничтожить, но изначально он находился внутри последовательности, хотя я сомневаюсь, что это имеет значение. Он успешно переименовывает. Моментальный снимок можно успешно перемещать и читать из каталога .zfs / snapshots. Клонов на его основе нет.
При попытке его уничтожить происходит следующее:
(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:/#
что, по-видимому, бессмысленно: конечно, оно уже существует, в том-то и дело!
Кто-нибудь видел что-нибудь подобное раньше? Поиск в Интернете ничего явно похожего не показывает.
При необходимости могу предоставить установленные патчи.
На этот вопрос был дан ответ, любезно предоставленный Синди Свиринген (cindys) здесь: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0
Сводка: если вы выполняете инкрементальные приемы, это может быть CR 6860996:
Временный клон создается для инкрементального приема и в некоторых случаях не удаляется автоматически.
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
После обновления до более свежих наборов патчей я смог успешно удалить этот снимок. Очевидно, где-то была ошибка, которую раздавила Сан.
Хотя это решение, вероятно, не связано с проблемой OP, у меня также было такое же загадочное сообщение об ошибке при попытке удалить zvol.
В моем случае zvol был создан прерванным приемом zfs, который был отправлен с помощью функции возобновления "-s". Токен резюме предотвращал его уничтожение.
Чтобы исправить это, я побежал zfs receive -A <pool/zvol> (в FreeBSD 10.3)
Я не думаю, что это проблема (я думаю, вы получите другое сообщение об ошибке), но есть ли у вас клоны на основе этого снимка?
Я тоже видел эту проблему (ноябрь 2009 г.). Опять же, только ОДИН снимок не может быть уничтожен, и я получаю то же бессмысленное сообщение
# zfs destroy blue/viss02_backup/46home1f@200910211357
cannot destroy 'blue/viss02_backup/46home1f@200910211357': dataset already exists
И этот снимок не является источником и клоном файловой системы. На самом деле у меня есть одна клонированная файловая система, но рекурсивный поиск показывает, что она не основана на проблемном снимке
# zfs get -H -o value -r origin blue | uniq
-
blue/viss02_backup/zones/puppis@200902031605
-
Пока я не переименую его, этот снимок также испортит скрипты, которые я запускаю, чтобы контролировать распространение снимков.
Информация о версии: Это Solaris на x86 (5.10 Generic_141445-09 i86pc) В настоящее время в этой системе используется пул ZFS версии 15. Все пулы отформатированы с использованием этой версии.
Та же проблема без клона.
Проблема возникает, когда версия zfs была 10. Пробуем обновиться до 15 без каких-либо изменений.
zfs destroy -rR zpool/mailboxes
cannot destroy 'zpool/mailboxes@bug': dataset already exists
Я давно столкнулся с этим и написал здесь: http://www.bitshop.com/Blogs/tabid/95/EntryId/101/ZFS-Destroy-dataset-does-not-exist-zdb-error-16.aspx
Однако на этот раз проблема не связана с%. Я использую Illumus / Illumian 1.0, то есть zpool версии 26.
Это очень старый сервер / снимок, который я пытаюсь удалить.
Попробуйте посмотреть набор данных с помощью zdb.
zdb -e -d tank
Я пытался сделать
zfs destroy -r tank/dataset
который появляется на zfs list и получал эту ошибку.
Я обнаружил, что zdb видел
tank/dataset/dataset
который не появлялся на zfs list. Я легко мог
zfs destroy -r tank/dataset/dataset
а потом
zfs destroy -r tank/dataset
без ошибок.
Это похоже на ошибку в zfs list. FreeBSD 11.2-СТАБИЛЬНАЯ.