Νέα από τον πλανήτη… planet.ellak.gr: Πού πήγε ο χώρος στον δίσκο; Ασφαλής διάγνωση και καθαρισμός στο Linux

by: Linux Insider

Το μήνυμα «No space left on device» μοιάζει απλό, αλλά δεν έχει πάντα την ίδια αιτία. Μπορεί να γέμισε πραγματικά ένα filesystem, να εξαντλήθηκαν τα inodes από εκατομμύρια μικρά αρχεία, ένα μεγάλο log να διαγράφηκε ενώ η υπηρεσία εξακολουθεί να το κρατά ανοικτό ή snapshots και container layers να διατηρούν δεδομένα που δεν φαίνονται στον προσωπικό μας φάκελο.

Η σωστή σειρά είναι διάγνωση, επιβεβαίωση και μετά καθαρισμός. Δεν ξεκινάμε με τυχαία rm, δεν διαγράφουμε ολόκληρο το ~/.cache επειδή είναι μεγάλο και δεν εκτελούμε prune σε containers χωρίς να δούμε τι πρόκειται να χαθεί.

Πρώτα βρείτε ποιο filesystem γέμισε

df -h

Το df εμφανίζει τη χρήση των mounted filesystems. Κοιτάξτε τις στήλες Use% και Mounted on. Το /, το /home, ένα ξεχωριστό /var και ένας εξωτερικός δίσκος μπορεί να είναι διαφορετικά filesystems. Το ότι υπάρχει χώρος στο /home δεν βοηθά αν έχει γεμίσει το /var.

Για πιο καθαρή έξοδο:

df -h --output=source,fstype,size,used,avail,pcent,target

Τα pseudo-filesystems όπως tmpfs δεν είναι απαραίτητα πρόβλημα. Εστιάστε στο mount point όπου αποτυγχάνει η εγγραφή και επιβεβαιώστε ότι εξετάζετε τη σωστή συσκευή.

Ελέγξτε τα inodes, όχι μόνο τα gigabytes

df -i

Κάθε αρχείο και κατάλογος χρειάζεται inode. Ένα filesystem μπορεί να έχει διαθέσιμα gigabytes αλλά μηδενικά ελεύθερα inodes, συνήθως επειδή δημιουργήθηκε τεράστιος αριθμός μικρών cache, session, mail ή build files. Αν το IUse% είναι 100%, η λύση δεν είναι να αναζητήσετε μόνο ένα μεγάλο ISO· πρέπει να βρείτε τον κατάλογο με τα πάρα πολλά entries.

Ένας πρώτος έλεγχος στο home:

du --inodes -d 2 "$HOME" 2>/dev/null | sort -n | tail -30

Η εντολή μετρά τη χρήση inodes ανά κλάδο. Δεν διαγράφει τίποτα. Σε πολύ μεγάλα trees μπορεί να χρειαστεί χρόνο.

Βρείτε τους μεγάλους καταλόγους με du

Για τον προσωπικό κατάλογο:

du -xhd1 "$HOME" 2>/dev/null | sort -h

Το -x παραμένει στο ίδιο filesystem, το -h εμφανίζει αναγνώσιμα μεγέθη και το -d1 δείχνει μόνο το πρώτο επίπεδο. Μόλις βρείτε έναν μεγάλο κατάλογο, επαναλάβετε την εντολή μέσα σε αυτόν:

du -xhd1 "$HOME/.local" 2>/dev/null | sort -h

Για ολόκληρο το root filesystem χρειάζονται συνήθως δικαιώματα διαχειριστή:

sudo du -xhd1 / | sort -h

Μην αφαιρέσετε το -x χωρίς λόγο. Διαφορετικά η σάρωση μπορεί να περάσει σε εξωτερικούς δίσκους, network mounts ή άλλα filesystems και να δημιουργήσει παραπλανητικό σύνολο.

ncdu: η ίδια έρευνα με διαδραστική πλοήγηση

Το ncdu κάνει ευκολότερη την εξερεύνηση μεγάλων directory trees:

ncdu -x "$HOME"

Για system directories:

sudo ncdu -x /

Δεν είναι προεγκατεστημένο σε κάθε διανομή, αλλά υπάρχει συνήθως στα repositories. Χρησιμοποιήστε το αρχικά μόνο ως viewer. Η δυνατότητα διαγραφής μέσα από το ncdu είναι πραγματική διαγραφή και δεν αποτελεί υποκατάστατο για package manager, snapshot manager ή γνώση του περιεχομένου ενός καταλόγου.

Γιατί διαφωνούν df και du;

