Brak miejsca na urządzeniu podczas usuwania pliku w OpenSolaris

Podczas próby zamontowania udziału NFS (eksportowanego z serwera OpenIndiana ) do skrzynki klienta, serwer OI się zawiesił. Dostałem czarny ekran śmierci, który wyglądał jak zrzut drewna, a potem system się zrestartował. Nigdy nie wrócił i po zatrzymaniu rozruchu pojawia się następujący komunikat o błędzie:

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

Nie mam nic innego na dysku rozruchowym poza systemem operacyjnym, więc ... Nie jestem pewien, co mogłoby zapełnić dysk? Może jakiś plik dziennika? Wydaje mi się, że nie mogę niczego usunąć. Daje mi błąd braku spacji, gdy próbuję coś usunąć:

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

Mogę zalogować się w „trybie konserwacji”, ale nie w standardowym monitie użytkownika.

Dane wyjściowe dfto:

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

Dane wyjściowe mountto:

/ 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 

Dane wyjściowe „zfs list -t all” to:

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    -

Ok, to dziwne ... za mało miejsca, aby usunąć plik!

Okazuje się, że jest to dość powszechny problem z ZFS, chociaż może potencjalnie wystąpić w każdym systemie plików, który ma migawki .

Wyjaśnienie jest takie, że plik, który próbujesz usunąć, nadal istnieje na migawce. Więc kiedy go usuniesz, zawartość pozostanie istniejąca (tylko w migawce); i system musi dodatkowo zapisać informację, że migawka ma plik, ale aktualny stan nie. Nie ma już miejsca na dodatkowe informacje.

Krótkoterminową poprawką jest znalezienie pliku utworzonego po najnowszej migawce i usunięcie go. Inną możliwością jest znalezienie pliku dołączonego po najnowszej migawce i obcięcie go do rozmiaru, jaki miał w czasie ostatniej migawki. Jeśli twój dysk się zapełnił, ponieważ coś spamuje twoje dzienniki, spróbuj przyciąć największe pliki dziennika.

Ogólniej obowiązującą poprawką jest usunięcie niektórych migawek. Możesz wyświetlić migawki za pomocą zfs list -t snapshot. Wydaje się, że nie ma łatwego sposobu przewidzenia, ile miejsca zostanie odzyskane, jeśli zniszczysz konkretną migawkę, ponieważ przechowywane w niej dane mogą okazać się potrzebne w przypadku innych migawek, a więc przetrwają, jeśli zniszczysz tę migawkę. Jeśli to konieczne, wykonaj kopię zapasową danych na innym dysku, zidentyfikuj jedną lub więcej migawek, których już nie potrzebujesz, i uruchom zfs destroy name/of/snap@shot.

W tym wątku na forach OpenSolaris znajduje się obszerna dyskusja na ten temat .

Jest to dobrze znany problem z systemami plików kopiowania przy zapisie: Aby usunąć plik, system plików musi najpierw przydzielić blok i naprawić nowy status, zanim będzie w stanie zwolnić mnóstwo miejsca w właśnie usuwanym pliku.

(To nie problem z systemami plików z migawek, ponieważ istnieją inne sposoby realizacji tych nie tylko kopiowanie przy zapisie)

Sposoby na wyciskanie:

• zwolnij migawkę (na wypadek, gdyby była jedna ...)
• powiększ pulę (na wypadek, gdyby można było do niej jakieś wolne)
• zniszcz inny system plików w puli, a następnie rozbuduj szczelny system plików
• obetnij plik, a następnie usuń go (chociaż gdy byłem już zbyt mocno ściśnięty, aby móc to zrobić, zobacz temat na ZFS Dyskusja )
• odłączyć plik. (tak samo jak powyżej)

Kilka lat temu wpadłem na tę samą pułapkę i nie miałem żadnych migawek, które mógłbym wydać, aby mnie uwolnić. Zobacz temat w ZFS Omów, gdzie ten problem został szczegółowo omówiony.

4.Z3G (kolumna UŻYWANA rpool / root) jest wątpliwa.

W każdym razie przyczyną jest zbyt duża rpool / export / home / admin (3,85 GB). Sprawdź jego zawartość i usuń niepotrzebne pliki. Ponieważ system plików administratora nie ma migawek, powinno to natychmiast zwolnić miejsce w puli.

Miałem to i spędziłem chwilę próbując dowiedzieć się, co było potrzebne. Moje rozwiązanie polegało na wyzerowaniu przestrzeni plików przed próbą ich usunięcia.

Mamy kilka źle zachowujących się procesów, które czasem wariują i wypełniają dysk podstawowymi plikami (kończącymi się cyframi), więc stworzyłem skrypt, który zawiera coś takiego, aby zachować jedną kopię.

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

Po uruchomieniu skryptu wystąpił jeden błąd:

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

i działało wyczyszczenie plików.

Aby to przetestować, zapełniłem dysk:

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