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)

---

Zurück zur Hauptseite