Du bist nicht angemeldet.

#26 12.11.2017 21:56:10

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

Hi GerBra,
also ich habe auch noch weiter getestet aber letztendlich bin ich weit von Deinem Skil entfernt und hab dann aufgegeben. Nun habe ich halt die SSDs rausgeschmissen und habe jetzt erstmal ein BTRFS RAID mit den zwei HDDs. Das andere Konzept hat mich jetzt doch ein wenig überfordert.
Ich muss jetzt erstmal Deinen letzten Beitrag genau studieren :-) Das ist doch ne Menge Holz. Auf jedenfall freut es mich dann doch das Du aus der ganzen Sache auch einiges an Erfahrungen sammeln konntest und einiges feststellen konntest. Ich dachte mitten drin schon was hab ich bloß für ein Fass aufgemacht :-)

Wenn Du schreibst das Du im Maintancane Mode von Hand "degraded" mountest, kannst Du danach dann wieder auch die grafische Oberfläche starten? Oder hast Du halt "nur" Zugriff wieder auf die Platte?
Also ich werde bei Zeit auch mal bißle weitertesten in der Virtualbox. Nur bin ich jetzt entspannter da mein Hauptsystem wieder läuft und jetzt doch nicht ganz so komplex ist. Wenn Du neue Erkenntnisse hast wäre es ja Klasse wenn Du bei dem Post hier weiterschreibst. Dann bekomme ich es mit oder Andere die auch noch evtl. mitlesen.

Zu meinem System das ich jetzt aufgesetzt habe auf meiner Hardware: Da bin ich jetzt auch schier gestorben. Ich habe es genau so eingerichtet wie in VB. Dann aber klappte es wieder nicht. Beim Ausfall einer Platte landete ich immer im Maintanance Mode.
Dann habe ich doch eine Kleinigkeit festgestellt die ich jetzt doch anders gemacht habe. Ich habe hier jetzt auch noch meine 10TB Platte unter /mnt/xfs/ über die FSTAB gemountet beim Start. Das ist das Problem. Wenn ich diese Platte automatisch beim Start mounten lasse klappt ein sauberer Boot beim Ausfall einer Platte nicht mehr. Jetzt mounte ich die Platte von Hand nach der Anmeldung an der grafischen Oberfläche und nun klappt es wunderbar. Beim Ausfall einer Platte bootet mein BTRFS RAID sauber weiter in die grafische Oberfläche.

Hast Du dazu auch eine Idee? Muss ich irgendwelche Mountoptionen anders machen in der FSTAB? Und warum hat die Platte den überhaupt eine Abhängigkeit zu dem BTRFS RAID? Wenn ich sie automatisch mounten lasse und eine Platte ausstecke habe ich das gleiche Verhalten wie schon so oft. Es kommen die 1:30 Minuten wo genau auf diese Platte gewartet wird (sdc1), danach lande ich im Maintanance Mode.

Offline

#27 13.11.2017 10:56:40

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

mabox schrieb:

Wenn Du schreibst das Du im Maintancane Mode von Hand "degraded" mountest, kannst Du danach dann wieder auch die grafische Oberfläche starten? Oder hast Du halt "nur" Zugriff wieder auf die Platte?

Ich habe in meiner Virtualbox keine graphische Oberfläche, boote also immer nur bis zu den TTY-Loginshells. Allerdings würde das Graphic-Target mit Sicherheit genauso starten, da ja alle notwenigen Daten vorhanden sind.
D.h.  - wenn im degraded-Status nicht automatisch gemountet/gestartet würde - ich also in der maintance Shell lande und dort "Handarbeit" verrichten müßte, dann reicht ein exit bzw. STRG-D um diese Shell/Modus zu verlassen. Das System versucht dann den normalen Bootprozess einfach weiter zu machen, also die normalen Logindienste und eben auch die graphische Umgebung.

XFS-Platte

mabox schrieb:

Hast Du dazu auch eine Idee? Muss ich irgendwelche Mountoptionen anders machen in der FSTAB? Und warum hat die Platte den überhaupt eine Abhängigkeit zu dem BTRFS RAID? Wenn ich sie automatisch mounten lasse und eine Platte ausstecke habe ich das gleiche Verhalten wie schon so oft. Es kommen die 1:30 Minuten wo genau auf diese Platte gewartet wird (sdc1), danach lande ich im Maintanance Mode.

Durch das Entfernen einer Platte (umgekehrt beim Zufügen von zusätzlichen) verschieben sich die Devices aus Sicht des Kernel natürlich (technisch bedingt). Z.B.: sda/sdb sind dein Btrfs-raid, sdc die XFS. Wenn du die 2. Platte(sdb) nun (simuliert) rausnimmst vorm Booten, dann ist aus Systemsicht ehemals sdc nun sdb. Das btrfs-Raid stört das nicht, da beim Start "btrfs device scan" dafür sorgt, daß btrfs-(raid) nur Devices berücksichtigt die auch btrfs als FS haben - sich also für diese sdb(mit xfs) nicht interessiert.
Allerdings in der fstab-Phase hat das System ein Problem: sdc gibt es momentan nicht (mehr), sdc ist sdb. Deshalb der Fehler.
Hier wäre es also absolut sinnvoll, das Mounten *nicht* über den Devicebezeichner (/dev/sdXY) zu machen, sondern über das LABEL/Name oder die UUID. Label/Name muß man meist beim Erstellen des FS angeben, manche Dateisysteme erlauben auch ein nachträgliches Setzen eines Namens. Label/Name sind verarbeitungsmäßig halt eher "für Menschen" gemacht, die UUIDs eher für Maschinen ;-)
Beides (Label und UUIDs) kriegst du (als root) mit den Befehlen:
# blkid
bzw.
# lsblk -f
raus. Die fstab dann für sdc1 halt anpassen mit LABEL= bzw. UUID= anstatt des /dev/sdc1. Dann sollte/ist dem System "egal" ob dieses Device intern momentan nun sdb oder sdc ist - über Label oder UUID wird auf jedenfall das richtige Device gefunden.
Damit solltest du beim Ausfalltest für btrfs-raid über diese Hürde(1:30 Min.) hinwegkommen.

#28 14.11.2017 06:12:41

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

GerBra(offline) schrieb:

Die fstab dann für sdc1 halt anpassen mit LABEL= bzw. UUID= anstatt des /dev/sdc1. Dann sollte/ist dem System "egal" ob dieses Device intern momentan nun sdb oder sdc ist - über Label oder UUID wird auf jedenfall das richtige Device gefunden.
Damit solltest du beim Ausfalltest für btrfs-raid über diese Hürde(1:30 Min.) hinwegkommen.

Perfekt, da hätte ich auch drauf kommen können, funktioniert.
Vielen Dank.

Offline

#29 14.11.2017 16:42:07

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

