Pełny dysk w Linuxie — jak brak miejsca wpływa na wydajność i aktualizacje?

W Linuxie pełny dysk potrafi objawić się bardziej gwałtownie niż w systemach, które prowadzą użytkownika za rękę. Nagle nie działa aktualizacja, nie zapisują się logi, aplikacja kończy pracę z błędem „No space left on device”, a środowisko graficzne zaczyna reagować z opóźnieniem.

Brak miejsca na partycji root, /home, /var albo /boot może wpływać nie tylko na wygodę pracy, ale też na stabilność aktualizacji i uruchamianie systemu. Dlatego w Linuxie trzeba sprawdzać nie tylko „ile jest wolnego na dysku”, ale też na której partycji tego miejsca zabrakło.

Czy pełny dysk w Linuxie naprawdę spowalnia system?

Tak, ale odpowiedź zależy od tego, która część systemu jest pełna. Jeśli zapełni się /home, użytkownik może nie zapisywać plików i profili aplikacji. Jeśli zapełni się /var, problem dotknie logów, cache menedżera pakietów i części usług. Jeśli zabraknie miejsca na /boot, aktualizacja jądra może się nie udać.

Linux zwykle nie ukrywa problemu za prostym komunikatem graficznym. Objawy bywają techniczne: błędy zapisu, przerwana aktualizacja, brak możliwości zalogowania do środowiska graficznego, awarie przeglądarki, przepełnione logi albo komunikat „No space left on device”. To nie jest moment na losowe kasowanie katalogów z sudo.

Partycje w Linuxie — dlaczego samo „mam miejsce na dysku” nie wystarcza

W wielu instalacjach Linuxa osobne partycje lub woluminy mogą obsługiwać /, /home, /boot, /var, a czasem także migawki Btrfs lub LVM. To oznacza, że jedna część dysku może mieć dużo wolnego miejsca, a inna może być pełna i blokować system.

Przykład jest prosty: możesz mieć wolne miejsce w /home, ale pełne /boot z kilkoma starymi jądrami. Możesz mieć przestrzeń na dużym dysku danych, ale pełne /var/cache po aktualizacjach. Dlatego podstawowym poleceniem diagnostycznym jest df -h, a nie samo patrzenie na rozmiar dysku w narzędziu graficznym.

W systemach serwerowych i stacjach roboczych szczególnie groźne jest zapełnienie /var/log. Usługi nadal próbują pisać logi, ale nie mają gdzie. W efekcie diagnostyka staje się trudniejsza dokładnie wtedy, gdy jest najbardziej potrzebna.

Swap, RAM i pełny dysk — skąd biorą się zawieszki

Linux korzysta z pamięci RAM, cache systemowego i przestrzeni wymiany, czyli swap. Swap może być osobną partycją albo plikiem. Gdy RAM się kończy, system może przenosić mniej aktywne strony pamięci do swapu. Jeśli swap jest zbyt mały, wyłączony albo system nie ma miejsca na plik wymiany, przy dużym obciążeniu może pojawić się szamotanie pamięci i gwałtowny spadek responsywności.

Nie każdy Linux z pełnym dyskiem zacznie od razu swapować. Problem polega na tym, że brak miejsca ogranicza margines bezpieczeństwa: aplikacje nie zapiszą cache, usługi nie zapiszą logów, a system może zacząć zamykać procesy przez OOM Killer.

Jeśli komputer zwalnia przy wielu kartach przeglądarki, sprawdź jednocześnie wolne miejsce, użycie RAM i swap. Samo czyszczenie dysku nie zastąpi dołożenia pamięci, jeśli RAM regularnie dobija do granicy.

Aktualizacje Linuxa i pełne /var, /boot oraz cache pakietów

Menedżery pakietów zapisują pobrane pakiety w cache. W Debianie, Ubuntu i Mint typowym miejscem jest /var/cache/apt/archives. Fedora korzysta z cache DNF, a Arch Linux trzyma paczki pacmana w /var/cache/pacman/pkg. Te katalogi są przydatne, ale mogą rosnąć przez lata.

Szczególnie nieprzyjemny scenariusz to brak miejsca w trakcie aktualizacji jądra. System musi pobrać paczki, rozpakować je, wygenerować initramfs i zaktualizować konfigurację bootloadera. Jeśli zabraknie miejsca po drodze, aktualizacja może zostać w stanie częściowo skonfigurowanym.

W Debianie i Ubuntu po odzyskaniu miejsca często trzeba dokończyć konfigurację poleceniem sudo dpkg --configure -a. W Fedorze przydaje się kontrolowane czyszczenie DNF, a w Archu regularne zarządzanie cache pacmana przez paccache. Najbezpieczniej czyścić cache narzędziami menedżera pakietów, a nie przez ręczne kasowanie losowych plików z /var.

Pełny SSD pod Linuxem — TRIM, fstrim i wolne bloki

Na Linuxie pełny SSD ma te same ograniczenia fizyczne co w Windows i macOS. Pamięć NAND nie nadpisuje danych tak jak klasyczny dysk talerzowy. Kontroler SSD potrzebuje wolnych bloków, aby sprawnie realizować Garbage Collection, wear leveling i operacje po komendzie TRIM.

W wielu dystrybucjach okresowe TRIM jest realizowane przez usługę lub timer fstrim. Można też używać opcji discard, choć w typowych instalacjach częściej zaleca się okresowe fstrim niż stały discard dla każdego zapisu. Szczegóły zależą od dystrybucji, systemu plików i nośnika.

