Ich habe einen openSUSE-Computer, der schon früh mit BtrFS gestartet ist (wie Leap 42.2). Irgendwann in der Vergangenheit war das /tmp-Subvolume voll (eine große Datei) und ich konnte den Speicherplatz erst nach einem Neustart wiederherstellen ( rmhatte einen ausgelöst No space left on device). Danach sah alles mindestens ein Jahr lang in Ordnung aus.
Aber vor kurzem (mittlerweile bei Leap 15.1) war BtrFS wieder voll und ich fragte mich, was ich tun sollte: Ich hatte viele Snapshots wie diesen:
# ls -l /.snapshots/
total 4
drwxr-xr-x 1 root root 32 Dec 18 2015 1
drwxr-xr-x 1 root root 32 May 14 09:45 1820
drwxr-xr-x 1 root root 66 May 14 09:46 1821
...
drwxr-xr-x 1 root root 32 Aug 8 08:08 1926
drwxr-xr-x 1 root root 38 Aug 8 08:09 1927
drwxr-xr-x 1 root root 38 Aug 8 08:12 1928
Nachdem ich alle Blockprüfsummen erfolgreich geprüft hatte (keine Probleme), startete ich einen „Balance“-Vorgang in der Hoffnung, dass etwas freier Speicherplatz erscheinen würde. Aber der Balance-Vorgang schien nie abgeschlossen zu werden, also versuchte ich, ihn abzubrechen. Nachdem ich mindestens 15 Minuten gewartet hatte, bis der Balance-Vorgang abgebrochen wurde, startete ich den Computer neu, um etwas anderes zu versuchen. Zu diesem Zeitpunkt war das Dateisystem zu 99 % voll.
1Ich dachte, ich würde den ältesten Snapshot ( ) mit bereinigen rm -rf /.snapshots/1. Leider waren danach wichtige Programme von /usrverschwunden und mein System konnte nicht mehr gestartet werden!
Meine Frage ist also: Ist das das erwartete Verhalten oder habe ich etwas falsch gemacht? Wenn ich etwas falsch gemacht habe, was ist das richtige Verfahren zum Entfernen alter Snapshots?
Antwort1
Es scheint, dass die nach dem Entfernen auftretenden Probleme /.snapshots/1nicht so sehr ein Merkmal von BtrFS selbst sind, sondern eher ein (Fehl-?)Merkmal von SUSE Linux:
Ich kann mich nicht erinnern, welches das Root-Dateisystem war, aber auf einem vergleichbaren SLES 15.0-System ist mir aufgefallen, dass der Snapshot 1als Root-Dateisystem gemountet war (aus welchem Grund auch immer):
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=16329060k,nr_inodes=4082265,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,size=24506344k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
#...
/dev/sda2 on / type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/@/.snapshots/1/snapshot)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14427)
#...
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/opt)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/sda2 on /var type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@/var)
#...
/dev/sda2 on /root type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/root)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3267512k,mode=700)
Dies subvol=/@/.snapshots/1/snapshot)scheint die Grundursache zu sein.