Au Mann GerBra.
Mein erster Test gestern mit der ersten Festplatte ziehen hat geklappt nach dem ich sdc1 über die UUID in der FSTAB eingetragen habe.
Dann wurde ich unterbrochen bis jetzt und konnte die zweite Platte nicht mehr testen. Das hab ich jetzt nachgeholt und es geht nicht :-(
Beim booten der Platte bekomme ich einen Fehler.

BTRFS Error (device sda2): parent transid verify failed on 59455.... wanted 3527 found ....
ERROR: Root device mounted successfully, but /sbin/init doe not exist.
Bailing out, you are on your own. Good luck.

Dann lande ich in der shell. Was könnte das jetzt wieder sein? Kann es sein das ich zwischen den Tests ein btrfs balance start / machen muss?

Offline

#30 14.11.2017 20:18:05

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

mabox schrieb:
BTRFS Error (device sda2): parent transid verify failed on 59455.... wanted 3527 found ....
ERROR: Root device mounted successfully, but /sbin/init doe not exist.
Bailing out, you are on your own. Good luck.

Dann lande ich in der shell. Was könnte das jetzt wieder sein? Kann es sein das ich zwischen den Tests ein btrfs balance start / machen muss?

Das beheben des 1. (produzierten) Fehlers wäre sicher das bessere gewesen. Ich vermute zwischen beiden Tests haben sich beide btrfs-Platten schon mal wieder als raid1 gesehen? Also:
a) 1. Platte weg, bootet
b) 1. Platte wieder angesteckt, gebootet, bootet
c) unterbrochen worden
d) Test mit 2. Platte weg führt zu dem Fehler ?

Dann wäre die Meldung erklärbar:
Im Datenblock/Sektor der 1. HD (59455...) wird (Checksumme,Journal) Daten mit der Generation 3527 erwartet, aber nur die Generation/Version gefunden die hinter found... noch angezeigt wird.
(Das root-Device wird dann scheinbar trotzdem (degraded) gemountet, aber die Dateisystemstruktur scheint inkonsistenter zu sein als ich es an diesem Punkt erwartet hätte. Da zumindest /sbin/init nicht mehr gefunden wird, ggf. noch weiter Dateien die zum Boot nötig sind, kommt du in die emergency shell)
Vermutung wäre: Nach oben b) haben sich Metadaten(-Teile) schon angefangen zu synchronisieren (sdb2 hatte neuere Daten als sda2). Da du aber kein balance gestartet hast eben nur teilweise. Jetzt ziehst du sdb2 ab und sda2 fällt auf die Schnauze da Metadaten und Daten nicht zueinanderpassen, d.h. zu versuchst von einer nur teilsynchroniserten Platte degraded zu booten. Ungetestet.

Abhilfe in deinem Fall sollte eigentlich sein: einfach die 2. Platte wieder hinzufügen, die ist ja nicht real defekt, und das Raid wieder synchron kriegen.
Ich habe zwischen Tests eigentlich immer "balance" gestartet, da man ja durch Boot-, Journal- und Konsolen-Meldungen doch auf Probleme hingewiesen wird.
Gradmesser für ein notwendiges Balance sind für mich (bei den Tests mit raid1) eigentlich immer:
a) wenn "btrfs file show" nicht für alle Raiddevices den gleichen Wert für "size" und/oder "used" anzeigen (was sie bei raid1 aus 2 Devices tun sollen)
b) wenn bei "btrfs dev usage" bei Data, Metadata,System eben nicht nur Werte für RAID1 angezeigt werden, sondern auch für Single. Genutzer Platz für Single-Data/Metadata/System auf einer Platte heißt bei einem raid1 aus 2 Devices immer: die andere Platte war eine Zeitlang nicht im Raidverbund und das Raid/Filesystem ist nicht synchron.
Ein Scrub-Lauf behebt das AFAIK nicht, es bedarf wirklich eines Balance. In Virtualbox-Testsetup habe ich immer mit Full-Balance gearbeitet, es ist ja ein kleiner Datenbestand.
btrfs balance start --full-balance /
erspart die 10s Abbruchphase ohne die --full-balance Option. Man sollte mit status auch prüfen ob das balance beendet ist.

#31 14.11.2017 21:23:06

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

Hi GerBra,
ja genau so war es eigentlich. Ich hatte kurz wieder mit beiden Platten gebootet und dann die zweite abgesteckt.
btrfs fi show zeigte allerdings keinen Unterschied, jetzt auch noch nicht. Einen Balance hatte ich nicht ausgeführt. Vielleicht sollte ich den jetzt erstmal durchlaufen lassen. Läuft halt glau ich ewig. Es sind mittlerweile über 1 TB Daten drauf :-)
btrfs dev usage / zeigt auch keinen Unterschied.....

Also ich lass mal laufen über Nacht.

EDIT: Noch ne Frage. Wenn das jetzt im schlimmsten Fall so wäre das die noch gesunde Platte nicht bootet weil die beiden davor nicht synchron waren. Gäbe es dennoch eine Möglichkeit zu booten? Vermutlich könnte man lediglich die Platte wo anders einbauen um noch an die Daten zu kommen oder?

Beitrag geändert von mabox (14.11.2017 21:29:22)

Offline

#32 15.11.2017 08:39:46

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

mabox schrieb:

btrfs fi show zeigte allerdings keinen Unterschied, jetzt auch noch nicht. Einen Balance hatte ich nicht ausgeführt. Vielleicht sollte ich den jetzt erstmal durchlaufen lassen. Läuft halt glau ich ewig. Es sind mittlerweile über 1 TB Daten drauf :-)
btrfs dev usage / zeigt auch keinen Unterschied.....

Also ich lass mal laufen über Nacht.

Full-Balance dauert halt seine Zeit (dehalb auch die "Warnung mit dem Countdown" am Anfang, ob man wirklich fullbalance starten will. Die Balance-Art kann man ja (man page btrfs-balance) durch Profile und andere Optionen gezielter steuern. Ich kann aber leider aus Erfahrung nicht sagen, ob eine (zeitlich dann kürzere) andere Art in diesem Fall ausreichend wäre. Da will ich auch noch mal in Virtualbox weitertesten. Aus diesem Grund habe ich für die Tests halt auch einen kleinen/minimalen Datenbestand, so daß das in Minuten erledigt ist.

Ein scrub-Lauf (und balance dauert AFAIK länger) auf meinem 2TB-Raid1 dauert rund zweieinhalb Stunden.

mabox schrieb:

EDIT: Noch ne Frage. Wenn das jetzt im schlimmsten Fall so wäre das die noch gesunde Platte nicht bootet weil die beiden davor nicht synchron waren. Gäbe es dennoch eine Möglichkeit zu booten? Vermutlich könnte man lediglich die Platte wo anders einbauen um noch an die Daten zu kommen oder?

Du meinst, wenn man gezwungen wäre mit dieser sda2 (1.Platte, teilsynchron zu sdb2) zu arbeiten, da die 2. Platte (mit dem eigentlich aktuellen Datenbestand, Murphy!!) plötzlich ganz hinüber wäre? Hmm,...
a) In der emercecy shell müßte das btrfs Programm auch funktionieren, damit und mit dmesg müßte man sich einen Gesamtüberblick verschaffen. Ebenfalls warum /sbin/init nicht gefunden wird und ob weitere/alle Teile des Dateisystems betroffen wären.
b) Den PC mit z.B. dem Arch-ISO booten und sich die Situation unter einem "richtigen" System statt emercecy Shell anschauen.
Ein Filesystem-Check (fsck.btrfs) sollte laut Doku zumindest mit der --repair-Option eigentlich nur das letzte Mittel sein.
Ich würde vorher (ohne weitere Infos) eher die Wege versuchen:
0. btrfs check ggf. für Infos im --readonly Mode, bzw. ohne "dangerous options"
1. Log/Journal löschen lassen
2. scrub-Lauf
3. Das ("kaputte") Raid1 ggf. auflösen und die Platte zu einer Single-Platte konvertieren lassen
Je nach Zustand die "Reihenfolge" verschieben.

