staging.inyokaproject.org

Es können GRUB und GRUB 2 bis Maverick Meerkat nicht mit einem Btr-Filesystem umgehen. Deshalb sollten Dateisysteme mit einem im Basisverzeichnis integrierten /boot-Verzeichnis bzw. ein separates /boot-Verzeichnis nicht konvertiert werden.

Wie? Meinst du, dass man eine separate Boot-Partition anlegen sollte, wie an anderer Stelle im Wiki beschrieben? 😉

Das Problem ist nicht BtrFS - sondern die alten Grub-Versionen. Solange Du eine Ubuntu-Version (oder Derivat) Maverick oder älter benutzt, klappt das nicht - es fehlen dort im Grub schlicht die entsprechenden Images (*.mod Dateien).

Und ein selektives Upgraden von Grub ist zwar möglich - bedarf aber gezielter Maßnahmen (also Expertenwissen).

Hi syscon-hh,

sieht sehr gut aus! Evtl. könnte "[ -d /mnt/h* ]" im Skript zu Problemen führen.

Gruss Lasall

Lasall schrieb:

Evtl. könnte "[ -d /mnt/h* ]" im Skript zu Problemen führen.

Solange das nur über das Skript läuft - nein - nun wochenlang und auf mehreren Maschinen getestet. Und händische Einträge, die zufällig so beginnen - na' dann Pech gehabt.

Nein diese Vorlagen sollen nur zum Denken anregen und Hinweise geben, wie man so etwas löst.Bei mir sieht das eine oder andere dann auch anders aus.

Hi syscon-hh,

sehr gut, ich hätte das auch nicht geändert und wollte nur deine Meinung dazu hören 😉 .

Dieser Artikel kann nun imho verschoben werden.

Gruss Lasall (der zum nächsten Artikel weiterzieht)

Verschoben mit Dank an den Autor syscon-hh noch nicht verlinkt, da Hauptartikel BtrFS-Dateisystem noch Baustelle und dort Erwähnung finden sollte.

Hi,

zurückverschoben, da Baustellenlinks im Artikel sind. Beim Review bin ich momentan bis hier gekommen und warte auf Rückmeldung. Anschließend reviewe ich den Artikel Baustelle/BtrFS-Mount Optionen und abschließend müssen wir nochmal über die Bezeichnung (Schreibweise von btrfs/BtrFS) diskutieren.

Gruss Lasall

Hi,

Artikel im Wiki, klasse Arbeit syscon-hh und vielen Dank!

Gruss Lasall

Aus dem Abschnitt Prozessorbelastung:

• nice -n 15 `btrfs filesystem balance /` & 

• cpulimit `btrfs filesystem balance /` -l 20 & 

