Gedanken zu BTRFS

[marce]

Ganz einfach. Ein Dateisystem, das weniger unnütze Daten schreibt bzw. generiert, arbeitet effizienter.

In dieser Aussage steckt schon der 1. Fehler.

*Angenommen: Die Nutzung von BTRFS "würde" die Lebensdauer eines Datenträgers signifikant vermindern.

Das tut in Deiner Definition jedes Dateisystem, welches CopyOnWrite oder ähnliche Technologien zur Konsistenzsicherung, Transaktionshandling und anderen modernen Features verwendet.

Und weißt Du was? Für SSD z.B wäre es sogar nachteilig, immer die gleichen Datenbereich zu überschreiben. Und bei "realen" HDs dank intelligenter Controller, Caches und schlauer Datenspeicherung anhang Geometrie und anderer Hardwarefaktoren auch,

Dann würde ich mir den Einsatz schwer überlegen.

Mach das. Diese Metrik ist aber leider nicht praxisrelevant. Wichtiger bei der "richtigen" Wahl eines Dateisystems sind ganz andere Eigenschaften.

Das geht schon so weit dass ich mir irgendwelche Tests überlege.

Dann überlege Dir Tests, die in der Praxis wirklich relevant sind oder die das Dateisystem wirklich fordern. Und nein, mit Deinen 5GB Daten in ein paar Tausend Dateien brauchst Du da gar nicht anfangen.
Da ist auch die Wahl des Dateisystems völlig Wumpe.

Iinteressant wird das alles ein paar Potenzen größer...

 

[revealed]

In dieser Aussage steckt schon der 1. Fehler.

Das wenn ich etwas lösche 30 MB mehr Daten über die Schnittstelle gerannt sind?

Das tut in Deiner Definition jedes Dateisystem, welches CopyOnWrite oder ähnliche Technologien zur Konsistenzsicherung, Transaktionshandling und anderen modernen Features verwendet.

Ist immernoch nicht angekommen, dass ich zahlen sehen will die das Wiederlegen. Sonst hätte ich den Thread nicht offen.

Und weißt Du was? Für SSD z.B wäre es sogar nachteilig, immer die gleichen Datenbereich zu überschreiben. Und bei "realen" HDs dank intelligenter Controller, Caches und schlauer Datenspeicherung anhang Geometrie und anderer Hardwarefaktoren auch,

Das ist für mich jetzt hier im Thema völlig aus dem Zusammenhang gerissen. (Zwischen den Zeilen gelesen).

Iinteressant wird das alles ein paar Potenzen größer...

Das ist auch für mich nichts neues.

Mach das. Diese Metrik ist aber leider nicht praxisrelevant. Wichtiger bei der "richtigen" Wahl eines Dateisystems sind ganz andere Eigenschaften.

Den Beweis hast du leider immernoch nicht angetreten.

Dann überlege Dir Tests, die in der Praxis wirklich relevant sind oder die das Dateisystem wirklich fordern. Und nein, mit Deinen 5GB Daten in ein paar Tausend Dateien brauchst Du da gar nicht anfangen.

Ich habe schon erwähnt --- und komme mir langsam vor wie eine kaputte Schallplatte wenn ich sage, ich hätte bitte gerne das jemand so einen Test macht.

Vielen Dank!

Gruß,

R

 

[marce]

Nein. Mag sein, daß das so ist. Wäre aber egal.

... der Fehler steckt in der Grundaussage, daß die Effizienz des Dateisystems etwas mit dem Verhältnis von logischer zu technischer Datenmenge zu tun hätte. Oder von netto zu brutto-Datenübertragung.

 

[josef-wien]

Du bist neugierig, aber gleichzeitig hat eine fixe Idee von Dir Besitz ergriffen. Ich kann Dir bei der Lösung nicht helfen, die in den Interna der Dateisysteme liegt, mit denen Du Dich beschäftigen mußt. Die gespeicherten Daten sind irrelevant, die sind nur Mittel zum Zweck. Entscheidend für die Effizienz eines Dateisystems ist dessen innere Struktur, ist die Abbildung jener Informationen, um das zu identifizieren, was aus Sicht des Benutzers eine Datei genannt wird.

Vergiß dabei nicht, daß jede Festplatte, bestehe sie intern aus rotierenden Scheiben oder bewegungslosen Speicherzellen oder woraus auch immer, ein eigenständiger Computer mit eigenem Prozessor und eigenem Betriebssystem ist. Dein PC kann Anforderungen an die Festplatte richten, wie sie sie ausführt, bestimmt sie selbst. Ein Dateisystem ist ausschließlich eine logische Sicht auf die Daten. Für die physische Abbildung der Daten ist die Festplatte zuständig, für die Begriffe wie Partition, Verzeichnis oder Datei völlig unbekannt sind, sie kennt nur Sektoren.

Zur Beschäftigung Deiner fixen Idee lege ich noch etwas darauf: Unter dem Gesichtspunkt "so wenig Schreibvorgänge wie möglich" arbeitet jedes Dateisystem mit Journal äußerst ineffizient, da ein Journal nur eine Vorsorgemaßnahme zur Behebung "kleiner" Katastrophen ist.

 

[Bequimão]

Schließlich muß man alle Subvolumes einrichten und vor dem Kopieren mounten

Entzieht sich meiner Logik, wenn man (RAW Daten) kopiert. Mal abgesehen vom Bootsektor.

Das kopiert es doch alles mit, wenn du die komplette sda in ein Image schiebst. Nicht?
...

R
...

Ich habe schon einmal eine LVM-Gruppe mit mehreren Installationen durch Unvorsichtigkeit verloren. Deswegen will ich zumindest mein Hauptsystem als Image auf einer externen Platte sichern. Kopieren mit dd dauert mir zu lange. Außerdem brauche ich die Snapshots und den Bereich, den btrfs für zukünftige Dateisystemerweiterung vorhält, nicht zu kopieren. Bei LVM muß man außerdem sowieso nach der Wiederherstellung in das System chrooten und grub neu installieren.

Die Scripts zu erstellen ist keine große Sache, nur Fleißarbeit. Das habe ich gerade für Mageia 6 (Cauldron) erstellt und erfolgreich ausgeführt. Dort wird direkt in das root-Subvolume installiert, was ziemlich ungünstig ist, da man dieses Subvolume nie löschen kann. Die Sicherungskopie kann also auch mit ext4 geschehen. btrfs verwende ich für Sicherungen nicht.

Viele Grüße
Bequimão