Ich möchte ein Hardware RAID6 auf einem HP Server erstellen und als Dateisystem Btrfs benutzen, da es für mich Anwendungen wie Prüfsumme und Subvolumes unterstützt, mit denen ich live backups machen kann. Nun habe ich immer mal wieder gelesen, dass Btrfs und RAID6 zu problemen führen kann. Allerdings sieht der Kernel den Plattenverbund als eine Platte, da der RAID Controller eben den Verbund steuert. Bin ich damit auf der sicheren Seite?
Btrfs hat an sich eigenes RAID. Und bei diesem RAID 5 konnte man vor wenigen Jahren von ersten Problemen lesen, wurde davon abgeraten. Hat aber nichts mit Hardware RAID zu tun.
(prx) A. K. schrieb: > Btrfs hat an sich eigenes RAID. Und bei diesem RAID 5 konnte man vor > wenigen Jahren von ersten Problemen lesen, wurde davon abgeraten. Hat > aber nichts mit Hardware RAID zu tun. Die RAID Funktionen von Btrfs nutze ich gar nicht dafür ist das Hardware RAID gedacht. Der Antwort zufolge gehe ich davon aus, dass ich mir keine Sorgen machen muss?
Mir sind keine Probleme bekannt und es liegt auch nicht nahe, dass es welche geben könnte. Ich bin aber nicht der Experte dafür.
Martin schrieb: > Die RAID Funktionen von Btrfs nutze ich gar nicht dafür ist das Hardware > RAID gedacht. Da fehlt ein Komma. Sorry, aber man muß das Ding mehrfach lesen, bis man weiß, was der Schreiberling wirklich sagen wollte, bzw. was Haupt- und Nebensatz ist ...
Ein älteres, gängiges Dateisystem hat oft mehr Unterstützung. Ein Backup braucht man trotzdem! https://www.veuhoff.net/zfs-vs-btrfs-welches-dateisystem-ist-besser-und-wo-liegen-die-unterschiede/
Franko S. schrieb: > Nimm zfs, btrfs ist immer noch Müll. Warum ist Btrfs Müll? Scheint mir zumindest schon verbreitet und auch die Business Produkte von zum Beispiel Synology setzen darauf. Lu schrieb: > Ein älteres, gängiges Dateisystem hat oft mehr Unterstützung. Ein Backup > braucht man trotzdem! > https://www.veuhoff.net/zfs-vs-btrfs-welches-dateisystem-ist-besser-und-wo-liegen-die-unterschiede/ Meine Idee Dienste kurz abzuschalten, ist ein Snapshot zu erstellen, dann alle Dienste wieder starten und das Backup dann im Betrieb auf die Backup Platte zu schieben. So wie ich es verstanden habe müsste das mit Snapshots möglich sein. Mir ist vollkommen klar, dass RAID kein Backup ist.
Franko S. schrieb: > Nimm zfs, btrfs ist immer noch Müll. Warum? zfs braucht unmengen an RAM um halbwegs brauchbar zu funktionieren. Dazu muss das zfs modul immer extra dazu kompiliert werden, wenn mans mal nach nem Kernel Update vergisst ..... Für eine kleine NAS unbrauchbar. Ja, die Performance von zfs ist wohl etwas besser, aber so schnell wie ext4 isses nicht. Auf das integrierte raid5/6 bei btrfs verzichtet man wohl besser. Lu schrieb: > https://www.veuhoff.net/zfs-vs-btrfs-welches-dateisystem-ist-besser-und-wo-liegen-die-unterschiede/ Artikel ohne wirklich Inhalt... Martin schrieb: > Meine Idee Dienste kurz abzuschalten, ist ein Snapshot zu erstellen, > dann alle Dienste wieder starten und das Backup dann im Betrieb auf die > Backup Platte zu schieben. Kann man machen, man sollte aber nicht zu viele btrfs snapshots haben, wirkt sich irgendwann wohl negativ auf die Performance aus. Also snapshots nicht zu lange aufheben. Mal sehen wie sich bcachefs in Zukunft entwickelt.
Andreas M. schrieb: > Kann man machen, man sollte aber nicht zu viele btrfs snapshots haben, > wirkt sich irgendwann wohl negativ auf die Performance aus. Also > snapshots nicht zu lange aufheben. > > Mal sehen wie sich bcachefs in Zukunft entwickelt. Genau das ist der Plan. Snapshot erstellen, sichern, snapshot dann sofort wieder löschen. Es geht bei dem Snapshot nur darum etwas unveränderliches für die Zeit zu haben.
Hallo Martin, Martin schrieb: > Franko S. schrieb: >> Nimm zfs, btrfs ist immer noch Müll. > > Warum ist Btrfs Müll? Scheint mir zumindest schon verbreitet und auch > die Business Produkte von zum Beispiel Synology setzen darauf. jein! BTRFS hat eingebaute Volume-Managementfunktionen. Offensichtlich nutzen Synology und Netgear diese Funktionen jedoch nicht, sondern legen BTRFS auf eine LVM-Schicht: [... We'll return to this analysis in the near future. In the meantime, if you're going to run btrfs in any configuration in which it manages multiple disks—as opposed to, eg., Synology and Netgear NAS devices, which crucially layer btrfs on top of traditional systems like LVM to avoid these pitfalls—please do so very carefully. ...] Es wäre doch einfacher und übersichtlicher, die LVM-Funktionen von BTRFS zu nutzen, oder?! :) Quelle: https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/
:
Bearbeitet durch User
Peter M. schrieb: > BTRFS hat eingebaute Volume-Managementfunktionen. Offensichtlich nutzen > Synology und Netgear diese Funktionen jedoch nicht, sondern legen BTRFS > auf eine LVM-Schicht Ich nutze beides nicht. LVM nutze ich nur für root. Mein Btrfs ist ein reines Datengrab für Datenbanken und Benutzerdaten.
Franko S. schrieb: > Muss man das heute echt noch erklären? Ja wenn du das behauptest solltest du zumindest erklären können waum Btrfs für mein Szenario Müll ist.
Andreas M. schrieb: > Kann man machen, man sollte aber nicht zu viele btrfs snapshots haben, > wirkt sich irgendwann wohl negativ auf die Performance aus. Also > snapshots nicht zu lange aufheben. So schlimm ist das nicht, solange es nicht hunderte Snapshots werden. Gerade in Verbindung mit Samba sind regelmäßige Snapshots ("snapper") nützlich, da kannst du z.B. für den letzten Tag stündlich und sonst tägliche/monatliche Snapshots aufbewahren. Windows-Clients können direkt im Explorer auf die Snapshots zugreifen, und alte Dateiversionen bzw. versehentlich gelöschte Dateien wiederherstellen. Reduziert die "Admin, kannst du bitte Datei XY aus dem Backup holen"-Anfragen gewaltig...
Allgemein von Prinzip her betrachtet sollten bei QoS Filesystemen wie ZFS, Btrfs, WAFL Zugriffe auf den aktuellen Stand nicht verlangsamt sein, unabhängig von der Anzahl Snapshots. Aufwand entsteht beim Löschen von Snapshots, aber das ist Hintergrundaktivität, die nur das System beschäftigt. Darin besteht ein Unterschied zu NTFS-Snapshots.
:
Bearbeitet durch User
Martin schrieb: > Ja wenn du das behauptest solltest du zumindest erklären können waum > Btrfs für mein Szenario Müll ist. Da reicht der Platz und Zeit nicht. Google einfach selber mal danach. Wer das ernsthaft einsetzt hat einen an der Waffel.
Franko S. schrieb: > Martin schrieb: >> Ja wenn du das behauptest solltest du zumindest erklären können waum >> Btrfs für mein Szenario Müll ist. > Da reicht der Platz und Zeit nicht. Google einfach selber mal danach. > Wer das ernsthaft einsetzt hat einen an der Waffel. Schnelles Google suche ergab eher, dass es zum heutigen Zeitpunk einsatzbereit ist. Wenn du aktuelle Links hast, die etwas anderes sagen gerne teilen.
Martin schrieb: > Schnelles Google suche ergab eher, dass es zum heutigen Zeitpunk > einsatzbereit ist. Wenn du aktuelle Links hast, die etwas anderes sagen > gerne teilen. Dann setzt es ein.
Franko S. schrieb: > Dann setzt es ein. Thread kann geschlossen werden sonst kommen noch mehr Stänkerer.
Martin schrieb: > Nun habe ich immer mal wieder gelesen, dass Btrfs und RAID6 zu problemen > führen kann. Wo willst du das gelesen haben? BTRFS (wie jedes andere Filesystem auch) läuft auf einem Hardware-RAID6 oder md-RAID6 genauso gut (oder schlecht) wie direkt auf der Hardware. Mehr noch: bei einem Hardware-RAID hat es gar keine Chance zu entdecken, daß es auf einem RAID läuft. Meist beziehen sich die Auto-Detection Routinen aber ohnehin nur darauf, bestimmte Eigenheiten des unterliegenden Device (z.B. Stripe-Size bei md) zu erkennen und die Defaults passend dazu zu setzen. Das dient allerdings nur der Performance, nicht der Zuverlässigkeit. Was BTRFS angeht, da schließe ich mich der negativen Meinung des Vorposters an. Ich traue dem einfach nicht. Und da man für Snapshots auch andere (erprobte) Mechanismen wie LVM hat, kann man auf BTRFS auch ganz verzichten und ein gut abgehangenes fs wie ext4 oder xfs nehmen. IMHO. YMMV. EOD.
Beitrag #7715068 wurde vom Autor gelöscht.
Ich würde mir generell überlegen, ob ich ein Hardware-RAID benutzen will. Die haben für mich immer einen faden Beigeschmack, wenn dir der RAID-Controller stirbt, brauchst du den gleichen als Ersatz um noch mal an die Daten zu kommen. Die Wiederherstellung geht zwar idr. auch per Software, aber das ist kein schönes Unterfangen. Außerdem muss man auch immer mit Caching aufpassen, da will man in jedem Fall eine USV oder einen Controller mit Backup. Zudem machen die meisten Hardware RAID's keine Konsistenzprüfung der Daten, wie das ein Scrub macht. Das heißt, Fehler fallen nur auf, wenn die Platte selbst einen Fehler hat. Level1Techs hat da mal ein interessantes Video zu gemacht, wenn ich mich richtig erinnere. Software RAID ist mittlerweile für die meisten Anwendungen leistungstechnisch mehr als ausreichend. Persönlich bin ich ein Fan von ZFS, das braucht zwar etwas RAM ja, aber das kann man relativ weit runterschrauben, wenn man nicht die maximale Performance braucht, da der ARC eigentlich nur ein Lesecache ist. Was viel RAM braucht, ist Deduplication, aber das braucht man jetzt auch nicht unbedingt. Ein sehr mächtiges Feature von ZFS sind die special devices, wenn man die verwenden will, und natürlich die Kompression auf Dateisystemebene. Was für ein Dateisystem man benutzt, ist am Ende vermutlich Geschmackssache.
Kevin M. schrieb: > und natürlich die Kompression auf Dateisystemebene. OT:Kommt auf den Dateninhalt an. Komprimierte Fotos werden durch Komprimieren kaum kleiner. Wennn Daten nur durch einen Link ersetzt werden, sieht die Sache etwas sparsamer aus, kann aber im Detail wie Backup od. forensischen Sachen "interessant" werden.
Lu schrieb: > OT:Kommt auf den Dateninhalt an. Das stimmt, deshalb kann man bei ZFS ja alle möglichen Einstellungen auf Dataset ebene einstellen. Bei ZFS ist es halt wichtig, ein bisschen zu planen, wie man die Dateien aufteilt. Datasets sind ein mächtiges Tool, gerade in Kombination mit Snapshots. Für verschiedene Inhalte können auch verschiedene Kompressionsalgorithmen und sofern verfügbar auch Kompressionslevel interessant sein. Man muss sich da definitiv mit beschäftigen und im Voraus etwas planen.
Εrnst B. schrieb: > So schlimm ist das nicht, solange es nicht hunderte Snapshots werden. Warum? Ich habe Server mit über 3000 Snapshots.
Kevin M. schrieb: > Zudem machen die meisten Hardware RAID's keine Konsistenzprüfung der > Daten, wie das ein Scrub macht. Kenne ich anders.
Hallo Martin, Martin schrieb: > Nun habe ich immer mal wieder gelesen, dass Btrfs und RAID6 zu problemen > führen kann. Allerdings sieht der Kernel den Plattenverbund als eine > Platte, da der RAID Controller eben den Verbund steuert. Bin ich damit > auf der sicheren Seite? Ja, weil Du nicht die BTRFS-internen Raid-Funktionen nutzt. Schau' mal hier, was "mostly OK" ist und ob Dich das betrifft: https://btrfs.readthedocs.io/en/latest/Status.html Ein Datengrab braucht man ja nicht zu defragmentieren. Ob Du von "device replace" betroffen bist, musst Du wissen. Probleme scheint es zu geben, wenn Dir Dein Speicher voll läuft. Offensichtlich fehlt eine intelligente integrierte Aufräumfunktion, die all das enthält, was die folgenden Anleitungen beinhalten: https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-space-emergency-response/ https://www.reddit.com/r/btrfs/comments/z61esj/what_happened_to_my_disk_space/ https://unix.stackexchange.com/questions/709954/btrfs-and-lack-of-free-disk-space https://forums.opensuse.org/t/btrfs-disk-full-how-to-fix-it-is-that-really-the-solution/172576 https://forum.manjaro.org/t/howto-get-space-on-btrfs/145130 Edward Shishkin beschreibt den Grund für den Ärger: Abweichende Implementierung der Musteralgorithmen! https://lkml.org/lkml/2010/6/18/144 Hier wird auf die fehlende Eindeutigkeit der Inode-Nummern hingewiesen: https://www.reddit.com/r/btrfs/comments/13ons7x/what_precisely_does_kent_overstreet_bcachefs_mean/?tl=de Darin enthalten ist auch eine Rechtfertigung zur Abweichung der Implementation von den Referenzalgorithmen: [... Meines Wissens nach gab es eine praktische Entscheidung zur Implementierung von B-Tree-Elementen, die nicht genau den Angaben in der Literatur entsprach, aber keine wirklichen Auswirkungen hatte. ...]
:
Bearbeitet durch User
Jens G. schrieb: > Da fehlt ein Komma. > Sorry, aber man muß das Ding mehrfach lesen, bis man weiß, was der > Schreiberling wirklich sagen wollte, bzw. was Haupt- und Nebensatz ist > ... Dann übe gefälligst mehr fehlertolerantes lesen. Mit mehr Fehlertoleranz wird dir auch die Bewältigung des Alltags leichter fallen.
Kevin M. schrieb: > Außerdem muss man auch > immer mit Caching aufpassen, da will man in jedem Fall eine USV oder > einen Controller mit Backup. Ich möchte das auf einen HPE Gen10 nutzen. Aktuell gibt es keine USV für den Server.
Martin schrieb: > Ich möchte das auf einen HPE Gen10 nutzen. Aktuell gibt es keine USV für > den Server. Er meint möglicherweise einen Backup des Write-Caches im RAM vom RAID Controller. Früher wurde das RAM per Akku gestützt. Heute ist es nicht selten ein Flash-Speicher, in dem im Fall eines Stromausfalls der Inhalt landet. Wenn das nicht der Fall ist, oder der Akku nach vielen Jahren platt ist, empfiehlt es sich, auf einen Write-Cache zu verzichten.
Martin schrieb: > Ich möchte das auf einen HPE Gen10 nutzen. Davon gibt es viele, wenn du einen HPE Microserver Gen10 oder HPE MLxxx Gen10 (die Desktop Variante) mit einem von diesen abgespeckten HPE SmartArray Controllern meinst, dann tu dir selbst einen Gefallen und benutze ein Software-RAID. In diesem Budget-Server haben sie so ziemlich das untere Ende von ihren Hardware-RAID-Controllern verbaut. Die meisten können in einem "HBA-Mode" betrieben werden. Dann reichen sie die Platten einfach ans System durch. Da habe ich schon alles gesehen, von es gibt einen expliziten HBA Modus bis hin zu ja erstell auf jeder einzelnen Platte ein RAID0. Martin schrieb: > Aktuell gibt es keine USV für > den Server. Bei meinem Server zu Hause habe ich jahrelang keine USV benutzt und immer Glück gehabt. Mittlerweile hängt eine kleine APC USV dran, die ich mal im Angebot gekauft habe. Grade, wenn nur ein kleiner Server mit wenig Leistung dran hängt, sind die echt nicht mehr teuer. Überleg dir ggf. eine zu kaufen.
Kevin M. schrieb: > Davon gibt es viele, wenn du einen HPE Microserver Gen10 oder HPE MLxxx > Gen10 (die Desktop Variante) mit einem von diesen abgespeckten HPE > SmartArray Controllern meinst, dann tu dir selbst einen Gefallen und > benutze ein Software-RAID. In diesem Budget-Server haben sie so ziemlich > das untere Ende von ihren Hardware-RAID-Controllern verbaut. Konkret ein HPE DL380 Gen10 mit P408i-a controller. Die Platten sehe ich im System als eine Platte wenn ich ein RAID konfiguriert habe. Der Controller kümmert sich also darum.
Beitrag #7715437 wurde vom Autor gelöscht.
Kevin M. schrieb: > Mittlerweile hängt eine kleine APC USV dran Meine Erfahrung mit einer grösseren Anzahl APCs: Auch USVs können ausfallen. Bei einem sehr stabile Stromnetz ist die USV selbst das grössere Risiko. Wer sicher gehen will, hat Server mit 2 Netzteilen, eines an der USV, eines direkt.
Hardy F. schrieb: > Εrnst B. schrieb: > >> So schlimm ist das nicht, solange es nicht hunderte Snapshots werden. > > Warum? Ich habe Server mit über 3000 Snapshots. Kommt halt drauf an, wie der Snapshot verwendet wird. In VM-Umgebungen benutzt man ihn oft als temporäres Backup mit der Fähigkeit, davon ausgehend die VM sowohl zum aktuellen Stand zu migrieren als auch zum Stand des Snaphots zurückkehren zu können. Dazu wird zunächst der Snapshot aufgezeichnet. Alles danach passiert zunächst nur temporär. Macht man das mehrfach, hat man schnell etliche temporäre Buffer am Laufen, die die Änderungen zu ihrem jeweiligen Basis-Snapshot aufzeichnen. Das drückt die Performance und macht viel Speicherbedarf. Und last but not least: es ist nicht ganz einfach, diesen Kram zu einem gezielten Punkt in der Zeit komplett abzuräumen. Die GUIs (und noch mehr die CLIs) sind da oft hochkryptisch. Man muss schon recht weise sein, um hinter dem ganzen gequirlten Bullshit die Intention zu erkennen und am Ende das zu erreichen, was man haben will. Und das ist praktisch über die gesamte Breite der Anbieter von VM-Lösungen so. Ein Schelm, wer Arges dabei denkt... Bei Backup-Lösungen á la Synology werden die Snaphots aber ganz anders verwendet (hier vereinfacht dargestellt, um den Blick fürs Wesentliche nicht zu verbauen): Da wird der Snapshot gezogen, das System läuft aber derweil weiter. Nachdem der Snaphot fertig ist, wird er zum Backup-Medium kopiert und das Quellsystem kann dann unmittelbar vergessen, dass es ihn je gegeben hat. In Wirklichkeit wird halt noch der temporäre Puffer dieses einen Snapshots gemerged und erst dann ist das System wieder wirklich unbelastet.
Ob S. schrieb: > Macht man das mehrfach, hat man schnell etliche temporäre Buffer am > Laufen, die die Änderungen zu ihrem jeweiligen Basis-Snapshot > aufzeichnen. Copy-on-Write Filesystem wie btrfs oder ZFS zeichnen keine Deltas auf. Snapshots sind darin quasi ein natürlicher Nebeneffekt ihrer normalen Arbeitsweise. Es gibt keinen Basis-Snapshot und keine Änderungen dazu, sondern jeder Snapshot ist im Grunde ein eigenes Filesystem mit Root-Block, Inodes etc. Ressourcen, die den gleichen Stand wie vorher haben, werden gemeinsam verwendet. Der Normalbetrieb bewahrt einen konsistenten Zustand zu einem bestimmten Zeitpunkt auf. Änderungen dem gegenüber entstehen als neuer Stand, ohne den alten zu überschreiben (copy on write). Alle zB 30 Sekunden wird ein neuer Stand auf Platte fixiert, indem der neue Root-Block geschrieben wird. Der alte Stand wird dann aufgeräumt, nun ungenutze Blöcke freigegeben usw. Bei einem Snapshots wird dieser alte Stand nicht f.goeivh reigegeben, sondern irgendwann später.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Copy-on-Write Filesystem wie btrfs oder ZFS zeichnen keine Deltas auf. > Snapshots sind darin quasi ein natürlicher Nebeneffekt ihrer normalen > Arbeitsweise. Das ist nicht bis zum Ende durchdacht. Ja, sie zeichnen kein expliziten Deltas auf. Aber implizit tun sie das natürlich sehr wohl. Wie sonst sollte das funktionieren können? Sprich effektiv wir nur die Rolle von "snapshot" und "present state" getauscht. Das hat natürlich enorme Vorteile. Ist aber auch nicht überzubewerten. Spätestens halt dann, wenn es darum geht zu jedem beliebigen Snapshot zurück gehen zu können, wird es zum Nachteil. Denn: der muß auch dann noch da sein...
Ob S. schrieb: > Dazu > wird zunächst der Snapshot aufgezeichnet. Nein, sie frieren den aktuellen Stand ein, und neues Zeugs wird woanders weitergeschrieben ...
:
Bearbeitet durch User
Ob S. schrieb: > Aber implizit tun sie das natürlich sehr wohl. Wie sonst > sollte das funktionieren können? Vorhin geschrieben. Jeder Stand hat seine vollständigen Metadaten, vom Root-Block bis zum Block-Mapping eines Files. Kennst du Backups via rsync mit Versionierung über Hardlinks? Das ist ein sehr grobes Analogon. Darin ist jeder Stand selbständig und es gibt keine Deltas.
:
Bearbeitet durch User
Ob S. schrieb: > Denn: der muß auch dann noch da sein... Da es keine Deltas gibt, ist das grob ähnlich wie beim erwähnten rsync. Der ist so lange da, bis man ihn wegräumt. Aufwand entsteht beim Löschen des Snapshots, weil alles abgeklappert wird und etwas erst dann gelöscht werden kann, wenn es mit keinem anderen Snapshot geteilt wird.
:
Bearbeitet durch User
Jens G. schrieb: > Ob S. schrieb: >> Dazu >> wird zunächst der Snapshot aufgezeichnet. > > Nein, sie frieren den aktuellen Stand ein, und neues Zeugs wird woanders > weitergeschrieben ... Genau das schrieb ich doch? Du hättest nur einfach nur zwei, drei Zeilen weiter lesen müssen.
Nicht verwechseln mit Snapshots bei Disk-Images von Hypervisorn, oder Snapshots in NTFS. Die arbeiten völlig anders. Der Schlüssel zum Verständnis ist das konsequent durchgezogene copy-on-write Prinzip. Dieses COW erzeugte zusätzlichen Aufwand und eine gegenüber anderen FS höhere Schreibaktivität. Ist aber nicht von der Anzahl der Snapshots abhängig.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Vorhin geschrieben. Jeder Stand hat seine vollständigen Metadaten, vom > Root-Block bis zum Block-Mapping eines Files. Ja, das ist mir vollkommen klar. Das Problem ist nur: Wie lange liegt all das im FS? Sicher nicht endlos. Und: wie kommt man zurück zu einem beliebigen Snapshot-Stand der Vergangenheit? > Kennst du Backups via rsync mit Versionierung über Hardlinks? Seit endlosen Zeiten. Hat aber eigentlich kaum was mit dieser Sache zu tun. > Das ist > ein sehr grobes Analogon. Darin ist jeder Stand selbständig und es gibt > keine Deltas. Aber natürlich gibt es auch hier Deltas (wie jedem mit den Grundlagen formaler Logik klar sein muss). Die stecken hier natürlich in den Meta-Informationen. Gibt's eine Datei "jetzt" nicht mehr, "früher" aber schon: sie wurde gelöscht. Usw. usf.
Ob S. schrieb: > In VM-Umgebungen benutzt man ihn oft als temporäres Backup mit der > Fähigkeit, davon ausgehend die VM sowohl zum aktuellen Stand zu > migrieren als auch zum Stand des Snaphots zurückkehren zu können. Völlig andere Baustelle! Hier geht es um Filesysteme. Sowas wie Snapshots über 6 Monate, 6 Wochen, 14 Tage, 36 Stunden ist bei entsprechenden Storage-Systemen völlig normal.
Ob S. schrieb: > Aber natürlich gibt es auch hier Deltas (wie jedem mit den Grundlagen > formaler Logik klar sein muss). Die stecken hier natürlich in den > Meta-Informationen. Gibt's eine Datei "jetzt" nicht mehr, "früher" aber > schon: sie wurde gelöscht. Usw. usf. Nein. Du hast lediglich das Grundprinzip nicht verstanden. Nicht bei COW Filesystemen und offensichtlich auch nicht bei rsync. Hier ist aber nicht der Raum, um dem abzuhelfen. Dein Argument mit der formalen Logik geht in die Irre, weil du dich nicht von der Arbeitsweise klassischer Filesysteme löst.
:
Bearbeitet durch User
Ob S. schrieb: > Und: wie kommt man zurück zu einem > beliebigen Snapshot-Stand der Vergangenheit? Indem man an Stelle des aktuellen Root-Blocks der Metadaten den Root-Block des Snapshots zu dem gewünschten Stand verwendet. Das ist alles.
:
Bearbeitet durch User
Ob S. schrieb: > Aber natürlich gibt es auch hier Deltas (wie jedem mit den Grundlagen > formaler Logik klar sein muss). Die Deltas sind aber (im Unterschied zu z.B. LVM-Snapshots) nicht als solche gespeichert. Du kannst dir aber nachträglich das Delta zwischen zwei Snapshots (so sie denn zur selben Versionshistorie gehören) berechnen lassen. >> btrfs send -p Das "Delta" kannst du dann archivieren, oder auf einem Zweit-System ins Dateisystem integrieren, sofern da auch die Ursprungsversion vorhanden ist.
Ob S. schrieb: > Wie lange liegt all das im FS? Sicher nicht endlos. So lange, bis man den Snapshot löscht. Das kann manuell erfolgen, oder automatisiert anhand Strategien wie bei klassischen Bandsicherungen.
(prx) A. K. schrieb: > Nein. Du hast lediglich das Grundprinzip nicht verstanden. Nicht bei COW > Filesystemen und offensichtlich auch nicht bei rsync. Hier ist aber > nicht der Raum, um dem abzuhelfen. Würde mich (und vermutlich auch andere) aber schonmal interessieren. Warum magst du deine Behauptungen nicht durch Fakten zu belegen? Zumindest erstmal für rsync. Das scheinst du ja wenigstens schonmal benutzt zu haben. Und damit liessen sich ja auch ganz easy die entsprechenden Testfälle herstellen. Drei, vier kleine Textdateien und los geht's. Dann änderst du eine davon, löschst eine davon und fügst eine hinzu. Und postest dann das Image von vor und nach der Änderung. Sollte natürlich auf einem sehr kleinen Test-FS passieren, damit der Datenaustausch des Image über das Forum den Forenbetreiber nicht über Gebühr in Anspruch nimmt. Muß aber natürlich ein FS sein, welches Hardlinks unterstützt. Ich mache mich auf jeden Fall anheischig, dir anhand der beiden Images dann zu zeigen, wo genau das Diff steckt. Für jedes einzelne verschissene Byte. Auch (und gerade) weil ich deiner Meinung nach das Grundprinzip nicht verstanden hätte...
Εrnst B. schrieb: > Das "Delta" kannst du dann archivieren, oder auf einem Zweit-System ins > Dateisystem integrieren, sofern da auch die Ursprungsversion vorhanden > ist. Woraus sich ganz natürlich ein Sekundärsystem ergibt, das auf Basis billiger SATA HDDs Stände über Monate aufbewahrt, während das mit teuren SSDs arbeitende Primärsystem die Snapshots nur kurz aufbewahrt.
Ob S. schrieb: > Warum magst du deine Behauptungen nicht durch Fakten zu belegen? Wie soll das aussehen? Führung durch die Bits vom WAFL einer NetApp? Ich arbeite mit den Dingern zwar, komme damit ganz gut zurecht bis hin zum Verständnis auch der Nachteile (Fragmentierung etwa), aber nicht bis runter aufs Bit. Die Familie von COW Systemen hat aufgrund dieser Arbeitsweise deutliche Ähnlichkeiten, aber auch Unterschiede. Ich kenne natürlich den Reflex, sich gegen zunächst unverständliche und widersprüchlich scheinende Informationen zu wehren. Geht mir manchmal auch so. Das ist nun der Stand der Diskussion. Weshalb ich nicht viel Sinn darin sehe, das weiter zu führen. Mach was draus, oder lass es. Den Charakter von emotionellen Politikdiskussionen oder Boxkämpfen mit Gewinner und Verlierer muss das nicht kriegen. Das rsync war der Versuch einer sehr groben Analogie. Das er nicht funktioniert hat, werde ich dies nicht weiter verfolgen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Nicht verwechseln mit Snapshots bei Disk-Images von Hypervisorn, oder > Snapshots in NTFS. Die arbeiten völlig anders. Der Schlüssel zum > Verständnis ist das konsequent durchgezogene copy-on-write Prinzip. Die arbeiten eben nicht "völlig anders" sondern nur sozusagen genau "umgekehrt", zumindest was die Snaphot-Geschichte angeht. Und, da das bis zum Aufkommen der Virtualisierung auch OK so war, tun das die damaligen FS auch heute noch. Ich würde behaupten, dass heut noch die weit überwiegende Mehrheit der Guests mit einem FS arbeitet, was nicht COW ist. Und übrigens ist ja auch keinesfalls so, dasss COW-FS nur Vorteile hätten. Dem ist nicht so. Natürlich haben sie Vorteile, speziell in virtuellen Umgebungen. Aer sie haben eben auch Nachteile.
Ob S. schrieb: > Ich würde behaupten, dass heut > noch die weit überwiegende Mehrheit der Guests mit einem FS arbeitet, > was nicht COW ist. Da wirst du Recht haben. Und? Der Thread fing explizit mit btrfs an, und damit mit einer Minderheit.
Ob S. schrieb: > Aer sie haben eben auch Nachteile. Natürlich. Etwa eine massive Neigung zu Fragmentierung von DB Tablespaces, die auf einem alten System schon nach Tagen zu erheblichem Anstieg der Backup-Zeit führte und regelmäßige Defragmentierung sinnvoll machte. Dank SSDs ist das aber kein Thema mehr. Und btrfs hat eben deshalb die Option, gezielt vom COW Verfahren abzuweichen. Die gegenüber traditionellen Systemen deutlich höhere Schreiblast erwähnte ich auch bereits.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ob S. schrieb: >> Warum magst du deine Behauptungen nicht durch Fakten zu belegen? > > Wie soll das aussehen? Hatte ich (doch ziemlich exakt und umißverständlich) beschrieben. Basierend auf deiner rsync-Vorlage, damit's einfach und überschaubar bleibt. > Das rsync war der Versuch einer sehr groben Analogie. Das er nicht > funktioniert hat, werde ich dies nicht weiter verfolgen. Das hat nur nicht nicht in deinem Sinne zum Zwecke deiner Argumentation funktioniert. Zum Glück ist dir das klar geworden, bevor du dich in weitere Peinlichkeiten begeben hast. Das hat mir Arbeit gespart und dem Forumsbetreiber nutzlosen Traffic. Aber, das das "rsync-Analogon" nunmehr vom Tisch ist, kommen wir zu den harten Sachen. Dasselbe Spiel also mit einem extrem kleinen (!) BTRFS oder ZFS. Wieder wäre ich bereit, die Deltas dort rauszufischen. Wird aber weder möglich noch nötig sein, denn genau da knallt es bei den COW-FS extrem schnell. Klein mögen die garnicht. Was natürlich angesichts der Funktionsweise nicht sehr überraschend ist... Ja klar, deiner Meinung nach verstehe ich ja sowieso garnichts davon... Also wayne interessierts...
Zu ergänzen wäre nur noch, dass nicht jeder, der fleißig Backups gemacht hat, sie auch alle wieder fehlerfrei und schnelllll zurückspielen kann.
Lu schrieb: > Zu ergänzen wäre nur noch, dass nicht jeder, der fleißig Backups gemacht > hat, sie auch alle wieder fehlerfrei und schnelllll zurückspielen kann. Auch anzumerken ist aber, das jemand, der kein Backup gemacht hat, es auch definitiv nicht wieder zurückspielen kann. Klingt trivial, wird aber doch gerne vergessen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.