Die eigentliche Btrfs-Befehlsequenz muss dabei in Akzentzeichen ( ` ) eingefasst werden, um eine eindeutige Zuweisung zu erhalten. Mit dem & -Zeichen kann man das als Hintergrundprozess starten.

Die Syntax der Befehle sieht aber anders aus.

nice-Manpgae (so auch schon öfters genutzt): nice [OPTION] [COMMAND [ARG]...]
Der Befehl müsste also lauten: nice -n 15 btrfs filesystem balance / & (ohne Akzentzeichen)

Zur cpulimit-Syntax siehe Wiki-Artikel (noch nie genutzt). Demnach müsste es so lauten ($! enthält die PID des letzten Hintergrundprozesses):

btrfs filesystem balance / & cpulimit -p $! -l 20 & 

Die Wirkung von

`Kommando` 

oder

$(Kommando) 

wird im Abschnitt "Command Substitution" der bash-Manpage beschrieben. Command Substitution ersetzt den Befehl durch seine Ausgabe. Beispiel:

$ uname -r
3.2.0-26-generic
$ ls /boot/*$(uname -r)*    # entspricht ls /boot/*3.2.0-26-generic*
/boot/abi-3.2.0-26-generic     /boot/initrd.img-3.2.0-26-generic  /boot/vmlinuz-3.2.0-26-generic
/boot/config-3.2.0-26-generic  /boot/System.map-3.2.0-26-generic

Das kann wohl kaum gemeint sein. Und einfache (') bzw. doppelte Anführungszeichen (") sind hier auch nicht nötig.

Den Hinweis "um eine eindeutige Zuweisung zu erhalten" verstehe ich nicht. Geht es um die Zuweisung der Argumente zu den Befehlen ❓ Die sollte bei nice sowieso funktionieren. Bei cpulimit wären vielleicht Anführungszeichen angebracht, wenn der Befehl eine ähnliche Syntax wie im Zitat angegeben hätte.

Abschnitt Backup und Replay:

Man sollte diese manuelle Methode zugunsten des automatischen Verfahrens vorziehen, welches man sich einrichtet mit dem Paket

• apt-btrfs-snapshot

Befehl zum Installieren der Pakete:

sudo apt-get install apt-btrfs-snapshot 

Verwirrende Satzkonstruktion: "Manuelle Methode vorziehen ←> zugunsten des automatischen Verfahrens"

Besser wäre

Man sollte statt der manuellen Methode das automatische Verfahren vorziehen, welches man sich einrichtet mit dem Paket

• apt-btrfs-snapshot

Befehl zum Installieren der Pakete:

sudo apt-get install apt-btrfs-snapshot 

Oder ist es andersherum gemeint?

Commander Data schrieb:

Fangen wir mit dem einfachsten an:

Abschnitt Backup und Replay:

....

Oder ist es andersherum gemeint?

1.: Ja man sollte auf dieses automatische Verfahren (also das mit dem Paket) verzichten. Langwierige Tests haben ergeben, dass das automatische Verfahren, weil es eben unkoordiniert zum Speichern ansetzt, zu starken Belastungen der CPU-Last führte und dann ein weiter arbeiten unmöglich machte, bis hin zum Einfrieren des Systemes. Das ist zumindest für die Versionen bis 12.04 öfter aufgetreten! Ab Quantal sieht es im Moment schon etwas besser aus. Jedoch halte ich ein ständiges Anlegen von Schnappschüssen, ohne das ich die Auswirkungen der vorangegangenen Paketinstallation überprüfen konnte, auch nicht gerade für vorteilhaft.

2.:

Aus dem Abschnitt Prozessorbelastung:

• nice -n 15 `btrfs filesystem balance /` & 

• cpulimit `btrfs filesystem balance /` -l 20 & 

und so weiter ...

bis hin zu ...

Den Hinweis "um eine eindeutige Zuweisung zu erhalten" verstehe ich nicht. Geht es um die Zuweisung der Argumente zu den Befehlen ❓ Die sollte bei nice sowieso funktionieren. Bei cpulimit wären vielleicht Anführungszeichen angebracht, wenn der Befehl eine ähnliche Syntax wie im Zitat angegeben hätte.

Es sind hier mehrere Ebenen und Anweisungen mit einander verknüpft worden - mal aufgebröselt:

• nice -n 15 → der eigentliche Befehl

  • btrfs filesystem balance → die eigentliche Anweisung für btrfs

    • / → die Option für den btrfs-Befehl

• & → ein neuer Befehl

Das Gleiche bei dem anderen Befehl - nur die Vorgabe der Optionen liegt dabei anders. Zumindest läuft das hier so wie es beschrieben wird. Und es wird nicht das Hochkomma (') sondern das (`) verwendet - hat dann auch eine andere Wertigkeit.

Zum Anderen, dieser Teil der Artikelserie ist ja auch anders zu verstehen - nicht als Anweisung, sondern als Sammlung von Erfahrungen - so wurde es ja auch im Header vorgestellt.

Ansonsten - es ist ein WIKI, jeder der fundierte und gesicherte (Er)Kenntnisse beitragen kann und will, darf das!

syscon-hh schrieb:

Commander Data schrieb:

Oder ist es andersherum gemeint?

1.: Ja man sollte auf dieses automatische Verfahren (also das mit dem Paket) verzichten. Langwierige Tests haben ergeben, dass das automatische Verfahren, weil es eben unkoordiniert zum Speichern ansetzt, zu starken Belastungen der CPU-Last führte und dann ein weiter arbeiten unmöglich machte, bis hin zum Einfrieren des Systemes.