Das BTRFS-Wiki bietet auch einige Tips/Anleitungen für bestimmte Zustände/Fehler, lohnt sich mal durch/anzulesen.
https://btrfs.wiki.kernel.org

#33 15.11.2017 08:49:42

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

GerBra(offline) schrieb:
mabox schrieb:

btrfs fi show zeigte allerdings keinen Unterschied, jetzt auch noch nicht. Einen Balance hatte ich nicht ausgeführt. Vielleicht sollte ich den jetzt erstmal durchlaufen lassen. Läuft halt glau ich ewig. Es sind mittlerweile über 1 TB Daten drauf :-)
btrfs dev usage / zeigt auch keinen Unterschied.....

Also ich lass mal laufen über Nacht.

Full-Balance dauert halt seine Zeit (dehalb auch die "Warnung mit dem Countdown" am Anfang, ob man wirklich fullbalance starten will. Die Balance-Art kann man ja (man page btrfs-balance) durch Profile und andere Optionen gezielter steuern. Ich kann aber leider aus Erfahrung nicht sagen, ob eine (zeitlich dann kürzere) andere Art in diesem Fall ausreichend wäre. Da will ich auch noch mal in Virtualbox weitertesten. Aus diesem Grund habe ich für die Tests halt auch einen kleinen/minimalen Datenbestand, so daß das in Minuten erledigt ist.

Ein scrub-Lauf (und balance dauert AFAIK länger) auf meinem 2TB-Raid1 dauert rund zweieinhalb Stunden.

Ups, ich hab das Balance um 1 Uhr gestartet und es war heute Morgen um 7 bei noch ca. 19% was zu balancen zu scheint sein. Ich habe 2x 3TB Platten als RAID drin.

GerBra(offline) schrieb:
mabox schrieb:

EDIT: Noch ne Frage. Wenn das jetzt im schlimmsten Fall so wäre das die noch gesunde Platte nicht bootet weil die beiden davor nicht synchron waren. Gäbe es dennoch eine Möglichkeit zu booten? Vermutlich könnte man lediglich die Platte wo anders einbauen um noch an die Daten zu kommen oder?

Du meinst, wenn man gezwungen wäre mit dieser sda2 (1.Platte, teilsynchron zu sdb2) zu arbeiten, da die 2. Platte (mit dem eigentlich aktuellen Datenbestand, Murphy!!) plötzlich ganz hinüber wäre? Hmm,...
a) In der emercecy shell müßte das btrfs Programm auch funktionieren, damit und mit dmesg müßte man sich einen Gesamtüberblick verschaffen. Ebenfalls warum /sbin/init nicht gefunden wird und ob weitere/alle Teile des Dateisystems betroffen wären.
b) Den PC mit z.B. dem Arch-ISO booten und sich die Situation unter einem "richtigen" System statt emercecy Shell anschauen.
Ein Filesystem-Check (fsck.btrfs) sollte laut Doku zumindest mit der --repair-Option eigentlich nur das letzte Mittel sein.
Ich würde vorher (ohne weitere Infos) eher die Wege versuchen:
0. btrfs check ggf. für Infos im --readonly Mode, bzw. ohne "dangerous options"
1. Log/Journal löschen lassen
2. scrub-Lauf
3. Das ("kaputte") Raid1 ggf. auflösen und die Platte zu einer Single-Platte konvertieren lassen
Je nach Zustand die "Reihenfolge" verschieben.

Das BTRFS-Wiki bietet auch einige Tips/Anleitungen für bestimmte Zustände/Fehler, lohnt sich mal durch/anzulesen.
https://btrfs.wiki.kernel.org

Also bei dem Problem lande ich  noch nichtmal in der Emergency Shell oder Maintanance Mode. Ich bin da in einer anderen Shell gleich ganz am Anfang sofort nach dem Bootloader. Keine Ahnung wie man die nennt und ich glaub da konnte ich gar nicht soviel machen. Hatte es mir aber nicht genauer angeschaut. Ich denke aber über die Live-Iso müsste man sich helfen können, stimmt.

Offline

#34 15.11.2017 18:10:56

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

Hi GerBra,
also nun hat nach dem Balance auch das booten von der anderen Platte geklappt. Es hagelte jede Menge BTRFS Fehler aber es bootete. Danach war das Filesystem aber nur read only. Nach einem erneuten Boot läuft hat aber alles wunderbar geklappt. Ich lass dann heute Nacht gleich wieder einen Balance laufen.

Schöne Grüße
mabox


EDIT: Ok zu früh gefreut. Auch nach dem Reboot bleibt eine der beiden Platten read only. Mach ich einen umouunt von einem Subvolume und versuche es wieder zu mounten bekomme ich einen Fehler. "Falscher Dateisystemtyp, ungültige Option, der Superblock von /dev/sdb2 ist beschädigt, fehlende Kodierungseite oder ein anderer Fehler"

Au Mann. Es wäre jetzt mein letzter Test gewesen, dann hätte ich das Kapitel mal abgeschlossen.

EDIT: Ok, Ui Ui Ui, nach einem erneuten Reboot passt jetzt doch wieder alles.

Beitrag geändert von mabox (15.11.2017 18:22:25)

Offline

#35 16.11.2017 12:44:00

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

mabox schrieb:

Hi GerBra,
also nun hat nach dem Balance auch das booten von der anderen Platte geklappt. Es hagelte jede Menge BTRFS Fehler aber es bootete. Danach war das Filesystem aber nur read only. Nach einem erneuten Boot läuft hat aber alles wunderbar geklappt. Ich lass dann heute Nacht gleich wieder einen Balance laufen.

Na, dann hast du ja jetzt eine Zeitangabe, wie lange (Full-)Balance für dein Setup braucht ;-)
Nochmal Obacht: Balance ist eigentlich nur notwendig, wenn es wirklich was zu Blancieren gibt, es ist nicht das Standard-"Reperatur-"/Wartungs-Werkzeug für btrfs. S.u.

