Tremendous Posted June 6 Share Posted June 6 Moin zusammen, Als ich dieses Jahr mein Unraid aufgesetzt habe, habe ich erstmal auf die Standardeinstellungen vertraut. Im Ergebnis laufen meine Cache nvme und meine Pool SSD auf btrfs. Nun lese ich hier immer wieder, dass von btrfs insbesondere im Pool abgeraten wird. Ich wollte das nun mal angehen und auf ein empfohlenes Datei System wechseln. Vorher möchte ich mir aber mein Vorgehen absetzen lassen um nachher nicht im Regen zu stehen. Cache: Es laufen nur drei Docker und wird vornehmlich für die schnelle Dateiablage aus dem 2,5 GHz Netzwerk benutzt um die Daten danach per Mover aufs Array zu schieben. Hier würde ich docker und vm Dienste stoppen, mover aufs array umstellen und laufen lassen. In dem Zug die nvme auf 2 TB updaten und nach Formatierung wieder die Dateien vom array auf Cache verschieben. Fertig. Pool: Es befinden sich ca. 70.000 kleine Dateien auf der SSD. Ein Backup existiert. Die Dateien sind alle in der gleichen Share wie das Array. Die Dateien sind alle in einer Plex Mediathek organisiert. Wenn ich nun die SSD auf ein neues dateisystem formatieren und mein Backup einspiele dürfte meiner Ansicht nach bei den Dockern kein Problem mit der Indizierung auftreten da die Dateien immer noch in der gleichen ordnerstruktur vorhanden sind!? Sehe ich das richtig? Dateisystem: Auf welches Dateisystem soll ich setzen für Cache und Pool? Cache behält den oben beschriebenen Anwendungsfall. Der Pool wird perspektivisch 200.000 mp3 Dateien beherbergen. Quote Link to comment
ich777 Posted June 6 Share Posted June 6 18 minutes ago, Tremendous said: Nun lese ich hier immer wieder, dass von btrfs insbesondere im Pool abgeraten wird. Wo und vor allem warum? Ich verwende das schon seit dem ich mit Unraid angefangen habe und bin sehr zufrieden damit in einem RAID1 sprich Mirror. Ich habe sogar erst vor kurzem meinen 2. Pool von ZFS wieder zurückgestellt auf BTRFS weil ich mit dem ZFS Mirror überhaupt nicht mehr zufrieden war und ich andauernd Kernel Panics hatte bei Docker container updates. 18 minutes ago, Tremendous said: Ich wollte das nun mal angehen und auf ein empfohlenes Datei System wechseln. Ich würde trotzdem noch immer zu BTRFS raten für einen Mirror bzw. eine Single device als Pool. Bei BTRFS hast du vor allem den Vorteil das du meistens noch was retten kannst bzw. du auch genau siehst was kaputt ist, bei ZFS ist es meistens so das es heißt: Destroy Pool und neu machen. Ich betreibe sogar noch Platten mit btrfs in Unassigned Devices: Sorry das ich hier evtl. wie ein ZFS hasser rüber komme aber ich finde das ZFS einfach ein wenig overhyped ist und natürlich jeder auf den ZFS Train aufspringt jedoch bedenken viele den Wartungsaufwand von ZFS nicht und wenn mal was kaputt ist brauchst du meistens irgendwo ein zweites Speichermedium auf das du deine Datein kopieren kannst, dann den Pool destroyst und schlussendlich deine Daten wieder zurück spielen musst. Wenn du dir die Hilfethemen von Oracle zu den ZFS fehlern ansiehst wird in vielen (ich glaub sogar mehr als der hälfte) empfohlen bei den Pool zu destroyen und neu zu erstellen um das Problem zu lösen. Meiner Meinung nach ist BTRFS noch immer ein sehr gutes Dateisystem gerade auf Unraid als Pool für die Zwischenspeicherung von Daten bzw. sogar auch für Daten die du länger dort drauf lässt. 3 Quote Link to comment
Tremendous Posted June 6 Author Share Posted June 6 Vielen Dank für deine Einschätzung! Wäre mein Vorgehen für den Cache NVME Wechsel so korrekt? Quote Link to comment
alturismo Posted June 6 Share Posted June 6 55 minutes ago, Tremendous said: Wäre mein Vorgehen für den Cache NVME Wechsel so korrekt? ja, wobei du dir eins sparen kannst, ../system/docker/ da liegen die docker images, wesentlich schneller durch Neuinstallation wieder hergestellt anstelle backup / restore und im Gegensatz zu @ich777 kann ich den Wechsel nur anraten ... spätestens beim ersten crash single drive > xfs pools (raidX) > lieber zfs anstelle btrfs ... Natürlich, wenn du bisher schmerzfrei durchkommst, warum wechseln ... 2 1 Quote Link to comment
Archonw Posted June 6 Share Posted June 6 Stimme altruismo da zu. Nach Möglichkeit kein BTRFS im Pool benutzen. Vor allem nicht, wenn man bei Docker von "Image" auf "Directory" umgestellt hat. Denn Docker selbst hat immer noch Probleme mit BTRFS und kann daruf nicht aufräumen, so dass alte Volumes nicht gelöscht werden können was natürlich ungünstig ist, da so schnell die Platte voll werden kann. Da du ja natürlich dich auch um das Backup des Cache gekümmert hast würde ich auch vermutlich wenn du sonst keine Probleme hast erst umstellen, wenn es zum Crash kommt. Quote Link to comment
ich777 Posted June 6 Share Posted June 6 4 hours ago, Archonw said: Nach Möglichkeit kein BTRFS im Pool benutzen. Vor allem nicht, wenn man bei Docker von "Image" auf "Directory" umgestellt hat. Denn Docker selbst hat immer noch Probleme mit BTRFS und kann daruf nicht aufräumen, so dass alte Volumes nicht gelöscht werden können was natürlich ungünstig ist, da so schnell die Platte voll werden kann. Also dieses Problem kenne ich gar nicht. Von wo hast du die Info? Wenn du verwaiste Images (bzw. dangling images) hast musst du die auf Unraid immer manuell löschen mit der Advanced View im Docker Tab eingeschaltet, das sollte aber eher die Ausnahme sein. Normalerweise werden die subvolumes von Docker ganz normal gelöscht. Quote Link to comment
vakilando Posted June 6 Share Posted June 6 (edited) Ich kann mich nur auf die Seite von @ich777 stellen und ihm zustimmen.... Ich habe von Anfang an (seit über 5 Jahren) einen Btrfs Cache Pool (RAID1). Tatsächlich hatte ich einmal defekte SSDs (der Pool bestand damals aus 2 x SanDisk SSD PLUS 480GB), diese sind beide kurz hintereinander gestorben.... Siehe auch Allerdings habe ich danach mit zwei Crucial MX500 1 TB SSDs erneut einen Btrfs Cache aufgebaut mit zwei "Modifikationen": - Docker directory anstelle von Docker Image - bei allen Docker Containern unter "Extra Parameter" folgendes hinzugefügt: "--no-healthcheck" Dieser Btrfs RAID1 Cache Pool läuft bis heute anstandslos. @Archonw, dass man vor allem kein BTRFS im Pool benutzen sollte, wenn man bei Docker von "Image" auf "Directory" umgestellt hat ist auch das erste was ich höre. Die ZFS Option finde ich durchaus interessant, habe aber derzeit keine Notwendigkeit umzustellen und warte daher lieber noch ab bis die ZFS Integration einfacher/vollständiger/ausgereifter ist. Edited June 6 by vakilando 1 Quote Link to comment
saber1 Posted June 7 Share Posted June 7 Kommt mir irgendwie gerade surreal vor dieser Thread. Das geistert doch schon seit gefühlt zwei Jahren durchs Forum, das BTRFS auf SSD's im Pool Probleme macht. Das hört Ihr jetzt zum ersten Mal? 😮 1 1 1 Quote Link to comment
ich777 Posted June 7 Share Posted June 7 1 hour ago, saber1 said: Das geistert doch schon seit gefühlt zwei Jahren durchs Forum, das BTRFS auf SSD's im Pool Probleme macht. Aber warum und vor allem wo? Ich muss dich mal anders fragen, was haben User vorher genutzt bevor es ZFS nativ und das ZFS plugin gab in einem Pool den sie redundant haben wollten? BTRFS war immer schon der Standard in Unraid für den Pool. Sogar Tom kompiliert die ganzen Unraid Kernel auf BTRFS (und ich mach das auch auf meinem System für die Treiber Plugins). 1 hour ago, saber1 said: Das hört Ihr jetzt zum ersten Mal? 😮 Sicher hab ich das schon mal gehört zB von @alturismo und der geht auch nicht mehr zurück (das hab ich mittlerweile akzeptiert ) aber für mich läuft das seit Jahren stabil und hatte nie ein Problem. Ich gehe zB sicher nicht mehr zurück auf ZFS (hatte das sowieso nur testweise in einem Pool) und hatte wie schon oben geschrieben dann Probleme, bin jetzt wieder zurück auf BTRFS. ...hat nicht jeder mal Probleme... 1 Quote Link to comment
saber1 Posted June 7 Share Posted June 7 Ich selbst hatte tatsächlich auch noch keine "BTRFS-Probleme". Ich wunderte mich nur über die Frage. So als ob das jetzt aus heiterem Himmel kommt. Quote Link to comment
ich777 Posted June 7 Share Posted June 7 23 minutes ago, saber1 said: Ich wunderte mich nur über die Frage. So als ob das jetzt aus heiterem Himmel kommt. Naja aber mal ehrlich, von wievielen Problemen weißt du wirklich und mich würde interessieren welche Probleme genau? Das mit Docker und BTRFS ist mir zum Beispiel komplett neu. Das ganze hört sich für mich eher nach hören sagen an und: ich hab das von diesem und diesem user gehört die verwenden aber auch produktiv BTRFS. Ich glaube du weißt worauf ich hinaus will. Ganz ehrlich, es gibt ab und an mal Probleme aber dann ist das meist Hardware basiert oder irendwas wurde unabsichtlich formatiert, aber so von wirklichen Problemen mit BTRFS weiß ich eigentlich nichts. Oh und natürlich der Ausnahmefall RADI5/6 wird verwendet mit BTRFS <- das sollte aber mittlerweile auch laufen, jedoch wird es noch immer unter experimentell geführt in der Doku wenn ich da noch richtig informiert bin. Quote Link to comment
Amane Posted June 7 Share Posted June 7 (edited) Warum ZFS? ZFS hat Deduplizierung und spart damit oft sehr viel Platz. ZFS ist mächtig an den Funktionen - Die man zugegebenermassen selten benötigt ZFS ist schneller je mehr RAM man dem ARC Cache zuweisen kann. ZFS ist aber daher nicht sehr Ausfallssicher, weswegen eine USV empfohlen wird. Ich hatte (zum Glück) noch nie einen Ausfall. Habe jedoch beide Systeme immer wieder ausprobiert und hab mich schliesslich für ZFS entschieden. Und XFS als separaten Pool für Docker. Das Imiges nicht richtig gelöscht werden (als ich brtfs hatte) umgehe ich persönlich so, dass ich dies mit Portainer prüfe und immer mal wieder von Hand aufräume. Das mach ich sowieso.. Wer das auch macht, hat auch mit btrfs quasi keine Probleme. (Hat sich da mal was getan?) Weder btrfs noch zfs ist im meinen Augen für das Docker Verzeichnisse optimal. Bei btrfs werden die Imiges nicht aufgeräumt nach entfernen des Containers, trotz dem Haken "Image auch entfernen". Bei ZFS hast du dafür ca. 200 Snapshots von jedem Image das jeder Container benutzt. Das siehst du halt erst, wenn du dir z.B. das Plugin ZFS Snapshots dazu hohlst. Ist zwar nicht Müll, so arbeitet Docker mit ZFS halt einfach, aber in meinen Augen dennoch unschön. Desswegen kein Pool für "system/docker"..naja hoffe das kommt bald besser. @ich777 Ich hoffe mal stark, dass die Wiederherstellung auch ohne Workaround (Daten verschieben, neuen pool erstellen, Daten zurück) funktioniert. In den meisten Fällen fehlt wahrscheinlich das Wissen dazu, oder man geht einfach auf nummer sicher und verlässt sich auf die bekannte Methode.. Auch ich würde immer den "Workaround" empfehlen, da dies auch ohne sich auskennen zu müssen immer funktionieren wird. (Solange man Platz hat) Aber nach meinem Wissenstand funktioniert die Wiederherstellung wie folgt: RAID 1 Btrfs - Das System identifiziert, dass eine Festplatte fehlerhaft ist und nicht mehr gelesen werden kann. - Festplatte entfernen: Der Administrator entfernt die fehlerhafte Festplatte physikalisch und setzt eine neue Festplatte ein. - Partitionieren und Dateisystem erstellen: Die neue Festplatte wird partitioniert und das Btrfs-Dateisystem wird darauf erstellt. - Rebalancing und Wiederherstellung: Mit dem Befehl btrfs replace start wird die fehlerhafte Festplatte durch die neue ersetzt. Btrfs beginnt dann mit dem Rebalancing und der Replikation der Daten von der noch intakten Festplatte auf die neue Festplatte. ZFS - ZFS benachrichtigt den Administrator über einen Festplattenfehler, typischerweise über ZFS-Events oder Systemlogs. - Festplatte ersetzen: Die defekte Festplatte wird entfernt und eine neue eingebaut. - ZFS Replace-Befehl: Der Befehl zpool replace wird verwendet, um ZFS anzuweisen, die alte Festplatte durch die neue zu ersetzen. - Resilvering: ZFS beginnt mit dem Prozess des "Resilvering", bei dem die Daten von der funktionierenden Festplatte auf die neue Festplatte gespiegelt werden. RAID 5 Btrfs - Ähnlich wie bei RAID 1. - Neue Festplatte hinzufügen: Die neue Festplatte wird dem Array hinzugefügt. - Rebalancing und Datenwiederherstellung: Btrfs beginnt automatisch mit einem Rebalancing-Prozess, um die Daten über das gesamte RAID-Array neu zu verteilen und die Parität wiederherzustellen. ZFS - Ähnlich wie bei RAID 1. - ZFS Replace-Befehl: Auch hier wird der Befehl zpool replace verwendet. - Resilvering: ZFS führt das Resilvering durch, um die Datenintegrität und die Paritätsinformationen auf der neuen Festplatte wiederherzustellen. Das muss sowohl als auch funktionieren! Edited June 7 by Amane Quote Link to comment
ich777 Posted June 7 Share Posted June 7 2 minutes ago, Amane said: Das Imiges nicht richtig gelöscht werden (als ich brtfs hatte) umgehe ich persönlich so, dass ich dies mit Portainer prüfe und immer mal wieder von Hand aufräume. Aber das sollte doch nicht der Regelfall sein. Ich meine verwaiste Images musst du sowieso immer per Hand löschen aber zu solchen images sollte es nur kommen wenn du händisch das Repository änderst. 5 minutes ago, Amane said: Bei btrfs werden die Imiges nicht aufgeräumt nach entfernen des Containers, trotz dem Haken "Image auch entfernen". Das ist hier echt nicht so, ich habe gestern updates von all meinen container gepusht und ich benutze auf meinem Server viele davon und alles wurde ordnungsemäß gelöscht und upgredated (war auch bei ZFS so). 6 minutes ago, Amane said: @ich777 Ich hoffe mal stark, dass die Wiederherstellung auch ohne Workaround (Daten verschieben, neuen pool erstellen, Daten zurück) funktioniert. Also ich wüsste nicht wie, ein Pool Destroy heißt das du den kompletten Pool löscht und dann neu erstellst und dazu musst du deine Daten erst wo hin schieben. Such einfach mal nach ZFS Pool Destroy auf Google. Klar ZFS hat schon coole features aber ich will da immer nur drauf hinweisen das ZFS auch dementsprechend teilweise Wartung und Aufmerksamkeit benötigt damit der auch stabil und ohne fehler läuft, dessen sind sich aber viele nicht bewusst. 10 minutes ago, Amane said: ZFS - ZFS benachrichtigt den Administrator über einen Festplattenfehler, typischerweise über ZFS-Events oder Systemlogs. - Festplatte ersetzen: Die defekte Festplatte wird entfernt und eine neue eingebaut. - ZFS Replace-Befehl: Der Befehl zpool replace wird verwendet, um ZFS anzuweisen, die alte Festplatte durch die neue zu ersetzen. - Resilvering: ZFS beginnt mit dem Prozess des "Resilvering", bei dem die Daten von der funktionierenden Festplatte auf die neue Festplatte gespiegelt werden. Ja klar das ist das standard prozedere wenn eine Platte kaputt ist und wenn Resilvering noch läuft, es gibt aber auch andere Fehler die meistens auch einen link zur Doku enthalten, das hab ich eher gemeint: https://openzfs.github.io/openzfs-docs/msg/index.html Nochmal zu meinem Problem das ich oben beschrieben habe, Kernel Panic (ziemlich random aber meistens nach 1 bis 2 Tagen) wenn ich Docker updates gemacht habe auf meinem ZFS Pool: Ich habe den ZFS Pool mittlerweile platt gemacht (war mein haupt Pool BTW) und jetzt wieder mit BTRFS neu aufgesetzt und es läuft alles (mittlerweile seit 28 Tagen, sprich seitdem ich den Pool wieder auf BTRFS umgestellt hab). Is eben nervig wenn du alle 2 bis 3 Tage einen crash hast nur weil du Docker container updates. Keine Ahnung was mein Pool da hatte, ich hab auch nicht viel dazu gefunden ist aber definitv ZFS zuzuordnen. Klar vermutlich war das ein Ausnahmefall aber das hat mich wieder gelehrt nicht einfach immer was neues auszuprobieren wenn das bestehende gut läuft. Klar ZFS hat wie gesagt auch viele coole features und kann auch richtig viel aber für die meisten User is BTRFS auf Unraid völlig ausreichend um einen Mirrored Pool zu erstellen. Quote Link to comment
ich777 Posted June 7 Share Posted June 7 Habe gerade kurz mit @JorgeB darüber geschrieben und ich verlinke hier seine Anleitung zum Monitoren von BTRFS/ZFS sodas ihr eine Nachricht bekommt wenn irgendetwas mit eurem Pool(s) nicht stimmt: (muss natürlich an auf euer System und eure(n) Pools(s) angepasst werden) Sowas ähnliches wird hoffentlich bald direkt in Unraid implementiert. 2 Quote Link to comment
b_tob Posted June 7 Share Posted June 7 Als ich vor etwas mehr als einem Jahr meine Cache Disks gegen grössere ausgewechselt habe stellte ich im gleichen Zuge von BTRFS zu ZFS um. Lief ein paar Tage ohne Probleme, doch ab dann lief gar nichts mehr. Jedes Mal wenn ich das Array starten wollte gab es einen PANIC Fehler und der Server stürzte ab. Nach langem Hin und Her die Cache Disks wieder zu BTRFS formatiert, seither läuft die Kiste wieder anstandslos durch. Den Fehler, den ich damals erhalten habe, ist in diesem Thread ersichtlich. 1 Quote Link to comment
DataCollector Posted June 8 Share Posted June 8 (edited) On 6/7/2024 at 7:53 AM, ich777 said: Aber warum und vor allem wo? Falls die Frage bedeutet: wo kann man das nachlesen: Leider ist im Forum die Suchfunktion nicht so ausgeklügelt (oder ich habe sie noch nicht gut genug verstanden), daß man genau diese Beiträge recht einfach herausfiltern und somit benennen kann. Aber es gibt wohl so einige, die eben irgendwelche Fehler/Probleme meldeten, bei denen sich dann nach Reparatur von btrfs der Betrieb wieder ganz normal fortführen ließ. Das betraf zwar öfters den Verbund von mehreren Daterägern, weil das unter unraid pre 6.12.x nur mit btrfs ging, aber soweit ich es richtig in Erinnerung habe waren da auch einige Singledrive oder gar Docker VD, die dann mit btrfs Probleme erzeugten. Das ist einer der Gründe warum ich bei Singledrive (auch im array) zu xfs rate und bei Verbund (im Pool) seit 6.12.x zu zfs. Und ich stimme zu, daß zfs auch (noch) nicht vollständig oder gar perfekt implementiert zu sein scheint, aber so viele Probleme, wie ich hier im deutschen unraidforum mit btrfs gelesen habe, habe ich in zfs noch nicht mitbekommen (sofern man sich eben auf diese Kernfunktion beschränkt. Snapshots oder exotischere Zusatzfunktionen von zfs nutze ich nicht und würde ich aktuell auch nicht unter unraid zfs empfehlen). Dein Hinweis oben bei Dir auf Kernel Panics ist (meiner schlechten Erinnerung nach) der erste Beitrag, in dem ich etwas von zfs Problemen las. (Ich habe aber natürlich nie alle Beiträge gelesen.) Und man hat ja zfs in unraid am Anfang nur so ein bisschen implementiert und das dann ja wohl auch später fortgesetzt/erweitert. Es ist ja wohl immer noch nicht alles möglich, was zfs wirklich beherrschen sollte. Somit sind Versuche mit früheren unraidversionen mit zfs wenig vergleichbar zu dem nun heutigen oder gar zukünftig neuen Stand ab 7.x. Das Problem würde ich (meiner persönlichen Meinung nach) als ungewöhnlichen Einzelfall ansehen. (Oder versteckt unraid Kernel Panic derart, daß es unbehelligt weiter läuft?) Mir ist bisher unter unraid mit zfs in Pools (bei Datenträgerverbünden) noch nichts derartiges aufgefallen, aber auch ich bin nur ein Einzelfall. On 6/7/2024 at 7:53 AM, ich777 said: Ich muss dich mal anders fragen, was haben User vorher genutzt bevor es ZFS nativ und das ZFS plugin gab in einem Pool den sie redundant haben wollten? btrfs, weil es nichts anderes gab. Als ich mit unraid begonnen habe waren auch schon da ältere Problemberichte zu lesen, die sich dann mit Reparatur von btrfs beheben ließen. Anfangs habe ich zum Lernen viel in alten Beiträgen geschnuppert. On 6/7/2024 at 7:53 AM, ich777 said: Sicher hab ich das schon mal gehört zB von @alturismo und Ich glaube mich auch daran zu erinnern, daß mgutt mehrfach gerne in einem Nachsatz andeutete, daß er sich nicht mehr wirklich mit btrfs Fehlern befassen möchte... unraid ist ja schön flexibel: Jeder ist frei seine eigene Entscheidung zu treffen. 😃 Basierend auf den Problemfällen im Forum habe ich mich weitgehend für xfs + zfs entschieden und da ich bisher keine Probleme hatte (wie gesagt, bin auch nur ein Einzelfall), die ich auf eines dieser beiden schieben kann werde ich es auch weiter so mitteilen. Und nur der Klarheit: eigentlich ist es egal, wenn man aktuelle Backups hat. 🤞 Edited June 8 by DataCollector Typos 2 Quote Link to comment
Recommended Posts
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.