OK, dann ist das aber nicht "zugunsten des automatischen Verfahrens" (eher "zuungunsten"). Ich ändere die Formulierung und ergänze noch knapp die Begründung.

2.:

Aus dem Abschnitt Prozessorbelastung:

• nice -n 15 `btrfs filesystem balance /` & 

• cpulimit `btrfs filesystem balance /` -l 20 & 

und so weiter ...

bis hin zu ...

Den Hinweis "um eine eindeutige Zuweisung zu erhalten" verstehe ich nicht. Geht es um die Zuweisung der Argumente zu den Befehlen ❓ Die sollte bei nice sowieso funktionieren. Bei cpulimit wären vielleicht Anführungszeichen angebracht, wenn der Befehl eine ähnliche Syntax wie im Zitat angegeben hätte.

Es sind hier mehrere Ebenen und Anweisungen mit einander verknüpft worden - mal aufgebröselt:

• nice -n 15 → der eigentliche Befehl

  • btrfs filesystem balance → die eigentliche Anweisung für btrfs

    • / → die Option für den btrfs-Befehl

• & → ein neuer Befehl

Das Gleiche bei dem anderen Befehl - nur die Vorgabe der Optionen liegt dabei anders. Zumindest läuft das hier so wie es beschrieben wird. Und es wird nicht das Hochkomma (') sondern das (`) verwendet - hat dann auch eine andere Wertigkeit.

Ich sehe, dass kein Hochkomma / Anführungszeichen verwendet wird, sondern `. Wie ich schon gesagt habe: `Kommando` entspricht $(Kommando). Die Befehle aus dem Artikel könnte man also auch so schreiben:

• nice -n 15 $(btrfs filesystem balance /) & 

• cpulimit $(btrfs filesystem balance /) -l 20 & 

Nur führt das nicht dazu, dass btrfs mit einem Nice-Wert von 15 bzw. mit einem CPU-Last-Maximum ausgeführt wird. Ich zeige das mal anhand von sleep statt btrfs. (btrfs nutze ich sowieso noch nicht.)

a@A:~$ nice -n 15 `sleep 10` &
[1] 4402
a@A:~$ ps -o nice,command -C sleep
 NI COMMAND
  0 sleep 10
a@A:~$ nice: Mit einer Priorität muss ein Befehl angegeben werden
„nice --help“ gibt weitere Informationen.

[1]+  Exit 125                nice -n 15 `sleep 10`

Folgendes ist passiert:

• sleep 10 wurde gestartet. Sein Nice-Wert lag bei 0 und nicht bei 15, wie ps gezeigt hat.

• Als der sleep-Prozess fertig war, wurde seine (nicht-existente) Ausgabe von der bash in die Befehlszeile eingefügt und nice gestartet: nice -n 15 AUSGABE_VON_SLEEP & (also, da sleep nichts ausgegeben hat: nice -n 15 &)

• nice hat sich über die falsche Aufruf-Syntax beschwert und effektiv nichts getan.

Jetzt das ganze ohne `:

a@A:~$ nice -n 15 sleep 10 &
[1] 4409
a@A:~$ ps -o nice,command -C sleep
 NI COMMAND
 15 sleep 10
a@A:~$ 
[1]+  Fertig                  nice -n 15 sleep 10

nice hat sleep mit einer Priorität von 15 gestartet.

Fazit: Bei nice müssen einfach nur die ` weggelassen werden, damit es so funktioniert, wie gewünscht. Bei cpulimit sind noch andere Anpassungen nötig, aber auch nichts gravierendes:

btrfs filesystem balance / & cpulimit -p $! -l 20 &  

Dadurch würde zuerst btrfs gestartet und dann sofort cpulimit mit der btrfs-PID aufgerufen (entsprechend der Manpage).

Zum Anderen, dieser Teil der Artikelserie ist ja auch anders zu verstehen - nicht als Anweisung, sondern als Sammlung von Erfahrungen - so wurde es ja auch im Header vorgestellt.

Dennoch scheint mir, dass die angegebenen Befehle nicht so funktionieren, wie angegeben. Vielleicht führst du selbst mal die Befehle aus dem Artikel aus, prüfst die nice-Werte bzw. CPU-Auslastung und postest hier die Terminal-Befehle und -Ausgaben. Das würde mich sehr überraschen, wenn die Befehle aus dem Wiki so funktionieren.

Ansonsten - es ist ein WIKI, jeder der fundierte und gesicherte (Er)Kenntnisse beitragen kann und will, darf das!

Weiß ich. ☺ Ich wollte nur nachfragen, um eventuelle Missverständnisse auszubügeln. Bei "Backup und Replay" habe ich mich ja tatsächlich bzgl. der Intention geirrt. Was "Prozessorbelastung" angeht: Wir werden sehen.

Hallo Commander Data, hier die Ergebnisse der heutigen Teste:

Terminal 1 :

laura@PRECISE-G64:~$ sudo -s
[sudo] password for laura: 
root@PRECISE-G64:~# btrfs fi sh
failed to read /dev/sr0
Label: 'PRECISE_DATA'  uuid: 13708e1c-e8eb-4cff-8ad9-54c89bd59d73
	Total devices 1 FS bytes used 105.84GB
	devid    1 size 351.76GB used 144.04GB path /dev/sdb6

Label: 'LINUX_ROOT'  uuid: 28fb0ae0-9cd2-4808-a81c-6cd43123018f
	Total devices 1 FS bytes used 3.55GB
	devid    1 size 46.74GB used 5.27GB path /dev/sda5

Btrfs Btrfs v0.19

root@PRECISE-G64:~# nice -n 15 `btrfs filesystem balance /` &
[1] 2685

root@PRECISE-G64:~# nice: Mit einer Priorität muss ein Befehl angegeben werden
„nice --help“ gibt weitere Informationen.

[1]+  Exit 125                nice -n 15 `btrfs filesystem balance /`

root@PRECISE-G64:~# 

Der btrfs-Befehl wurde aber richtig abgearbeitet - frag' nicht wieso!

Terminal 2 :

Auszug während Terminal 1 arbeitet:

laura@PRECISE-G64:~$ top

 
 2686 root      20   0  8716  408  308 D   24  0.0   0:12.85 btrfs              
 2690 root      20   0     0    0    0 S   21  0.0   0:03.79 btrfs-endio-3      
 2486 root      20   0     0    0    0 R    9  0.0   0:01.35 btrfs-endio-wri    
 2789 root      20   0     0    0    0 S    8  0.0   0:00.24 btrfs-endio-4      
 2689 root      20   0     0    0    0 S    8  0.0   0:00.41 btrfs-endio-2      
 2500 root      20   0     0    0    0 S    6  0.0   0:04.32 btrfs-endio-3      
 1594 root      20   0     0    0    0 S    5  0.0   0:01.75 flush-btrfs-1      
 2691 root      20   0     0    0    0 S    4  0.0   0:00.94 btrfs-endio-wri    
 2510 root      20   0     0    0    0 S    3  0.0   0:00.41 btrfs-worker-4     
 2509 root      20   0     0    0    0 S    3  0.0   0:00.42 btrfs-worker-3     
 2688 root      20   0     0    0    0 S    2  0.0   0:00.80 btrfs-endio-wri    
 2287 root      20   0     0    0    0 R    2  0.0   0:01.60 btrfs-endio-wri    
  303 root      20   0     0    0    0 S    1  0.0   0:00.92 btrfs-worker-1     
 1597 root      20   0     0    0    0 S    1  0.0   0:02.65 btrfs-delalloc-    
 2474 root      20   0     0    0    0 S    1  0.0   0:00.31 btrfs-worker-2     
  305 root      20   0     0    0    0 S    1  0.0   0:00.43 btrfs-submit-1 

Terminal 1 :

Das Gleiche mal ohne die ( ` ):

