Немає місця на пристрої під час видалення файлу під OpenSolaris

Під час спроби встановити папку NFS (експортовану з сервера OpenIndiana ) на клієнтському вікні, сервер OI зазнав аварії. У мене з’явився чорний екран смерті, який виглядав як дамп журналу, потім система перезавантажилася. Він ніколи не повертався, і після зупинки завантаження я отримую таку помилку msg:

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 -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 Discuss, де ця проблема була обговорена глибоко.

4.Z3G (стовпець, що використовується USP), сумнівний.

У будь-якому випадку, занадто велика (3,85 ГБ) rpool / export / home / admin, ймовірно, є першопричиною. Подивіться на його вміст і видаліть непотрібні файли там. Оскільки файлова система адміністратора не має знімків, це повинно негайно звільнити місце в пулі.

Я мав це і витратив деякий час, намагаючись зрозуміти, що потрібно. Моє рішення полягало в нульовому просторі файлів, перш ніж спробувати їх видалити.

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

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