Предисловие. Нет на свете ничего абсолютно чёрного (белого, полезного, плохого, вредного...) Так и COW принцип записи данных в ZFS (сначала пишем новое на свободное место, потом перемещаем указатель на новый адрес, потом освобождаем место под старые данные) всем хорош. И надёжность и снимки файловой системы мгновенные,
Понятно, на заполненный на 100% ZFS пул ничего нельзя записать. Но с него ничего нельзя и стереть! Ведь стирание в COW концепции - это сначала запись нового блока!.. Печалька.
Так что сильно советую больше чем на 90-95% домашние пулы не забивать, а 100% так избегать совсем. А сегодня мы подробно разберём такую проблему, возникшую у камрада
doctor56. Как она упиралась, как была решена, почему возникла и каков алгоритм действий в подобной ситуации.Дано. ZFS пул забит на 100%.
nas4free: ~ # zfs list
NAME USED AVAIL REFER MOUNTPOINT
Data 7.13T 0 268K /mnt/Data
Data/Backup 411G 0 411G /mnt/Data/Backup
Data/Files 6.72T 0 5.50T /mnt/Data/Files
Data/Sys 9.11G 0 8.92G /mnt/Data/Sys
Пытаемся удалить файл
nas4free: ~ # rm /mnt/Data/Files/Movies/Film.mkv
rm: /mnt/Data/Files/Movies/Film.mkv: No space left on device
Лечение. Идём в наш FAQ и видим - надо изменить размер файла на нулевой, тогда место освободится.
nas4free: ~ # dd if=/dev/null of=/mnt/Data/Files/Movies/Film.mkv
dd: /mnt/Data/Files/Movies/Film.mkv: No space left on device
Не получается...
Гуглим дальше. Люди пишут, что трюк пороходит только с маленькими файлами. Чтобы обнулить длину большого что-то пишется, а писать - некуда. Находим маленький файл
nas4free: ~ # dd if=/dev/null of=/mnt/Data/Files/a772f243f719588c
0+0 records in
0+0 records out
0 bytes transferred in 0.000018 secs (0 bytes/sec)
Ура, сдвинулась!
nas4free: ~ # rm /mnt/Data/Files/a772f243f719588c
rm: /mnt/Data/Files/a772f243f719588c: No space left on device
Ан нет, печалька...
0+0 records out
0 bytes transferred in 0.000018 secs (0 bytes/sec)
Ура, сдвинулась!
nas4free: ~ # rm /mnt/Data/Files/a772f243f719588c
rm: /mnt/Data/Files/a772f243f719588c: No space left on device
Ан нет, печалька...
Смотрим, нет ли снапшотов (снимков файловой системы)
nas4free: ~ # zfs list -t snapshot
Data/Files@auto-20131124-090000 914K - 5.96T -
Data/Files@auto-20131125-090000 1.68G - 5.96T
...
Вот и отгадка. Когда мы обнуляли файлу длину, его копия сохранялась в снапшоте. Поэтому место не освобождалось
Начинаем удалять снапшоты, первыми - самые древние
nas4free: ~ # zfs destroy Data/Files@auto-20131125-090000
пока у нас не появится свободное место (проверять можно командой zfs list). Удалять в Nas4free можно и из вебгуя.
Теперь, когда место есть - всё прекрасно удаляется.
Причина. Конечно, на пул писалась информация - но старые файлы же удалялись! И тут снова надо вспомнить про снапшоты. У камрада (как и у меня) их изготовление (и удаление через месяц) было автоматизировано. Об этом нетрудно позабыть. В результате все удалённые файлы продолжали храниться в старых снимках и место не освобождали.
Что делать.
- Следить за свободным местом. Тем более, что заполенность пулов показана на главной странице.
- Если свободного места становится меньше 10% пула - принимать меры. Удалять старые снимки, возможно - все. Удалять файлы.
Если попали в ситуацию с полным на 100% пулом.
- Не паниковать.
- Заниматься проблемой на свежую голову (не в 3 ночи и не под модификаторами сознания)
- Проверить наличие снапшотов на проблемном пуле zfs list -t snapshot
- если есть - стирать, начиная с древних, из вебгуя или zfs destroy Data/Files@auto-20131125-090000
- если нет (или всё стёрто, но место не освободилось) - найти небольшой (но не нулевой длины) файл и обнулить его длину
dd if=/dev/null of=/mnt/Data/Files/a772f243f719588c
0+0 records in
0+0 records out
0 bytes transferred in 0.000018 secs (0 bytes/sec)
- а потом удалить
rm /mnt/Data/Files/a772f243f719588c