mabox schrieb:

EDIT: Ok zu früh gefreut. Auch nach dem Reboot bleibt eine der beiden Platten read only.
EDIT: Ok, Ui Ui Ui, nach einem erneuten Reboot passt jetzt doch wieder alles.

Zum 1.Edit: "Eine der beiden Platten read only" verstehe ich nicht, meinst du das ganze Raid? Sollte nicht sein...
Zum 2.Edit: "Reboot tut immer gut" - alter Windowslehrsatz....

Nochmal zum Punkt Test und Balance. Ich teste immer noch im obigen Virtualbox-Setup (2xSSD, 2xHDD, 2 btrfs-Volumes).
Ich ziehe für vol_tank vorm boot die hdd1 ab, mounte per Hand vol_tank nach /mnt/tank, und kopiere ein paar Daten hinzu:

# btrfs file file show
Label: 'vol_root'  uuid: 3a3f5672-8035-4771-a326-2c53538d3142
	Total devices 2 FS bytes used 1.28GiB
	devid    1 size 8.00GiB used 2.28GiB path /dev/sda1
	devid    2 size 8.00GiB used 2.28GiB path /dev/sdb1

Label: 'vol_tank'  uuid: c5ad18ea-79a9-4800-90cf-f58c4ae95fe9
	Total devices 2 FS bytes used 242.79MiB
	devid    2 size 8.00GiB used 2.38GiB path /dev/sdc1
	*** Some devices missing

(Also bei vol_tank fehlt devid 1, somit ist es faktisch kein Raid1 (mehr))

# btrfs dev usage /mnt/tank
/dev/sdc1, ID: 2
   Device size:             8.00GiB
   Device slack:            3.50KiB
   Data,single:           832.00MiB
   Data,RAID1:              1.00GiB
   Metadata,single:       256.00MiB
   Metadata,RAID1:        256.00MiB
   System,single:          32.00MiB
   System,RAID1:           32.00MiB
   Unallocated:             5.62GiB

missing, ID: 1
   Device size:               0.00B
   Device slack:              0.00B
   Data,RAID1:              1.00GiB
   Metadata,RAID1:        256.00MiB
   System,RAID1:           32.00MiB
   Unallocated:             6.72GiB

(Hier sieht man deutlich: Das btrfs agiert als Single-Device (für Daten wo überall single hinter Data,Metadata,System steht).

# btrfs dev stats /mnt/tank
[devid:1].write_io_errs    0
[devid:1].read_io_errs     0
[devid:1].flush_io_errs    0
[devid:1].corruption_errs  1041
[devid:1].generation_errs  2
[/dev/sdc1].write_io_errs    0
[/dev/sdc1].read_io_errs     0
[/dev/sdc1].flush_io_errs    0
[/dev/sdc1].corruption_errs  0
[/dev/sdc1].generation_errs  0

( Für das entfernte Device 1 hätten sich in der Fehlerstatistik nun bereits etliche Fehler(chunks) ergeben.)

Ich fahre das System runter, hänge die hdd1 wieder an ihren Platz. Das System bootet und mountet vol_tank -> /mnt/tank automatisch. Der Status nun ist:

# btrfs file file show
Label: 'vol_tank'  uuid: c5ad18ea-79a9-4800-90cf-f58c4ae95fe9
	Total devices 2 FS bytes used 242.79MiB
	devid    1 size 8.00GiB used 1.28GiB path /dev/sdc1
	devid    2 size 8.00GiB used 2.38GiB path /dev/sdd1

(Hier nun der erste Hinweis: used bei beiden Devices ist nicht (mehr) gleich was bei raid1 eigentlich sein muß.)

# btrfs dev usage /mnt/tank
/dev/sdc1, ID: 1
   Device size:             8.00GiB
   Device slack:            3.50KiB
   Data,RAID1:              1.00GiB
   Metadata,RAID1:        256.00MiB
   System,RAID1:           32.00MiB
   Unallocated:             6.72GiB

/dev/sdd1, ID: 2
   Device size:             8.00GiB
   Device slack:            3.50KiB
   Data,single:           832.00MiB
   Data,RAID1:              1.00GiB
   Metadata,single:       256.00MiB
   Metadata,RAID1:        256.00MiB
   System,single:          32.00MiB
   System,RAID1:           32.00MiB
   Unallocated:             5.62GiB

(Hier ebefalls der definitive Hinweis, das Balance notwendig ist: sdd1, ID2 hat/hält die Daten, die eigentlich dem momentan gemouteten Datenbestand entsprechen - aber halt im Single-Mode, d.h. asynchron zum Raid1 mit sdc1, ID1 (die ja "weg" war))

Das ist also für mich der Gradmesser wo ein Balance-Lauf AFAIK zwingend notwendig ist um diese Single- vs. Raid1 Inkonsistenz aufzulösen. Das passiert nicht automatisch.

Also lasse ich ein: btrfs balance start --full-balance /mnt/tank los. Danach sehen die Werte dann so aus:

# btrfs file file show
Label: 'vol_tank'  uuid: c5ad18ea-79a9-4800-90cf-f58c4ae95fe9
	Total devices 2 FS bytes used 242.55MiB
	devid    1 size 8.00GiB used 1.28GiB path /dev/sdc1
	devid    2 size 8.00GiB used 1.28GiB path /dev/sdd1

(Also used-Werte wieder identisch, gespiegelt)

# btrfs dev usage /mnt/tank
/dev/sdc1, ID: 1
   Device size:             8.00GiB
   Device slack:            3.50KiB
   Data,RAID1:              1.00GiB
   Metadata,RAID1:        256.00MiB
   System,RAID1:           32.00MiB
   Unallocated:             6.72GiB

/dev/sdd1, ID: 2
   Device size:             8.00GiB
   Device slack:            3.50KiB
   Data,RAID1:              1.00GiB
   Metadata,RAID1:        256.00MiB
   System,RAID1:           32.00MiB
   Unallocated:             6.72GiB

("Single" Daten sind weg, Raid1 ist wieder synchron)

Sicherheitshalber lasse ich nochmal über das Dateisystem ein scrub laufen. Vorher lösche ich noch die Fehlerstatistik für vol_tank, da ich nach dem Balance eigentlich keine (neuen) Fehler mehr erwarte:

# btrfs dev stats -z /mnt/tank
[/dev/sdc1].write_io_errs    0
[/dev/sdc1].read_io_errs     0
[/dev/sdc1].flush_io_errs    0
[/dev/sdc1].corruption_errs  1041
[/dev/sdc1].generation_errs  2
[/dev/sdd1].write_io_errs    0
[/dev/sdd1].read_io_errs     0
[/dev/sdd1].flush_io_errs    0
[/dev/sdd1].corruption_errs  0
[/dev/sdd1].generation_errs  0

Der scrub-Lauf endet ohne weitere Fehler, die Statistik bleibt auf 0.
Das wäre jetzt der Punkt, an dem ich meinem Raid1 "wieder trauen" würde.

Also:
a) Balance als Reperatur-Werkzeug nur, wenn es auch was zu balancieren gibt.

