BTRFS Subvolume Input/Output Error bzw WARNING: CPU PID /fs/btrfs/extent-tree.c:


mgutt

Recommended Posts

Gestern habe ich einem Kunden geholfen, der einen mir bisher unbekannten BTRFS Fehler hatte. Es gab einen Fehler wie diesen, gefolgt von einem Stack Trace:

WARNING: CPU: 2 PID: 452 at ../fs/btrfs/extent-tree.c:3731 btrfs_free_reserved_data_space_noquota+0xe8/0x100 [btrfs]()

image.png.26b5f670e05188265aea07b24cdf64ac.png

 

Dem folgten dann noch einige "BTRFS error (device loop2) bdev /dev/loop2, loop Write error at byte offset length"

 

Als Resultat wurde eine der SATA SSDs seines RAID1 auf BTRFS info (device sdc1): forced readonly" gesetzt. Nach einem Neustart war soweit wieder alles ok, also habe ich einen scrub gemacht.

 

Bei der weiteren Analyse fiel mir auf, dass seine SSDs fast abgenutzt waren (schaut mal auf Power on hours und Percent lifetime remain, da soll noch einer sagen, dass es nicht dringend notwendig ist für Docker eine RAM-Disk einzuführen), aber sonst keine Fehler zeigten:

image.thumb.png.b381779c12cfde2aeb9d334a9bd2e760.png

 

Also wies ich ihn auf meinen Guide hin und nach Ausgabe der BTRFS Subvolumes von Docker, kam es zu einem Input/Output Error:

image.png.33044c1c93d2d0b81a302e6c22b6d7fa.png

 

Und erneut wurde die SSD auf readonly gesetzt:

image.png.9999148002c7ea678303e484255193fc.png

 

Was mich ja total verwundert ist, dass wir hier von einem Subvolume innerhalb eines gemounteten docker.img sprechen. Es geht also eigentlich gar nicht um das BTRFS RAID1, aber trotzdem wird die komplette SSD (/dev/sdc) auf readonly gesetzt?!

 

 

 

 

 

Link to comment
1 hour ago, mgutt said:

da soll noch einer sagen, dass es nicht dringend notwendig ist für Docker eine RAM-Disk

Bin schon hier. :D

 

Also ich kann das nicht nachvollziehen, meine SSD's laufen seit ca. 2 Jahren mit ~30 Containern und kenn das überhaupt nicht.

 

Ich kann nur vermuten das bei allen/vielen containern der healthcheck angeschaltet ist bzw irgendetwas extram auf die caches schreibt.

Um welche SSDs handelt es sich, wieviel wird auf die SSDs geschrieben, laut den total written lbas muss da exzessiv drauf geschrieben werden nach 1,5 monaten, ich kann mir nicht vorstellen das es nur durch die Logs so zustande kommt.

Link to comment
13 minutes ago, ich777 said:

Ich kann nur vermuten das bei allen/vielen containern der healthcheck angeschaltet ist

Ja war es. Der Nutzer hat auch massig Container im Einsatz.

 

14 minutes ago, ich777 said:

kenn das überhaupt nicht.

Naja, wenn du healthcheck überall deaktiviert hast, dann hast du ja schon aktiv was gemacht. Dieser Nutzer und ich denke das gilt für die meisten, wissen ja gar nicht was das überhaupt bedeutet. Die wundern sich nur einfach, wenn die SSD nach kurzer Zeit wieder tot ist und schieben das dann natürlich auf Unraid.

 

13 minutes ago, ich777 said:

Um welche SSDs handelt es sich, wieviel wird auf die SSDs geschrieben

Crucial MX500 im BTRFS RAID1 und das docker.img entsprechend auch BTRFS. Wie viel da geschrieben wird, konnte ich nicht testen, da nach kurzer Zeit die SSDs auf read only wechselten. Auch hier wieder nervig, dass Unraid in der GUI nichts dazu meldet. Weder kommen Benachrichtigungen, noch sieht man optisch, dass der Cache Pool hinüber ist.

 

Ich habe daher empfohlen auf XFS zu wechseln, die zweite SSD als Backupziel zu verwenden und Docker auf Pfad umzustellen. Dann gibt es auch keine BTRFS Subvolumes mehr.

 

Findest du es denn nicht auch komisch, dass ein Subvolume in einem Disk-Image die Hauptpartition beeinflussen kann?

Link to comment
12 minutes ago, mgutt said:

Ja war es. Der Nutzer hat auch massig Container im Einsatz.

Ja aber ~120TB bei 512B oder ~960TB bei 4K (je nach sektor größe) ist schon viel nur für den health check in 1,5 Monaten...

 

12 minutes ago, mgutt said:

Auch hier wieder nervig, dass Unraid in der GUI nichts dazu meldet. Weder kommen Benachrichtigungen, noch sieht man optisch, dass der Cache Pool hinüber ist.

Werd mich da mal schlau machen ob das so gewollt ist.

 

12 minutes ago, mgutt said:

Ich habe daher empfohlen auf XFS zu wechseln, die zweite SSD als Backupziel zu verwenden und Docker auf Pfad umzustellen. Dann gibt es auch keine BTRFS Subvolumes mehr.

Das wäre auch eine möglichkeit.

 

12 minutes ago, mgutt said:

Findest du es denn nicht auch komisch, dass ein Subvolume in einem Disk-Image die Hauptpartition beeinflussen kann?

Nein also wenn ein subvolumen einen fehler auslöst dann wird automatisch das parent auf read only gesetzt.

Ihr könntet auch probieren auf den pfad umzustellen um diese "problem" zu umgehen, ihr benutzt doch hier ein image statt dem pfad was ich so herauslese.

Link to comment
22 minutes ago, ich777 said:

Ihr könntet auch probieren auf den pfad umzustellen um diese "problem" zu umgehen, ihr benutzt doch hier ein image statt dem pfad was ich so herauslese

Das wäre ja das selbe, nur dass die Subvolumes dann direkt in der Hauptpartition stecken.

 

Ansonsten würde natürlich schon die Umstellung alleine helfen, weil dadurch ja alle Subvolumes neu erstellt werden. Aber falls es wieder zu dem Fehler käme, wäre auch hier wieder das ganze RAID kaputt.

 

22 minutes ago, ich777 said:

Nein also wenn ein subvolumen einen fehler auslöst dann wird automatisch das parent auf read only gesetzt.

Das wundert mich, weil man ja rein theoretisch das BTRFS Image auch auf einer XFS Partition liegen haben könnte. Das gemountete BTRFS setzt dann bei Fehlern ja auch nicht die XFS Partition auf read-only. Also was hier als "parent" betrachtet wird, finde ich komisch. Auch weil es einfach eine viel zu krasse Reaktion ist, da es ja nur um ein Subvolume von Container XYZ geht. Soll der eben kaputt sein. Dafür muss man ja nicht gleich das ganze RAID "killen".

 

Weißt du mit welchen Optionen das docker.img gemountet wird? Es gibt doch bestimmt eine Option wo man die Auswirkungen auf das Parent Volume verhindern kann, evtl über subvol und/oder subvolid?!

Link to comment
6 minutes ago, mgutt said:

Weißt du mit welchen Optionen das docker.img gemountet wird

Auswendig nicht aber du kannst dir ein neues xfs docker image erstellen, wäre noch ein workaround.

 

7 minutes ago, mgutt said:

Das wäre ja das selbe, nur dass die Subvolumes dann direkt in der Hauptpartition stecken.

BTRFS... Manche schwören drauf und manche hassen es.

Gibt hier im forum viele leute die damit probleme gehabt haben und nie wieder BTRFS verwenden wollen.

  • Like 1
Link to comment
1 hour ago, ich777 said:

Gibt hier im forum viele leute die damit probleme gehabt haben und nie wieder BTRFS verwenden wollen.

 

Ich bin hier ;--)

 

3 hours ago, mgutt said:

Gestern habe ich einem Kunden geholfen, der einen mir bisher unbekannten BTRFS Fehler hatte.

 

Spaß beiseite: Mit dem Wechsel zu 6.9 gab es doch eine Änderung (Stichwort: New partition alignment). Wenn ich mich richtig erinnnere hatte ich 22 TB written nach 6 Monaten. Ich hatte dann die Subsysteme Docker und VM komplett gestoppt und alles aufs Array gesichert. Da ich ohnehin mit dem Umbau beschäftigt war, wurden beide M.2 diesmal mit XFS neu formatiert und alles wieder zurück gespielt. Danach war der ganze Spuk vorbei. Nie wieder massive Schreibaktivitäten und nie wieder die Notwendigkeit für BTRFS Maintenance.

 

Marc, guck mal welches Partition Alignment die SSDs Deines Kunden haben.

 

  • Like 1
Link to comment
17 minutes ago, hawihoney said:

Marc, guck mal welches Partition Alignment die SSDs Deines Kunden haben.

Zu spät, ist schon XFS. ^^ Im Sinne des Kunden ist das effizienter gewesen. Ich kann da ja nicht auf dessen Kosten stundenlang herumprobieren.

 

Wenn das außerdem wirklich so ist, dass BTRFS Subvolumes das Parent still legen können, sehe ich BTRFS eh als keine Option mehr, außer Docker ist exklusiv auf einem Pool. Da hat mir Docker eindeutig zu viel Einfluss auf VMs, SMB, usw.

Link to comment
9 hours ago, ich777 said:

Gibt hier im forum viele leute die damit probleme gehabt haben und nie wieder BTRFS verwenden wollen.

Du kennst meine Meinung hierzu ;) nie wieder btrfs nach zweimaligem neu machen (und einmal ohne backup ich Depp) ;)

 

und wenn wir ehrlich sind passiert das glaube ich noch viel häufiger wenn ich so manche Fehlermeldungen lese und wie oft docker images neu gemacht werden usw usw ... seit xfs vor knapp 2 Jahren hiermit keine issues mehr gehabt (glücklicherweise) obwohl ich jetzt tagesaktuelle backups hätte ;)

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.