root@PRECISE-G64:~# nice -n 15 btrfs filesystem balance / &
[1] 3045
root@PRECISE-G64:~#

[1]   Fertig                  nice -n 15 btrfs filesystem balance /
root@PRECISE-G64:~#

Der Auszug während Terminal 1 arbeitet, ist vom Inhalt mit dem Obigen vergleichbar.

Terminal 1 :

Den Auftrag nun mit cpulimit und in der varierten Fassung:

root@PRECISE-G64:~# btrfs filesystem balance / & cpulimit -p $! -l 20 &
[1] 3389
[2] 3390
root@PRECISE-G64:~# Process 3389 detected

root@PRECISE-G64:~# Process 3389 dead!

[1]-  Fertig                  btrfs filesystem balance /
[2]+  Exit 2                  cpulimit -p $! -l 20
root@PRECISE-G64:~# 

Wenn die Zeile mit dead kommt, wird angezeigt, dass der Auftrag abgearbeitet wurde und muss mit ⏎ bestätigt werden, was dann die letzten Info's auspuckt.

Der Auszug während Terminal 1 arbeitet, ist vom Inhalt mit dem Obigen vergleichbar.

Mit diesen Daten habe ich diesen Abschnitt im WIKI korrigiert - ich hoffe es findet Deine Zustimmung.