b) Scrub reicht ansonsten aus, um ein intaktes btrfs-Raid1 zu prüfen und zu reparieren. Hier werden v.a. die Checksummen geprüft und - da greift dann der Vorteil von raid1 - eventuelle "korrupte" Daten anhand der korrekten Version vom jeweils anderen Device wieder synchronisiert (wenn möglich). Nach deinem erfolgreichen 1.Balance-Lauf hätte also ein Scrubbing vollkommen ausgereicht.
Scrub sollte man sowieso periodisch laufen lassen, das btrfs-Wiki empfiehlt einmal im Monat. Bei mir lasse ich es alle 2 Wochen laufen, da meine beiden HDs auch schon "überfällig" für Ausfälle sind. (Wiki auf archlinux.org für btrfs zeigt wie das mit systemd geht, mir persönlich sind cronjobs vertrauter)
Scrub hält also Dateisystem (und "Raid") in Ordnung, und zeigt auch aufgetretene Hardware-Probleme an

c) Die Fehlerstatistik sollte man auch periodisch prüfen, ich teste per cronjob alle Stunde ob Fehlerwerte auftreten:

/usr/bin/btrfs device stats /mnt/tank | grep -vE ' 0$'

Das grep sorgt dafür, daß nur Zeilen mit Wert ungleich 0 als Ergebniss kämen, über dieses evtuelle Ergebniss würde ich dann informiert.
Nach jeder "Reparatur" aufgrund von Fehlern sollte die Statistik logischerweise wieder zurückgesetzt werden.

d) Für ein Raid1 im "Heimbereich" bietet sich ein periodischer Smart-Test der beteiligten Platten ebenfalls an. (pacman -Si smartmontools). Ich lasse für meine HDs täglich einen Short-Test und wöchentlich einen Long-Test laufen.

Die notwendigen Laufzeiten der periodischen Prüfungen (scrub, smartctl, etc.) sind auf einem 24h bzw. dauerhaft/länger laufendem System ("Server") natürlich einfacher zu bewerkstelligen als bei einer "Workstation", auch die eigentlichen Vorteile von btrfs-raid greifen IMHO nur da. Man sollte diese Zeit für Tests/Wartung halt verfügbar machen.

Bei einer "Workstation", die ich ggf. 2-3 mal am Tag boote bzw. suspende, da würde ich persönlich wohl eher nicht auf Raid1 setzen wollen, bzw. ich sehe viele der eigentlichen Vorteile da flöten gehen (speziell auch was btrfs-raid betrifft). Ein "Grund": Festplatten geben nach meiner Erfahrung gerade immer beim/nach Einschalten/Anlaufen ihren Geist auf - mit 2 HDs im raid1 potenziere ich diese "Gefahr". Ich würde mir wahrscheinlich eher die 2. HD entweder extern bzw. eben nicht dauerhaft angeschlossen von Zeit zu Zeit "spiegeln/rsyn'en/etc." um beim Ausfall der einen die zweite aktivieren zu können. Also eher als "Backup" zu haben anstatt "Ausfallsicherheit" bei einer Workstation (die mir ausfallsicher nichts "liefern/servieren" müßte). Aber das sind eher "my 2 ct's...".

#36 16.11.2017 16:49:47

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

Hi GerBra,
klasse, vielen Dank für die Tipps. Bei mir sieht jetzt alles gut aus. Dann muss ich mir mal mein Konzept in der Richtung Dateisystempflege einfallen lassen.
Mein "Server" hier läuft auf jedenfall 24x7.

Eine Frage noch zu dem Balance-Befehl. Ich habe hier ein Script das am Ende von einem pacman -Syu immer noch folgendes ausführt "BTRFS balance -dusage=5 /btrfs". Also auf alle Subvolumes die ich auf dem Pfad gemountet habe. Ich habe vor das Script vielleicht einmal die Woche ausführen zu lassen. Wenn ich es richtig verstehe handelt es sich bei dem Befehl ja nicht um ein Full Balance. Den Full sollte ich ja nur ausführen wenn nötig. Der Befehl von oben schadet aber nicht einmal die Woche oder? Ich weiß leider noch nicht genau was der macht

Wegen dem read only von vorhin. Es waren nur ein paar Subvolumes read only, nicht alle und auch nicht die vom System aber wie gesagt nach dem erneuten Rebot ist jetzt alles gut.

Offline

#37 16.11.2017 20:00:38

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

mabox schrieb:

Eine Frage noch zu dem Balance-Befehl. Ich habe hier ein Script das am Ende von einem pacman -Syu immer noch folgendes ausführt "BTRFS balance -dusage=5 /btrfs". Also auf alle Subvolumes die ich auf dem Pfad gemountet habe. Ich habe vor das Script vielleicht einmal die Woche ausführen zu lassen. Wenn ich es richtig verstehe handelt es sich bei dem Befehl ja nicht um ein Full Balance. Den Full sollte ich ja nur ausführen wenn nötig. Der Befehl von oben schadet aber nicht einmal die Woche oder? Ich weiß leider noch nicht genau was der macht

<"BTRFS balance -dusage=5 /btrfs". Also auf alle Subvolumes die ich auf dem Pfad gemountet habe>
Du kannst eigentlich keine btrfs-Aktion (wie balance) "nur" auf ein Subvolume anwenden, diese agieren immer auf der kompletten Volumegroup. Subvolumes haben nichts mit einer Art Device/Partition/LVM-LogicalVolume o.ä. zu tun. Am ehesten noch mit "Namensräumen", der einzige Nutzen von subvolumes bei btrfs ist IMHO die Snapshot-Funktionalität. ZFS bietet da ein anderes Handling für seine Subvolumes, dort ist z.B. recht einfach zu erfahren wieviel Platz/Dateien in den jeweiligen Subvolumes genutzt werden, btrfs ist das nicht zu entlocken.

<Ich weiß leider noch nicht genau was der macht>
Einen Wert von 5% halte ich jetzt für einen nahezu sinnlosen Wert für diese Balance-Art (und im Zusammenhang gerade mit pacman). Zumindest soweit ich das Balancing verstanden habe <g>).
Zeige doch mal die Ausgabe von:

btrfs filesystem df -g --si /btrfs

Dann kann ich das anhand deiner Werte etwas versuchen zu erklären, morgen oder am WE.

#38 16.11.2017 20:42:48

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

GerBra(offline) schrieb:

Zeige doch mal die Ausgabe von:

btrfs filesystem df -g --si /btrfs

Dann kann ich das anhand deiner Werte etwas versuchen zu erklären, morgen oder am WE.