Nawet jeśli TRIM działa poprawnie, zapełnienie SSD po brzegi ogranicza przestrzeń roboczą kontrolera. Dlatego na dysku systemowym warto zostawić praktyczny bufor 10–15%, a przy intensywnych zapisach więcej.

Nie korzystasz z Linuxa i szukasz poradnika dla pełnego dysku na Windows lub MacOS? Przeczytaj te artykuły:

• Pełny dysk w Windows — jak brak miejsca wpływa na wydajność komputera?
• Pełny dysk w macOS — jak brak miejsca wpływa na szybkość Maca?

Jak sprawdzić, co zajmuje miejsce w Linuxie

Pierwsze polecenie to df -h. Pokazuje ono zajętość zamontowanych systemów plików w czytelnych jednostkach. Dzięki temu szybko widać, czy pełne jest /, /home, /boot, /var, osobny dysk danych czy wolumin migawkowy.

Drugim krokiem jest lokalizacja największych katalogów. Można użyć sudo du -h --max-depth=1 / | sort -hr | head -n 15, a potem schodzić głębiej w katalogi. Na komputerze użytkownika wygodniejsze bywa ncdu, Baobab w GNOME albo Filelight w KDE.

Warto osobno sprawdzić /var/log, /var/cache, katalog domowy, foldery pobierania, katalogi maszyn wirtualnych, obrazy kontenerów, katalogi Flatpak i Snap oraz migawki Timeshift lub Btrfs.

Co najczęściej zajmuje miejsce w Linuxie

Najczęstsze źródła problemu to cache menedżerów pakietów, stare wersje jąder, logi systemowe, migawki systemu, katalog Downloads, kontenery Dockera lub Podmana, obrazy maszyn wirtualnych, cache przeglądarek, katalogi projektów programistycznych i runtime’y Flatpak.

Na komputerach deweloperskich ogromne potrafią być katalogi node_modules, obrazy kontenerów, lokalne bazy danych i buildy projektów. Na komputerach domowych częściej winne są multimedia, gry, backupy i niekontrolowane katalogi synchronizacji chmury.

W Linuxie „duży katalog” nie zawsze oznacza „katalog do usunięcia”. Zanim usuniesz coś z sudo, sprawdź, czy należy to do systemu, menedżera pakietów, kontenera, aplikacji Flatpak lub migawki.

Bezpieczne czyszczenie apt, dnf, pacman, Snap i Flatpak

W Debianie, Ubuntu i Mint typowym, bezpiecznym krokiem jest sudo apt clean, które usuwa pobrane pakiety z cache. sudo apt autoremove może usunąć niepotrzebne zależności, ale przed potwierdzeniem warto przeczytać listę pakietów.

W Fedorze do czyszczenia cache służy sudo dnf clean all. W Archu cache pacmana nie czyści się automatycznie do zera; zalecane jest używanie paccache, np. pozostawienie kilku ostatnich wersji paczek zamiast kasowania wszystkiego bez planu.

Dla Flatpak przydatne jest flatpak uninstall --unused, a dla Snap warto sprawdzić stare rewizje pakietów. W każdym przypadku zasada jest taka sama: najpierw używaj narzędzi właściwych dla danej technologii, dopiero potem rozważ ręczne działania.

Czego nie usuwać ręcznie w Linuxie

Nie usuwaj ręcznie katalogów /usr, /bin, /sbin, /lib, /lib64, /etc, /var/lib ani przypadkowych plików z /boot. Nie kasuj też zawartości bazy menedżera pakietów, jeśli nie wiesz dokładnie, co robisz. To może uszkodzić zależności, pakiety i rozruch systemu.

Ostrożnie z /tmp i /var/tmp. Część danych tymczasowych jest rzeczywiście tymczasowa, ale niektóre aktywne procesy mogą ich używać. Bezpieczniejsze są systemowe mechanizmy czyszczenia, restart albo narzędzia dystrybucji.

Szczególną uwagę zachowaj przy migawkach Btrfs, Timeshift i LVM. Usunięcie migawek może odzyskać dużo miejsca, ale może też pozbawić możliwości cofnięcia systemu po nieudanej aktualizacji.

Kiedy czyszczenie Linuxa nie wystarczy

Jeśli problem stale wraca, warto sprawdzić, czy partycje są sensownie podzielone. Być może / jest zbyt mały, /home ma za dużo danych, /boot gromadzi stare jądra, a /var przechowuje cache, kontenery i logi. Czasem lepsze od kolejnego czyszczenia jest powiększenie partycji albo przeniesienie danych na osobny dysk.

Na SSD warto sprawdzić S.M.A.R.T. przez smartctl, a także upewnić się, że działa okresowe TRIM. Przy komputerach z małą ilością RAM sprawdź swap i użycie pamięci. Przy serwerach sprawdź logrotate, retencję dziennika systemd i limity logów aplikacji.

Linux daje dużą kontrolę, ale wymaga też większej odpowiedzialności. Najpierw diagnoza, potem czyszczenie, a dopiero na końcu ręczne usuwanie nietypowych danych.

Objaw, możliwy związek z pełnym dyskiem i bezpieczne działanie

Bezpieczne i ryzykowne czyszczenie w Linuxie

Podsumowanie

W Linuxie pełny dysk trzeba diagnozować z podziałem na partycje i punkty montowania. Inaczej rozwiązuje się pełne /home, inaczej /boot, a inaczej /var. Najbezpieczniejsza ścieżka to df -h, analiza największych katalogów, czyszczenie cache właściwym menedżerem pakietów, kontrola logów i migawek, a dopiero potem decyzja o zmianie partycjonowania lub większym dysku.