Btrfs
Erste Erfahrungen mit dem neuen btrfs-Dateisystem
Mit der (Neu-)Installation von openSUSE 12.1 auf meinen Desktop Rechner, habe ich zugleich das neue Linux Dateisystem btrfs für die root-Partition eingerichtet. Dieses wählte ich mit einer Größe von 34GB, zusätzlich wurde eine /boot-Partition mit 4GB und eine /tmp-Partition mit 14GB beide mit ext4 eingerichtet. Zusätzlich wurde das bestehende swap Dateisystem mit 16GB und eine Partition mit openSUSE 11.4 mit 36GB mit eingebunden.
Erste Problem - Systemplatte voll!
Insgesamt macht das Dateisystem eine gute Figur - bis vor ein paar Tagen. Es kamen komische Fehler beim täglich zypper ref ; zypper dup und KDE ist abgestürzt, was schon lange nicht mehr vorgekommen ist. Nach einer kurzen Suche, habe ich dann gleich gesehen, dass das Dateisystem voll ist:
# df -h Filesystem Size Used Avail Use% Mounted on rootfs 34G 28G 428K 100% / devtmpfs 3.8G 48K 3.8G 1% /dev tmpfs 3.8G 0 3.8G 0% /dev/shm tmpfs 3.8G 648K 3.8G 1% /run /dev/sda5 34G 28G 428K 100% / /dev/sda2 4.0G 114M 3.7G 3% /boot /dev/sda3 14G 6.0G 6.9G 47% /tmp tmpfs 3.8G 648K 3.8G 1% /var/lock tmpfs 3.8G 0 3.8G 0% /media
Um die Ursache auf den Grund zu gehen, habe ich mal die Festplatten Belegung überprüft:
# du -hcs 11M /bin 42M /boot 48K /dev 32M /etc 0 /home 192M /lib 24M /lib64 0 /media 0 /mnt 176M /opt 0 /proc 933K /root 648K /run 16M /sbin 0 /selinux 1.3M /srv 0 /sys 5.8G /tmp 9.7G /usr 1.6G /var 18G total
Ups - es sind nur 18GB belegt, von denen ja noch die 42M der boot-Partition und 5,8GB der tmp-Partition abgezogen werden müssten, also nur etwas über 12GB von 34GB! Was ist der Grund? Wieso werden überhaupt 34GB - 28GB = 6GB für das System benötigt? Also Fragen über Fragen! Anmerkung: /home ist bei mir auf einem NFS Server ausgelagert - der dieses täglich sichert - für die Arbeiten am Rechner wurde dieses sicherheitshalber gar nicht gemounted - weshalb es hier auch 0 Byte groß ist
Der Lösungsansatz
Nach einigen Recherchen (auf einen anderen Rechner - es lief auf meinen Hauptrechner ja gar nichts mehr) fand ich das openSUSE Snapper Portal. Hier habe dann erfahren, dass unter openSUSE nicht direkt mit dem Befehl btrfs und einigen dazugehörigen Programmen gearbeitet werden sollte. Eine grundsätzliche Einführung zu Snapper fand ich dann im dort verlinkten Tutorial. Zumindest konnte ich mir jetzt mit Hilfe der recht ordentlichen man Seiten auf dem Rechner dann einige Arbeiten vornehmen.
Anmerkung: Alle genannten Seiten leider nur in Englisch verfügbar!
Der Lösungsweg
Zunächst mal als root auf dem ersten Terminal angemeldet und die man-Seite zu Snapper gelesen:
man snapper
Dann mal die relevanten Configs angesehen
cat /etc/cron.daily/suse.de-snapper cat /etc/sysconfig/snapper cat /etc/snapper/configs/root cat /etc/snapper/config-templates/default tailf -n 100 /var/log/snapper.log snapper list-configs
Anschließend in der im Cronjob aufgerufenen Config die zyklische Generierung von snapshots mit ändern von IMELINE_CREATE="no" unterbunden:
joe /etc/snapper/configs/root rm /etc/snapper/configs/root~
Dann der versuch das Dateisystem aufzuräumen - was aber nur minimalen Erfolg brachte (ein paar kByte mehr Platz):
snapper -v cleanup empty-pre-post snapper -v cleanup timeline snapper -v cleanup number
Dann der Gewaltakt - den Cronjob manuell mal zu starten - brachte aber auch nur wenig erfolgt (ein paar MByte mehr Platz):
/etc/cron.daily/suse.de-snapper
Dann der Marathon weg, alle älteren Snapshots manuell zu löschen. Zunächst mal ansehen was für Snapshots existieren:
# snapper list Type | # | Pre # | Date | Cleanup | Description | Userdata -------+---+-------+------------------------------+----------+----------------------+--------- single | 0 | | | | current | single | 1 | | Tue 22 Nov 2011 10:30:02 CET | timeline | timeline | pre | 2 | | Tue 22 Nov 2011 10:41:28 CET | number | yast system_settings | post | 3 | 2 | Tue 22 Nov 2011 10:41:49 CET | number | |
Diese liegen übrigens in /.snapshots - lassen sich aber nicht in der Größe mit du ermitteln, da sie mit Hardlinks arbeiten. Der erste Eintrag in obiger Liste mit der Bezeichnung single und der Nummer 0 ist die aktuelle Version, mit der man gerade arbeitet - und darf auf 'keinen Fall gelöscht werden!!!'
Nun wie gesagt, habe ich alle älteren Sicherungen von der höchsten Nummer zur niedrigsten gelöscht, bis nur noch 20 Einträge in der Liste waren. Hier würde ich mit dem folgenden Befehl den letzten post Snapshot mit der Nummer 3 löschen:
snapper delete 3
Das hat mir dann ca. 2,5GB an Platz gebracht.
Am Ende kann man dann noch das btrfs defragmentieren. Dazu verwendet man für die root-Partition wie bei mir den nachfolgenden Befehl:
btrfs filesystem defragment /
Zusätzliche Maßname
Um einer Wiederholung des Problems vorzubeugen, habe ich das größte Unterverzeichnis (bei mir /usr mit etwa 10GB in eine separate 16GB große Partition gelegt und das alte Verzeichnis gelöscht. Das war gar nicht so einfach, hat aber funktioniert. Leider ist aber der Freie Plattenplatz nicht größer geworden, da die Daten ja weiterhin im vorletzten Snapshot, den ich nicht gelöscht habe enthalten sind.
Aktuelles Ergebnis
Eine aktuelle Überprüfung ergibt wieder ein arbeitsfähiges System - was aber noch keine Prickelnden Reserven bietet. Hier muss noch einiges an btrfs gemacht werden, um solche Situationen sicher zu umgehen - auf einen Server kann diese Situation tödlich sein!
# df -h Filesystem Size Used Avail Use% Mounted on rootfs 34G 26G 2.2G 93% / devtmpfs 3.8G 52K 3.8G 1% /dev tmpfs 3.8G 1.6M 3.8G 1% /dev/shm tmpfs 3.8G 664K 3.8G 1% /run /dev/sda5 34G 26G 2.2G 93% / /dev/sda7 17G 11G 2.1G 84% /usr /dev/sda2 4.0G 158M 3.7G 5% /boot /dev/sda3 14G 6.1G 6.9G 47% /tmp /dev/sda6 36G 15G 20G 43% /mnt/openSUSE11.4-sda6 tmpfs 3.8G 664K 3.8G 1% /var/lock tmpfs 3.8G 0 3.8G 0% /media
--Ulf 21:56, 10. Jan. 2012 (CET)