Hier die Ausgabe. Wie gesagt das ist ein Script das ich von jemanden habe wo pacman -Syu ausführt, davor noch einen Snapshot macht von / und noch ein paar Dinge. Am Ende auf jedenfall steht dann der balance Befehl von oben. Den würde ich jetzt gerne verstehen und falls er keinen Sinn macht dann halt entfernen. Evtl. ersetzen mit einem Scrub Befehl den ich ja lt. Deinen Infos sowieso öfters ausführen sollte.....

[root@arch ~]# btrfs fi df -g --si /btrfs
Data, RAID1: total=1243.39GB, used=1242.90GB
System, RAID1: total=0.03GB, used=0.00GB
Metadata, RAID1: total=3.22GB, used=1.95GB
GlobalReserve, single: total=0.54GB, used=0.00GB
[root@arch ~]# ll /btrfs
insgesamt 16
drwxr-xr-x 1 root root    138 12. Nov 15:21  ./
drwxr-xr-x 1 root root    160 12. Nov 15:54  ../
drwxr-xr-x 1 root root    160 12. Nov 15:54 '@'/
drwxr-xr-x 1 root root     32 12. Nov 16:46 '@home'/
drwxr-xr-x 1 root root  57596 16. Nov 18:55 '@pkg'/
drwxr-xr-x 1 root root     44 14. Nov 18:40 '@snapshots'/

Offline

#39 17.11.2017 14:29:39

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

mabox schrieb:

Wie gesagt das ist ein Script das ich von jemanden habe wo pacman -Syu ausführt, davor noch einen Snapshot macht von / und noch ein paar Dinge. Am Ende auf jedenfall steht dann der balance Befehl von oben.

Es geht also um dieses Befehl:

btrfs balance start -dusage=5 /btrfs

mabox schrieb:

Den würde ich jetzt gerne verstehen und falls er keinen Sinn macht dann halt entfernen

[root@arch ~]# btrfs fi df -g --si /btrfs
Data, RAID1: total=1243.39GB, used=1242.90GB
System, RAID1: total=0.03GB, used=0.00GB
Metadata, RAID1: total=3.22GB, used=1.95GB
GlobalReserve, single: total=0.54GB, used=0.00GB

Dann versuche ich es mal. Vorab:
Speicherplatz wird von der Hardware (und Kernel) auf den Platten in "Blöcken" belegt/angefordert. Jedes Byte von Daten belegt nun mindest einen Block. Speicherplatz kann nun "verschwendet" werden, wenn es viele Daten gibt, die kleiner sind als die genutzte Blockgröße. Im laufenden Betrieb und mit zunehmender Anzahl der schon belegten Blöcke steigt die Wahrscheinlichkeit, daß das passiert. Im allgemeinen wird das als Fragmentierung bezeichnet.

Btrfs organisiert diesen vorgegebenen Speicherplatz (die "Blöcke") nun intern ("low-level") in sogenannten "Chunks". Ein Chunk nutzt immer etliche der Blöcke, laut Doku ist ein Chunk normalerweise eine Größe von 1 GB.
Jeder durch Daten angeforderte neue Chunk erhöht nun immer den obigen "total="-Wert um die Chunk-Größe und vermindert den freien Platz entsprechend (was z.B. bei btrfs file usage <pfad> unter: Free(estimated) angezeigt wird oder mit Einschränkungen bei df -h).

Einschub: Kernel und Dateisysteme unter Unixen sind im allgemeinen sehr intelligent um "Fragmentierung" und interne "Verschwendung" zu vermeiden. Ein lange laufendes ext(3|4)-FS oder auch btrfs "leidet" nach meiner Erfahrung signifikant weniger unter Fragmentierungs-/Verschwendungs-Effekten als früher z.B. die Windows-Dateisysteme (fat,fat32,ntfs), die kurze Zeit nach einer Defragmentierung schon wieder eine erhebliche neue Fragmentierung aufwiesen (zumindest aus Systemsicht).

Wir schauen bei obiger df-Ausgabe nur nach den Werten für Data (System und Metadata lassen wir außen vor), da "Daten" nun mal den Hauptanteil des Speicherplatzes ausmachen.

Data, RAID1: total=1243.39GB, used=1242.90GB

Das heißt: aus dem gesamt verfügbaren Speicherplatz(Blöcke) verwendet das Volume(Pool) durch angefordete Chunks momentan 1243.39 GB (total=). "Optimal" wäre nun, wenn jeder belegte Chunk zu 100% auch durch reale Nutzdaten belegt wäre. Dieses "optimale Verhältniss" wird in der Praxis aber nie vorkommen. Hier zeigt nun der "used=" Wert durch reale Daten("Dateien") 1242.90 GB an.
Das "Verhältniss" von "Chunk-Belegung" zu "Daten-Belegung" ist nun:

1242.90 / 1243.39 = 0,99(gerundet)

Also momentan ein Verhältniss von total zu used von rund 99%, was sehr nahe an den 100% liegt <g>.
Was kann man aus diesem Zustand ableiten?
a) Jeder belegte Chunk ist im Durchschnitt zu 99% auch mit realen Nutzdaten belegt (Verschwendung von 1%)
Das alle belegten Chunks nun mit gerade diesem Durchschnitt belegt sind ist aber praktisch realitätsfern.
b) So ist eher zu erwarten, daß es Chunks gibt die mit weniger als 99% genutzt werden. Aber aus dem Verhältniss sind eher Belegungen in Richtung der 99% zu erwarten als in Richtung 1%. So wird sich hier real eher ergebenen, daß du einige wenige Chunks hast, die ungefähr nur zu 50%-70% bzw. 70%-85% belegt sind.

Weiterhin kann man durch:

1243.39GB(total) - 1242.90GB(used) = 0,49GB

rauslesen:
Durch eine wirklich optimale Nutzung würdest du momentan rund 500MB gewinnen können, der wieder für neue Daten/Snapshots in Btrfs zur Verfügung stände. Da daß aber gerade wohl mal ein "halbes Chunk" ist, wäre der "Gewinn" ... Null.

Und hier ist dann der Punkt wo Balancing als "Wartungstool" (nicht als Reparaturtool, wie wir es früher genutzt haben) ins Spiel kommen könnte:
# btrfs balance start -dusage=X <pfad>
ist ein Balance mit dem Filter auf die benutzten Daten( -d ist Daten/Data aus df oben, usage ist der verwendete Filter). Das ist also ein (wesentlich) eingeschränkter Balance-Lauf als ein full-balance.
Diesere Balance-(Filter)-Lauf würde eine Neuorganisierung der belegten Chunks (teils durch Neuschreiben von Chunks) erreichen mit dem Ziel, belegte Chunks möglichst komplett mit realen Daten zu füllen und somit die teilbelegten wieder frei verfügbar zu kriegen. Würde also versuchen Obiges total= von df oben möglichst nah zum used= zu kriegen, total= also zu vermindern.

