Ich hatte folgendes Problem, vlt. kann man einen Teil davon mit in die FAQ aufnehmen:
"Letzte Hilfe: Subvols aus Readonly-Snapshots neu aufsetzen"
Mein in die Jahre gekommener HTPC läuft mit Trusty LTS, aber Kernel 3.19 auf einer 2011er Crucial M4 SSD mit 128 GB und 3 >=1TB Platten für Medien.
Board hat noch kein EFI, also habe ich da ein "align@MIB"-gparted-Setup mit MDOS-Disklabel auf der SSD, die Medienplatten haben gpt.
Die SSD hat ein /dev/sda1 als /boot mit ext2 (500 MiB) ein /dev/sda2 mit btrfs mit rootvol + 3 subvols "@" "@home" "@opt" mit compress=lzo.
Am "Ende" der SSD ist sind noch ein paar kleine partitionen für ZFS/L2-ARC und ZIL für den einen kleinen zpool, der u.a. mit auf den Medienplatten ist..
Das /opt als extra subvol gibt es hautpsächlich aus historischen Gründen: Da liegt u.a. ein Virtualbox-win8.1-VDI, dass ich alle Jubeljahre mal brauche..
Backup-Strategie ist, den mbr per dd, das /boot per rsync und das layout <hab ich vergessen wie> maschinenlesbar zu sichern in einen Ordner im Hauptvolume:
mount /dev/sda2 /mnt/b-snap
cd /mnt/b-snap
ls -la
"@ @home @opt trg zz-snaps"
cd trg
ls -la
<boot> mbr.bin partitioninfo [@${isodate}] [home@{isodate}] [opt@{isodate}] zz-snapme.sh
wobei <> ein Verzeichnis ist und [] vom zz-snapme.sh erstellte Readonly-Snapshots der Subvols aus /mnt/b-snap sind.
Das ganze landet dann in einem Squashfs, damit man leicht an einzelne Dateien kommt, ohne alles wieder entpacken zu müssen...:
mksquashfs /mnt/b-snap/trg htpc@{isodate}.sq -comp xz
(lz4 wäre mir lieber, aber das kann im Moment das "zu alte" Ubuntu nicht richtig, fedora kann es...)
Soviel zur Ausgangslage.
Das Backup hatte so um die 20 GB (ca. 10 GB Ubuntu, ca. 10 GB win-vdi). Plözlich waren es 30 GB...
Das Problem war, dass das .vdi für das Win8.1 ein Image für max. 40GB war und schließlich auch bei 40 GB gelandet ist.
(Das .vdi war im dafür hauptsächlich vorgesehen "@opt", dessen snapshots sollen nämlich separat löschbar sein...)
Der Grund für den Speicherplatzanstieg war der "c:/windows/winsxs" Ordner im virtualisierten Windows.
Eine vermurkste Sache, wen es interessiert ⇒ google.
Mit Gewalt habe ich diesen sog. ComponentStore dann von 20 GB auf 5GB zusammengestrichen mit "dism.exe" und ich weiss nicht mehr was noch alles...
Nur BTRFS hat das nicht interessiert. Dabei fand ich es praktisch, dass das VDI auf BTRFs liegt und somit - wie wenn es auf ZFS läge - ich meine eigenen Snapshots machen kann und weder die Variante von Virtualbox brauche, noch die von Windows (eine unsäglicher als die andere...).
Die Performance der VM auf der SSD war OK, trotz COW...
Das eigentliche Windows 8.1 scheint aber nur so aus 2 bis 4 GB zu bestehen. Alles andere ist Bloat. Belegt lt. Win sind danach ca. 20 GB, das VDI liess sich aber nur - trotz
sdelete -z c:
nur auf 30 GB verkleinern, mittels
vboxmanage modifyhd win8.vdi --compact
# oder so ähnlich?
Der Rest ist wahrscheinlich NTFS-Metadatenmüll, der sich nicht bereinigen lässt, weil win8.1 bei SSDs das Defragmentieren verweigert und ich das in der VBox mit eingestellt habe, dass das VDI auf SSD liegt... soll auch so bleiben..
Nach einem
| btrfs bal start /mnt/b-snap
|
hätten auf dem 100GB BTRFS dann noch ca. 60% frei sein sollen, also ca. 15GB für Ubuntu und ca. 30GB für Win-VDI-on-BTRFS.
Es waren leider immer noch 70 GB von 100 GB belegt und keine Änderung, trotz Entfernen aller Readonly-snapshots, d.h. der Übeltäter war nicht auffindbar... Idee war hier, einfach neue Subvols aufzusetzen und die Dateien - nicht das System mit btrfs send/receive - neu zu kopieren, ist ja eh auf SSD... wer weiss was die alten Kernel in den letzten Jahren so alles mit dem BTRFs auf der SSD da so angestellt haben...
So und jetzt, wie löst man das:
Kurzfassung: Alte Volumes mit readonly-Snapshots festhalten, umbenennen, neue erzeugen, Daten kopieren (NICHT mit send/recv), Neustarten, alte Subvolumes löschen, neue Snapshotten, Rebalancen, SSD nullen, rebalancen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | cd /mnt
sudo su
umount /mnt/b-snap
mount /dev/sda2 -o compress=lzo /mnt/b-snap
cd /mnt/b-snap
btrfs sub snap -r @ @goodroot
btrfs sub snap -r @home @goodhome
btrfs sub snap -r @opt @goodopt
mv @ @badroot
mv @home @badhome
mv @opt @badopt
btrfs sub create @
btrfs sub create @home
btrfs sub create @opt
|
Gleich alles aktuelle mit lz4 komprimieren
optional: rsync -axvd hinterherschieben zur Kontrolle.
| cd @
cp -a ../@goodroot/* .
cd ../@home
cp -a ../@goodhome/* .
|
mkdir /srv/my-legacy-xfs-array-on-rotating-disks/save-opt
cp -a ../@goodroot/* /srv/my-legacy-xfs-array-on-rotating-disks/save-opt
}}}
Das spätere Löschen der "schlechten" Subvols vorbereiten (geht erst, wenn die neuen vom System belegt und die alten freigeben sind:
| cd /mnt/b-snaps
mkdir zz-snap
mv @good* zz-snap
mv @bad* zz-snap
|
In der fstab den @opt-Mountpunkt auskommentieren, Neustarten, damit die renovierten @ @home genommen werden.
Achtung: fstab muss im neuen @ geändert werden
| nano /mnt/b-snap/@/etc/fstab # => @opt auskommentieren
init 6
|
GGf.: "S" to skip mounting (ich hatte in /opt/myth/xfs-[bcd] die drei Platten-XFSe für MythTV, "myth" liegt im @opt, das dann ja fehlt
Aufräumen nach Neustart:
| sudo su
mount -o compress=lzo /dev/sda2 /mnt/b-snap
cd /mnt/b-snap/zz-snap
btrfs sub del *
cd ..
|
Schauen, dass es nur noch @, @home und @opt gibt, die anderen werden als "DELETED" angezeigt
| cd /mnt/b-snap
btrfs sub list .
|
Warten, bis btrfs-cleaner den ganzen Müll gelöscht hat
In meinem Fall: 15GB "echte Ubuntu-Daten", auf 9.5GB geschrumpft
Schade für die mit dem vielen Nullen und rebalancen für die SSD, aber SMART meint, sie hätte noch 95% ihrer Zyklen, also nach drei Jahren, und die <200 MB/s write sind ja auch nicht mehr nicht mehr zeitgemäß verglichen mit den 400...800... aktueller SSDs bzw m2 oder pciex-Speiher, also kann sie auch kaputt gehen ⇒ egal!
In einem anderen Terminal
| watch btrfs bal status /mnt/b-snap
|
Dann nur noch 10 GB Extends belegt, baobab sagt es sind 14.5 ⇒ lzo ist also auch schon nicht schlecht..:
Windows wieder zurück auf die SSD packen:
| cd @opt
cp -a /srv/my-legacy-xfs-array-on-rotating-disks/save-opt/* # Annahme in /opt gab es keine versteckten Dateien...
cd ..
|
Und nun:
Data, single: total=40.00GiB, used=39.41GiB
System, single: total=32.00MiB, used=12.00KiB
Metadata, single: total=1.00GiB, used=583.95MiB
unknown, single: total=196.00MiB, used=0.00
JUHUUU keine 70G sondern nur noch 10+30 = 40 (Immer noch 10GB "müll" von Windows, aber egal...)
Und jetzt noch ein goody wg. fstrim oder nicht
Hierzu muss man wissen: btrfs schaut pro Datei nur kurz am Anfang, ob die Daten mit lzo komprimiert werden könne. Also dd /dev/zero geht nicht direkt. Aber so geht es,
ohne dass man neu mounten müsste, um compress=lzo wieder abzuschalten:
| dd if=/dev/urandom bs=4M count=10 of=zerofile.dd
dd if=/dev/zero bs=4M count=14000 seek=9 # 100 - 40 GB, davon etwas weniger, damit man nicht das ganze fs vollschreibt...
|
Ergebnis: 10GB Ubuntu und 30 (statt 40) GB) win8.1, wieder Ruhe für ? 1 Jahr oder bis win10 da ist ?
Feedback willkommen!