Нет места на устройстве при удалении файла под OpenSolaris

При попытке смонтировать общий ресурс NFS (экспортированный с сервера OpenIndiana ) на клиентском компьютере произошел сбой сервера OI. Я получил черный экран смерти, похожий на дамп журнала, и система перезапустилась. Это никогда не возвращалось, и я получаю следующее сообщение об ошибке после остановки загрузки:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

У меня на загрузочном диске нет ничего, кроме ОС, так что ... Я не уверен, что может заполнить диск? Может быть, какой-нибудь лог-файл? Я не могу ничего удалить независимо. Это дает мне ошибку без пробела, когда я пытаюсь удалить что-либо:

$ rm filename
cannot remove 'filename' : No space left on device 

Я могу войти в «Режим обслуживания», но не в обычном приглашении пользователя.

Вывод df:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

Вывод mount:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

Вывод 'zfs list -t all':

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Хорошо, это странно ... недостаточно места для удаления файла!

Оказывается, это довольно распространенная проблема с ZFS, хотя она может возникнуть в любой файловой системе, имеющей моментальные снимки .

Это объясняется тем, что файл, который вы пытаетесь удалить, все еще существует на снимке. Поэтому, когда вы удаляете его, содержимое остается существующим (только в снимке); и система должна дополнительно записать информацию о том, что снимок имеет файл, а текущее состояние - нет. Там нет места для этой дополнительной информации.

Краткосрочное исправление - найти файл, созданный после последнего снимка, и удалить его. Другая возможность - найти файл, к которому добавлен после последнего снимка, и обрезать его до размера, который был на момент последнего снимка. Если ваш диск переполнен из-за спама в ваших журналах, попробуйте обрезать самые большие файлы журналов.

Более распространенным решением является удаление некоторых снимков. Вы можете перечислить снимки с zfs list -t snapshot. Похоже, не существует простого способа предсказать, сколько места будет восстановлено, если вы уничтожите конкретный снимок, потому что данные, которые он хранит, могут оказаться необходимыми для других снимков и будут жить, если вы уничтожите этот снимок. Поэтому при необходимости создайте резервную копию данных на другом диске, определите один или несколько снимков, которые вам больше не нужны, и запустите zfs destroy name/of/snap@shot.

В этой ветке форумов OpenSolaris обсуждается эта проблема .

Это хорошо известная проблема с файловыми системами копирования при записи: чтобы удалить файл, файловая система должна сначала выделить блок и исправить новый статус, прежде чем она сможет освободить пространство, содержащееся в файле, который только что удаляется.

(Это не проблема файловых систем со снимками, так как есть и другие способы их реализации, кроме простого копирования при записи)

Способы выжимания:

• выпустить снимок (если он есть ...)
• увеличить пул (в случае, если есть запасные, вы можете назначить его)
• уничтожить другую файловую систему в пуле, затем вырастить жесткую файловую систему
• обрежьте файл, затем удалите его (хотя, как только я оказался в слишком тесном положении, чтобы сделать это, см. обсуждение в ZFS. Обсудить )
• отсоедините файл. (так же, как и выше)

Я столкнулся с той же ловушкой несколько лет назад, и у меня не было снимков, которые я мог бы выпустить, чтобы освободить меня. Смотрите ветку в ZFS. Обсудите, где эта проблема обсуждалась подробно.

4.Z3G (колонка rpool / USED) сомнительна.

В любом случае корень является причиной того, что rpool / export / home / admin слишком велик (3,85 ГБ). Посмотрите его содержимое и удалите ненужные файлы. Поскольку в файловой системе администратора нет снимков, это должно немедленно освободить место в пуле.

Я имел это и провел некоторое время, пытаясь выяснить, что было нужно. Мое решение состояло в том, чтобы обнулить пространство файлов, прежде чем пытаться их удалить.

У нас есть некоторые неправильные процессы, которые иногда сходят с ума и заполняют диск основными файлами (заканчивающимися числом), поэтому я создал сценарий, который содержит что-то вроде этого, чтобы сохранить одну копию.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

Когда я запустил свой скрипт, он выдал одну ошибку:

mv: cannot rename core.200000 to core: No space left on device

и была функциональная очистка файлов.

Чтобы проверить это, я заполнил диск:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done