Du aktuell würdest wohl (Differenz von ~500MB) nicht mal ein Chunk durch Neuorganisierung freikriegen, dein noch "junges" System zeigt ja, daß du kaum Chunks hast, die mit *wesentlich* weniger als 90% nur belegt sind. Da du den Pool/Volume ja wohl im wesentlichen durch "Kopieren-im-Rutsch-aus-Backup" gefüllt hast, zeigt das auch, daß Btrfs sich selbst um eine möglichst effizente Nutzung der Chunks kümmert.

Dein kompletter Befehl würde nun folgendes anstoßen:
Eine Neuorganisierung von durch Daten(Data) belegten Chunks, die nur zu 5% mit realen Nutzdaten belegt sind. Deine sind - haben wir festgestellt - "durchschnittlich" sogar zu 99% belegt. Wie wahrscheinlich ist es, da auch nur einen Chunk zu finden der "nur" mit bis zu 5% belegt ist? Nahezu Null IMHO...
Deshalb wunderte ich mich über dieses "-usage=5" auch, da ja jedesmal nur die belegten Chunks reorganisert würden die - umgekehrt - zu 95% nicht durch Nutzdaten auch belegt sind. Natürlich kann ein Chunk angefordert/belegt werden, da daß Dateisystem eine Datei(oder Daten) unterbringen muß von nur wenigen Bytes. Allerdings nutzt das System diesen Chunk dann sicher für andere Operationen, sodaß ein wirklich nur mit bis zu 5% belegter Chunk kaum vorkommen dürfte - und sich signifikant auf eine Verringerung von total= auswirken würde.
Ich nehme an - auch im weiteren "Wachsen" des Dateisystems - daß zum Zeitpunkt X du fast immer nur ein Ergebniss von:

reallocated 0 out of YYY chunks

bekommst, oder evtl. 1 bis 3 reorganisierte Chunks von allen. Also eine "Verschwendungsersparniss" von nur rund 0-3 GB. Also ein Wert, der den Zeit-/Ressourcen-Aufwand IMHO nicht rechtfertigt. Und der Zeitpunkt für diesen Befehl (im Zusammenhang nach einem Snapshot und pacman -Syu) macht IMHO aus diesem Blickwinkel noch weniger Sinn/Nutzen.
Wirklich zum Verständniss: -dusage=5 rührt keine Chunks an, die 6% bis 99% belegt sind. Dein Belegungsverhältniss haben wir oben schon analysiert, weit entfernt eine signifikante Anzahl von "5-Percentern" zu finden. Und das wohl auch in Zukunft.

Wann und wie macht ein Balance der Daten - mit dem Ziel, belegte Chunks in freie Chunks zu verwandeln - also Sinn?
Da wäre zum einen, der zu erwartende mögliche "Gewinn", der sich wie oben aus "total=" minus "used=" ungefähr abschätzen läßt. Also eine Ausgabe, die man von Zeit zu Zeit im Auge haben sollte.
Zum anderen spielen die Art der Nutzdaten und auch die Raid-Art eine Rolle. Wenn ich z.B. bei einem Webserver(Host) eine erkleckliche Anzahl von kleinen statischen HTML-Dateien oder Bildern erwarten kann, bei einem News-Server(wie der antike INN) eine erklecklicke Anzahl von kleinen News-Posting-Dateien - dann ist die Wahrscheinlichkeit, das total= von used= im Laufe stärker abweichen wird, also mehr nicht komplett genutzte Chunks auftreten, von Natur aus größer als z.B. bei Videodateien/Filmen. Ebenfalls ist AFAIK ein raid1 aus 2 Devices per se weniger von der Chunk-Verschwendung betroffen als z.B. ein Raid10 mit "drölfzig" Devices.

Ebenfalls wichtig ist eben, daß man bei "-dusage=X" für X einen Prozentwert wählt, der möglichst viele Chunks in die Reorganisierung einbezieht - bei vertretbarem Zeitaufwand (mehr angefaßte Chunks = längere Laufzeit) zum erwarteten Gewinn. Einen gewissen Anhalt kann man ja anhand der obigen Verhältniss-Berechnung ermitteln.
Die Btrfs-Doku nimmt in Beispielen meist 50% als Wert ("Glas halb voll / leer" Empfinden <g>) für einen periodischen Balance-Lauf (periodisch bedeutet aber hier eben nicht nach z.B. dieser pacman-Aktion, genausowenig wie ein Scrub-Lauf explizit danach sinnvoll wäre).

Ich würde dir raten für periodisches Balance:
Behalte die Werte von "btrfs file df" im Auge (das ist Aufgabe eines Administrators), und entscheide, wann im Laufe der Zeit du einen signifikanten Wert an freien Chunks durch eine Reorganisierung erhalten würdest, ergo: wann driften used= und total= weit auseinander. Und mit welchem (Prozent-)Wert sollte ich dann sinnvoll (Zeit/Ressourcen) arbeiten um an diesen "maximalen" erwarteten Zuwachsgewinn heranzukommen.

Kurz also: IMHO macht der Befehl in einem wie immer angelegten (snapshot/pacman)-Szenario keinen Sinn, da nutzlos.
Trotzdem kannst du es ja auch ausprobieren (und wie gesagt: viele Dinge werden erst im Lauf der Zeit, der Nutzung wirklich relevant), indem du:

time btrfs balance start -dusage=5 /btrfs

einfach mal startest. Dann siehst du zum reinen (durch time) die gebrauchte Zeit, und siehst wieviel aktuelle 5%-Chunks überhaupt reorganisiert würden und was es dir für df (total=) bringt.
Ebenfalls denkbar wären Erweiterungen in deinem Skript, die Ergebnisse dieses Balancings mitprotokollieren. Um nach einer Zeit abzuschätzen: werden ausreichend Chunks angefaßt und was ist der Zugewinn, hat sich der Autor dieses Skripts also doch was dabei gedacht oder andere Erfahrungen gemacht, die ich ad hoc nicht sehe. Ich weiß nicht, wie erfahren du im Shell-Skripten bist, ich würde an sowas denken:
Angenommen dein Skript macht auch das pacman -Syu quasi "unbeaufsichtigt", automatisch, was eigentlich IMHO nicht sinnvoll ist. Und es wird als root ausgeführt. Und du solltest noch da Paket time installiert haben (pacman -S time), welche die GNU-Version von time mitbringt.

...
(snapshot Teil)
...
(pacman -Syu Teil)
...
dann der zu untersuchende balance Lauf, den ich einbetten würde in:

echo "=========" >> /root/pacman-balance.log
date >> /root/pacman-balance.log
btrfs filesystem df -g --si /btrfs >> /root/pacman-balance.log
echo "Starte balance..., warten..."
/usr/bin/time -p -o /root/pacman-balance.log -a btrfs balance start -dusage=5 /btrfs >> /root/pacman-balance.log
btrfs filesystem df -g --si /btrfs >> /root/pacman-balance.log
...
(Rest vom Skript)