syscon-hh schrieb:

Der btrfs-Befehl wurde aber richtig abgearbeitet - frag' nicht wieso!

Das überrascht mich nicht. Der btrfs-Befehl wird ja (bei der Variante mit `) direkt von der Shell gestartet. Das ist das gleiche wie wenn man einfach nur

btrfs filesystem balance /

aufruft. Nur die Ausgabe dieses Befehls wird mit den ` besonders behandelt. Danach wurde also nice -n 15 & aufgerufen. Nur dieser Befehl hatte dann einen Fehler, den es nicht behandeln konnte, nämlich, dass ein aufzurufendes Kommando fehlte. Besser sichtbar wird das vielleicht, wenn man den Befehl etwas aufdröselt:

btrfs_ausgabe=`btrfs filesystem balance /`
nice -n 15 $btrfs_ausgabe &

Beschrieben wird das auch unter Shell/Bash-Skripting-Guide für Anfänger (Abschnitt „Ausgaben-in-eine-Variable-schreiben“).

Auszug während Terminal 1 arbeitet:

laura@PRECISE-G64:~$ top

 
 2686 root      20   0  8716  408  308 D   24  0.0   0:12.85 btrfs              

Nice-Wert 0 (Standard) statt 15.

Das Gleiche mal ohne die ( ` ):

root@PRECISE-G64:~# nice -n 15 btrfs filesystem balance / &
[1] 3045
root@PRECISE-G64:~#

[1]   Fertig                  nice -n 15 btrfs filesystem balance /
root@PRECISE-G64:~#

Der Auszug während Terminal 1 arbeitet, ist vom Inhalt mit dem Obigen vergleichbar.

top müsste eigentlich einen nice-Wert von 15 anzeigen. Das kann ich so natürlich nicht überprüfen, aber ich denke, das sollte geklappt haben (gerade noch mal mit sleep statt btrfs überprüft).

Mit diesen Daten habe ich diesen Abschnitt im WIKI korrigiert - ich hoffe es findet Deine Zustimmung.

In Ordnung. Ich passe noch ein paar Kleinigkeiten an die Wiki-Gepflogenheiten an, aber das sieht schon gut aus.

👍

Grüße, Data

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

1

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.

1
2
3
4

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:

1
2
3
4

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

1
2

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:

1
2
3
4
5

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

1
2

cd /mnt/b-snap
btrfs sub list .

Warten, bis btrfs-cleaner den ganzen Müll gelöscht hat

1

watch df -h . 

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!

1

btrfs bal start . 

In einem anderen Terminal

1

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:

1
2
3

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:

1

brtrfs fi df .

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:

1
2

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!

Hallo in die Runde,

ich bin eben über mehrere Meldungen gestolpert, dass BTRFS nicht in einem RAID5/6-Verbund betrieben werden soll.

z. B. https://btrfs.wiki.kernel.org/index.php/RAID56

"Parity may be inconsistent after a crash (the "write hole")"

Diese Einschränkung sollte vielleicht in den Abschnitt zu RAID im Wiki aufgenommen werden.

Grüße

Rai