Το df ρωτά το filesystem πόσα blocks χρησιμοποιούνται. Το du αθροίζει όσα αρχεία μπορεί να διασχίσει. Μικρές διαφορές είναι φυσιολογικές λόγω metadata, reserved blocks, snapshots, permissions, sparse files και διαφορετικών τρόπων μέτρησης.

Μεγάλη διαφορά μπορεί να σημαίνει ότι μια διεργασία κρατά ανοικτό ένα αρχείο που έχει ήδη διαγραφεί. Το pathname εξαφανίστηκε, αλλά τα blocks δεν απελευθερώνονται μέχρι να κλείσει και ο τελευταίος file descriptor:

sudo lsof +L1

Κοιτάξτε τις στήλες process, PID και size. Η ασφαλέστερη ενέργεια είναι συνήθως να επανεκκινήσετε ελεγχόμενα τη συγκεκριμένη υπηρεσία ή εφαρμογή, αφού βεβαιωθείτε ότι επιτρέπεται διακοπή της. Μην τερματίζετε τυχαία διεργασίες παραγωγής και μην πειράζετε descriptors κάτω από το /proc χωρίς σχέδιο ανάκαμψης.

Μετρήστε τα systemd journals

journalctl --disk-usage

Η εντολή είναι read-only και εμφανίζει το συνολικό μέγεθος ενεργών και αρχειοθετημένων journal files. Αν τα logs έχουν διογκωθεί, εξετάστε πρώτα τι γράφεται:

journalctl -p warning --since today
journalctl --since today | tail -100

Η συνεχής επανάληψη ενός error χρειάζεται διόρθωση της αιτίας, όχι μόνο διαγραφή του ιστορικού. Αν αποφασίσετε ότι μπορείτε να περιορίσετε τα παλιά logs:

sudo journalctl --rotate --vacuum-size=500M

Αυτή είναι μη αναστρέψιμη ενέργεια: περιστρέφει τα ενεργά journals και αφαιρεί τα παλαιότερα αρχειοθετημένα μέχρι το σύνολο που μπορεί να γίνει vacuum να πέσει στο επιλεγμένο όριο. Μπορεί να αφαιρέσει στοιχεία χρήσιμα για troubleshooting, auditing ή διερεύνηση περιστατικού. Επιλέξτε όριο που ταιριάζει στο σύστημά σας και ρυθμίστε μόνιμη πολιτική journald αν το πρόβλημα επανέρχεται.

Flatpak: εφαρμογές, runtimes και παλιά branches

Δείτε πρώτα τι είναι εγκατεστημένο:

flatpak list --app
flatpak list --runtime

Για refs που δεν χρειάζονται πλέον οι εγκατεστημένες εφαρμογές:

flatpak uninstall --unused

Διαβάστε τη λίστα πριν επιβεβαιώσετε. Η εντολή αφαιρεί unused runtimes και extensions, όχι γενικά «άχρηστα αρχεία» που έχει αποφασίσει ένας καθαριστής. Αν χρησιμοποιείτε SDKs για ανάπτυξη ή κρατάτε συγκεκριμένα branches για δοκιμές, βεβαιωθείτε ότι δεν τα χρειάζεστε.

Τα δεδομένα των Flatpak εφαρμογών βρίσκονται συνήθως κάτω από ~/.var/app. Μετρήστε τα ξεχωριστά:

du -xhd1 ~/.var/app 2>/dev/null | sort -h

Η απεγκατάσταση μιας εφαρμογής δεν σημαίνει πάντοτε ότι θέλετε να χαθούν και τα προσωπικά της δεδομένα. Εξετάστε τον αντίστοιχο κατάλογο και κρατήστε backup πριν από χειροκίνητη διαγραφή.

Package caches: καθαρίστε με το εργαλείο της διανομής

Οι package managers κρατούν downloaded packages ώστε επανεγκαταστάσεις ή rollback να είναι γρηγορότερα. Μετρήστε πρώτα τους σχετικούς καταλόγους και χρησιμοποιήστε το επίσημο εργαλείο, όχι rm μέσα στη βάση πακέτων.

Σε Debian και Ubuntu, για το cache των κατεβασμένων πακέτων:

sudo apt clean

Σε Fedora και άλλες διανομές με DNF:

sudo dnf clean packages

Οι εντολές αυτές αδειάζουν package caches και δεν απεγκαθιστούν εγκατεστημένα πακέτα. Εντολές όπως autoremove είναι διαφορετική κατηγορία: προτείνουν αφαίρεση πακέτων. Αν τις χρησιμοποιήσετε, ελέγξτε ένα προς ένα όσα πρόκειται να αφαιρεθούν.

Browser caches, thumbnails και Trash

Δείτε ποιο τμήμα του προσωπικού cache είναι μεγάλο:

du -xhd1 ~/.cache 2>/dev/null | sort -h

Ένα cache συνήθως αναδημιουργείται, αλλά αυτό δεν σημαίνει ότι κάθε κατάλογος κάτω από ~/.cache είναι ασφαλές να διαγραφεί ενώ η εφαρμογή τρέχει. Κλείστε την αντίστοιχη εφαρμογή και χρησιμοποιήστε τις δικές της επιλογές καθαρισμού όπου υπάρχουν. Μετά τη διαγραφή, ο browser ή το desktop μπορεί να χρειαστεί χρόνο και bandwidth για να ξαναδημιουργήσει δεδομένα.

Ελέγξτε επίσης τον Κάδο Απορριμμάτων από το file manager. Το «Delete» συχνά μετακινεί αρχεία στον Trash αντί να επιστρέφει αμέσως τον χώρο. Αδειάστε τον μόνο αφού ελέγξετε το περιεχόμενο, επειδή αυτή είναι η στιγμή που χάνεται η εύκολη δυνατότητα επαναφοράς.

Containers: πρώτα system df, μετά απόφαση

Images, writable layers, stopped containers και build caches μπορούν να καταλάβουν δεκάδες gigabytes. Μετρήστε τα με το εργαλείο που χρησιμοποιείτε:

docker system df
podman system df

Μην εκτελέσετε μηχανικά system prune. Ένα stopped container μπορεί να περιέχει δεδομένα που δεν έχουν μεταφερθεί σε volume, ενώ ένα παλιό image μπορεί να είναι απαραίτητο για rollback ή offline deployment. Εξετάστε containers, images, volumes και build cache ξεχωριστά πριν αφαιρέσετε οτιδήποτε.

Btrfs snapshots: το αρχείο έφυγε, τα blocks έμειναν

Σε Btrfs, ένα snapshot μπορεί να συνεχίζει να αναφέρεται στα ίδια extents μετά τη διαγραφή ενός αρχείου από το τρέχον subvolume. Έτσι το du ενός καταλόγου μπορεί να μειωθεί χωρίς αντίστοιχη άμεση πτώση στη συνολική χρήση.

sudo btrfs filesystem usage /
sudo btrfs subvolume list /

Αν χρησιμοποιείτε Timeshift, Snapper ή εργαλείο της διανομής, διαχειριστείτε τα snapshots από εκεί. Μην αντιμετωπίζετε έναν snapshot κατάλογο σαν συνηθισμένο directory και μην τον αφαιρείτε με αναδρομικό rm. Επιβεβαιώστε ποια snapshots είναι bootable, ποια χρησιμοποιούνται από πολιτική rollback και ποια επιτρέπεται να διαγραφούν.

Ένα ασφαλές workflow δέκα λεπτών

Τρέξτε df -h και εντοπίστε το πραγματικά γεμάτο filesystem.
Τρέξτε df -i για να αποκλείσετε εξάντληση inodes.
Χρησιμοποιήστε du -xhd1 ή ncdu -x στο συγκεκριμένο mount point.
Αν το df δείχνει πολύ περισσότερα από το du, ελέγξτε lsof +L1, snapshots και reserved/filesystem metadata.
Μετρήστε χωριστά journals, Flatpak, package caches και containers.
Καθαρίστε μία κατηγορία κάθε φορά και ξανατρέξτε df -h.
Καταγράψτε τι μεγάλωσε. Αν επιστρέψει γρήγορα, διορθώστε την πηγή αντί να προγραμματίσετε τυφλή περιοδική διαγραφή.

Το βασικό συμπέρασμα

Το «γεμάτος δίσκος» είναι σύμπτωμα, όχι διάγνωση. Το df δείχνει ποιο filesystem πιέζεται, το df -i αν λείπουν inodes, τα du και ncdu πού βρίσκονται τα ορατά δεδομένα, ενώ τα journals, τα open deleted files, τα containers και τα snapshots εξηγούν συχνά όσα δεν φαίνονται με την πρώτη ματιά.

Η πιο ασφαλής διαγραφή είναι εκείνη που γίνεται από το εργαλείο που δημιούργησε τα δεδομένα: package manager για package cache, Flatpak για unused runtimes, journalctl για journals και snapshot manager για snapshots. Μετρήστε πριν και μετά, κρατήστε backup για ό,τι είναι προσωπικό και μη μετατρέπετε το cleanup σε αυτοματισμό πριν καταλάβετε γιατί ο χώρος τελειώνει.

Για τις ακριβείς επιλογές μέτρησης δείτε τα επίσημα εγχειρίδια των GNU df, GNU du και journalctl.

Πηγή άρθρου: https://planet.ellak.gr/ , https://www.linuxinsider.gr/