Diese Änderung führt ein wachsendes Logfile in /root/pacman-balance.log, bei dem vorm Balance ein df protokolliert wird, dann der Balance mit 5% ausgeführt wird, und danach nochmal ein df. Separiert werden die Läufe durch "======" gefolgt vom Datum.
So kannst du beobachten:
a) Wieviele chunks werden in so einer Situation in das Reorganisieren eingezogen? (relocate x out of y chunks)
b) Wieviel Zeit brauchte der Durchlauf?
c) Wieviel freie Chunks / Spiecherplatz hat die Aktion gewonnen? (beide df Ausgaben bei total= vergleichen)
Wenn du das mal eine Zeitlang, Wochen so laufen ließest, dann könnte der Sinn dieses Balancings langfristig belegbar abgeschätzt werden.

Zum Vergleich mal die df Ausgabe von meinem Btrfs-System, was schon einige Jahre läuft, nur als Anhalt:

# btrfs file df -g --si /
Data, RAID1: total=1162.86GB, used=1156.93GB
System, RAID1: total=0.04GB, used=0.00GB
Metadata, RAID1: total=3.22GB, used=1.58GB
GlobalReserve, single: total=0.54GB, used=0.00GB

Durch ein Balancing (was ich noch nie, außer Anfangs-Testphase gemacht habe) würde ich
1162.86 minus 1156.93 = 5,93
also rund 6GB zusätzlichen Platz durch Chunk-Reorganisierung "gewinnen".
Ich werde die Tage hier mal mit 5% und mit realistischeren 50-70% testen, wie sich ggf., used= und total= gegenüber darstellen nach dem Balancing.

Wie schon angeklungen, daß sind Aussagen, Hinweise aufgrund dem, wie ICH das Balancing meine verstanden zu haben. Lasse mich da gerne korrigieren.

Nochmal ein Nachtrag zu meiner anderen Aussage zu btrfs-subvolumes im letzten Post:
<...der einzige Nutzen von subvolumes bei btrfs ist IMHO die Snapshot-Funktionalität...>
Das war sehr kurzgegriffen von mir, die Btrfs-Doku liefert da bessere Argumente wann/warum Subvolumes "Sinn" machen:
https://btrfs.wiki.kernel.org/index.php … Subvolumes

#40 18.11.2017 02:26:12

mabox
Mitglied

Re: BTRFS RAID über SSD und HDD hinweg möglich?

Hi GerBra,
und wieder mal vielen Dank für Deine ausführliche Hilfe. Einwandfrei erklärt. Deinen Scriptvorschlag habe ich jetzt gleich mal eingebaut und werde das dann tatsächlich mal eine Weile beobachten. Ansonsten befasse ich mich jetzt weiter mit BTRFS so wie Du beschrieben hast und beobachte mein System genau.

Was machen Deine Tests mit dem Ausgangsproblem hier? Irgendwelche neuen Erkenntnisse? Ich denke mittlerweile solch eine Konstellation hat vermutlich kaum jemand. Sonst käme das Thema doch vielleicht schon mal hier irgendwo hoch im Forum.

Schöne Grüße
mabox

Offline

#41 19.11.2017 10:47:02

GerBra(offline)
Gast

Re: BTRFS RAID über SSD und HDD hinweg möglich?

GerBra(offline) schrieb:

Zum Vergleich mal die df Ausgabe von meinem Btrfs-System, was schon einige Jahre läuft, nur als Anhalt:
...
Ich werde die Tage hier mal mit 5% und mit realistischeren 50-70% testen, wie sich ggf., used= und total= gegenüber darstellen nach dem Balancing.

Das habe ich nun mal gemacht, hier das Ergebniss:

# btrfs file df -g --si /                                                                      
Data, RAID1: total=1162.86GB, used=1160.04GB                                                   
System, RAID1: total=0.04GB, used=0.00GB                                                       
Metadata, RAID1: total=3.22GB, used=1.58GB                                                     
GlobalReserve, single: total=0.54GB, used=0.00GB                                               
---------------------------                                                                    
# time btrfs balance start -dusage=5 /                                                         
Done, had to relocate 0 out of 1088 chunks                                                     
                                                                                               
real<-->0m0.748s                                                                               
user<-->0m0.000s                                                                               
sys<--->0m0.137s                                                                               
----------------------------                                                                   
# time btrfs balance start -dusage=50 /                                                        
Done, had to relocate 2 out of 1088 chunks                                                     
                                                                                               
real<-->0m26.539s                                                                              
user<-->0m0.000s                                                                               
sys<--->0m4.667s                                                                               
# btrfs file df -g --si /                                                                      
Data, RAID1: total=1161.79GB, used=1160.04GB                                                   
System, RAID1: total=0.01GB, used=0.00GB                                                       
Metadata, RAID1: total=3.22GB, used=1.58GB                                                     
GlobalReserve, single: total=0.54GB, used=0.00GB                                               
----------------------------------                                                             
# time btrfs balance start -musage=75 -dusage=75 /                                             
Done, had to relocate 4 out of 1086 chunks                                                     
                                                                                               
real<-->1m31.653s                                                                              
user<-->0m0.010s                                                                               
sys<--->0m14.093s                                                                              
# btrfs file df -g --si /                                                                      
Data, RAID1: total=1161.79GB, used=1160.04GB                                                   
System, RAID1: total=0.03GB, used=0.00GB                                                       
Metadata, RAID1: total=3.22GB, used=1.58GB                                                     
GlobalReserve, single: total=0.54GB, used=0.00GB                                               

Bei usage=5 - wie erwartet<g> - Null Effekt (0 chunks), die anderen Läufe brachten mir jetzt keine wesentliche Änderungen. Zumindest keine, die mich an diesem System veranlassen würden, den 75%-Balance-Lauf irgendwie periodisch z.B. im nächsten Monat wiederholen zu wollen.

Mein System wird dient hauptsächlich als $HOME für meine Clients und als VideoDiskRecorder(VDR) und Massengrab für Filme. Die Datenveränderungen bewegen sich pro Tag eher im (kleiner ~10)Gigabyte-Bereich, und das verwaltet Btrfs wohl vorab schon "intelligent". Anders kann sich das wieder auf Systemen darstellen, die z.B. Änderungen im TB-Bereich haben (und halt auch kein raid1 aus 2 Devices).

Zu den Tests mit dem "Ausgangsproblem": Schaue ich die nächsten Tage mal, bin mir aber aus den bisherigen schon angeführten Dingen sicher, daß zweite/dritte zusätzliche Btrfs-Volumegroups/Pools - von denen *nicht* gebootet wird - "ausfallsicher" nur außerhalb der /etc/fstab handhabbar wären. Zum Btrfs-Status-Skript habe ich bisher nur "Ideen" *wie*, aber noch nichts *gemacht* ;-)

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums