es ist schade, dass die Enticker so an der Kernelintegration vorbei entwickelt haben. Snaps auf Dateissystembasis hätte in machen Situationen ihren Vorteil. Insbesondere wenn sie 'fest' gespeichert werden könnten.
Backups könnten online im 'normalen' Betrieb gezogen werden, da des Dateisystemsand mittels Snaps eingefroren werden kann. Zu Glück uns steht diese Möglichkeit mit LVM schon seit Jahren zur Verfügung und das auch noch äußerst Performant. Wahrscheinlich werden die weiteren Features in den nächsten Jahren auch bei ext4, ext5, .... auftauchen.
Zu Glück uns steht diese Möglichkeit mit LVM schon seit Jahren zur Verfügung und das auch noch äußerst Performant
Wäre schön, wenn dem so wäre. Aber hier (im Privatbereich) bricht die Performance jedesmal ein, wenn ich einenen neuen Snaphost zum wegsichern aufmache.
Die Performance von Schreiboperationen bei LVM ist eine Katastrophe (=1/3), sobald Snapshots gemacht wurden. In einigen Fällen ist dies nicht weiter tragisch, aber im Allgemeinen punkten genau da BTRFS, ZFS und jetzt vielleicht auch NEXT3.
Hmm, Backup auf Snapshot-Basis hab ich noch nie für eine besonders gute Idee gehalten. Sebst im Privatbereich hat man da das Problem mit Inkonsistenzen, und sei es nur die .lock-Datei vom gerade laufenden Firefox. Im professionellen Umfeld (insbes. Datenbanken) ist das erst recht nichts wert.
Also ein Snapshot kann eine Backupzeit verkürzen, da zwischen /etc/init.d/anwendung stop und [..] start nur der Snapshot steht, aber einen größeren Nutzen hab ich da noch nicht gesehen. Und für ein Backup auf diese Art tuts auch LVM-Snapshot oder eine Snap-Funktion des Filers.
Das musst du mir erklären. Angenommen eine DB hat gerade eine laufende Transaktion und von der schon x von y Bytes geschrieben, in dem Moment wird ein Snap auf Filesystemebene gemacht. Wo ist da die Konsistenz? Man kann sicher durch das Transaktionslog wieder einen konsistenten Zustand herstellen, aber von einer Garantie seh ich da nix.
HotBackups sind in vielen Bereichen gerade nur durch Volumen Snapshots möglich. Oft werden diese direkt durch das Storagesystem zur Verfügung gestellt oder eben mittels VolumeManager (LVM, etc.) erzeugt.
Scheinbar hast du bei Snapshots einiges falsch verstanden. Gerade im professionellen Bereich, in welchem ich kein tägliches Wartungsfenster etc. habe könnte ich mir nicht vorstellen, ein Backup ohne Snapshots zu betreiben.
Ich hab mich da etwas ungenau ausgedrückt, klar sind snapshots sinnvoll beim Backup, wo ich noch keinen echten Nutzen erkannt habe sind nur bei snapshots auf Filesystemebene, oder Snapshots die ohne Zusammenspiel mit dem System erzeugt werden. Wie z.B. einige Kunden auf die Snapshot-Funktion der Netapps vertrauen ohne dass dafür gesorgt wird, dass der Filer den Snap in einem passenden/konsistenten Moment erzeugt.
...damit ist der Krams doch quasi schon wieder tot. Wenn jemand Next3 produktiv ausliefern will muss er sich erst selbst um die laufende Einarbeitung der Patches in den Kernel und User-Space kümmern, und später die Wartung eines nicht mehr entwickelten Dateisystems übernehmen.
An diesem Problem ist ja Reiser4 letztendlich auch gescheitert, und das versprach immerhin mehr als nur ein einziges neues Feature.
Im Moment geht die Reise klar in Richtung btrfs, aber das heißt doch nicht, dass ein wenig Konkurrenz nicht förderlich sein könnte.
Mal sehen, vielleicht entwickelt es sich überraschenderweise so dynamisch zum Positiven, dass es doch noch Verbreitung und/oder Zuspruch bei den Kernel-Entwicklern findet. Wenn nicht, ist es ja auch nicht schlimm, man kann auch aus Projekten lernen, die sich nicht durchsetzen konnten.
Wenn ich die Diskussion auf der Kernel-Entwickler-Liste richtig verfolgt habe, wird der Entwickler von next3 längerfristig daran arbeiten, den Krams in ext4 zu importieren. Einige Änderungen hat er bereits am Code vorgenommen, um Baustellen zu beheben, die bemängelt wurden.
Moin Moin,
es ist schade, dass die Enticker so an der Kernelintegration vorbei entwickelt haben. Snaps auf Dateissystembasis hätte in machen Situationen ihren Vorteil. Insbesondere wenn sie 'fest' gespeichert werden könnten.
Backups könnten online im 'normalen' Betrieb gezogen werden, da des Dateisystemsand mittels Snaps eingefroren werden kann. Zu Glück uns steht diese Möglichkeit mit LVM schon seit Jahren zur Verfügung und das auch noch äußerst Performant. Wahrscheinlich werden die weiteren Features in den nächsten Jahren auch bei ext4, ext5, .... auftauchen.
MfG
mawa
Zu Glück uns steht diese Möglichkeit mit LVM schon seit Jahren zur Verfügung und das auch noch äußerst Performant
Wäre schön, wenn dem so wäre. Aber hier (im Privatbereich) bricht die Performance jedesmal ein, wenn ich einenen neuen Snaphost zum wegsichern aufmache.
Die Performance von Schreiboperationen bei LVM ist eine Katastrophe (=1/3), sobald Snapshots gemacht wurden. In einigen Fällen ist dies nicht weiter tragisch, aber im Allgemeinen punkten genau da BTRFS, ZFS und jetzt vielleicht auch NEXT3.
Hmm, Backup auf Snapshot-Basis hab ich noch nie für eine besonders gute Idee gehalten. Sebst im Privatbereich hat man da das Problem mit Inkonsistenzen, und sei es nur die .lock-Datei vom gerade laufenden Firefox. Im professionellen Umfeld (insbes. Datenbanken) ist das erst recht nichts wert.
Also ein Snapshot kann eine Backupzeit verkürzen, da zwischen /etc/init.d/anwendung stop und [..] start nur der Snapshot steht, aber einen größeren Nutzen hab ich da noch nicht gesehen. Und für ein Backup auf diese Art tuts auch LVM-Snapshot oder eine Snap-Funktion des Filers.
Snapshots garantieren Konsistenz auf Filesystem-Ebene, was besonders bei Datenbanken wichtig ist.
Das musst du mir erklären. Angenommen eine DB hat gerade eine laufende Transaktion und von der schon x von y Bytes geschrieben, in dem Moment wird ein Snap auf Filesystemebene gemacht. Wo ist da die Konsistenz? Man kann sicher durch das Transaktionslog wieder einen konsistenten Zustand herstellen, aber von einer Garantie seh ich da nix.
HotBackups sind in vielen Bereichen gerade nur durch Volumen Snapshots möglich. Oft werden diese direkt durch das Storagesystem zur Verfügung gestellt oder eben mittels VolumeManager (LVM, etc.) erzeugt.
Scheinbar hast du bei Snapshots einiges falsch verstanden. Gerade im professionellen Bereich, in welchem ich kein tägliches Wartungsfenster etc. habe könnte ich mir nicht vorstellen, ein Backup ohne Snapshots zu betreiben.
Ich hab mich da etwas ungenau ausgedrückt, klar sind snapshots sinnvoll beim Backup, wo ich noch keinen echten Nutzen erkannt habe sind nur bei snapshots auf Filesystemebene, oder Snapshots die ohne Zusammenspiel mit dem System erzeugt werden. Wie z.B. einige Kunden auf die Snapshot-Funktion der Netapps vertrauen ohne dass dafür gesorgt wird, dass der Filer den Snap in einem passenden/konsistenten Moment erzeugt.
...damit ist der Krams doch quasi schon wieder tot. Wenn jemand Next3 produktiv ausliefern will muss er sich erst selbst um die laufende Einarbeitung der Patches in den Kernel und User-Space kümmern, und später die Wartung eines nicht mehr entwickelten Dateisystems übernehmen.
An diesem Problem ist ja Reiser4 letztendlich auch gescheitert, und das versprach immerhin mehr als nur ein einziges neues Feature.
Im Moment geht die Reise klar in Richtung btrfs, aber das heißt doch nicht, dass ein wenig Konkurrenz nicht förderlich sein könnte.
Mal sehen, vielleicht entwickelt es sich überraschenderweise so dynamisch zum Positiven, dass es doch noch Verbreitung und/oder Zuspruch bei den Kernel-Entwicklern findet. Wenn nicht, ist es ja auch nicht schlimm, man kann auch aus Projekten lernen, die sich nicht durchsetzen konnten.
Wenn ich die Diskussion auf der Kernel-Entwickler-Liste richtig verfolgt habe, wird der Entwickler von next3 längerfristig daran arbeiten, den Krams in ext4 zu importieren.
Einige Änderungen hat er bereits am Code vorgenommen, um Baustellen zu beheben, die bemängelt wurden.