staging.inyokaproject.org

Moin,

rein zur Information, Videos zu btrfs und subvolumen anschaulich erklärt! Vielleicht ist es für den einen oder anderen interessant.

• https://youtu.be/4oCVBUnNwEA

• https://youtu.be/E_qABG9-jlw

• https://youtu.be/mADYj9O50oQ

• https://youtu.be/P6r7vTWMn5Y

peace

Deduplizierung auf Blockebene kann eine ganze Menge einsparen. Kommt immer auf die Daten an... z.B. Digital-Bilder von denen man Kopien hat, in denen nur die Meta-Daten anders sind. Oder das selbe mit MP3s, Kopien mit anderen Meta-Daten.

Auf meinen Windows Server hab ich Deduplizierung eingeschaltet. Auf der 4TB Platte (mit 3TB Daten) habe ich 880GB Einsparung durch Duplizierung. Ich arbeite viel mit Dateien-Kopien, die sich nur wenig ändern.

Zu sehen, wie viel man durch Deduplizierung und Kompression spart, ist Sinnvoll, damit man erkennen kann, ob es überhaupt was bringt. Einschalten und nicht wissen, was es bewirkt, ist doch blöd.

jedie schrieb:

Ich arbeite viel mit Dateien-Kopien, die sich nur wenig ändern.

Auf einem COW Dateisystem wie btrfs oder auch ZFS könnte man auf der anderen Seite auch einfach mit Snapshots arbeiten. Einige Container tools machen es so und sparen erheblich Platz weil sich ausgehend vom Template / Golden Image nur selten was ändert.

Zu sehen, wie viel man durch Deduplizierung und Kompression spart, ist Sinnvoll, damit man erkennen kann, ob es überhaupt was bringt. Einschalten und nicht wissen, was es bewirkt, ist doch blöd.

Gegenwärtig ist Deduplizierung noch relativ rudimentär in btrfs, es geht weder In-Band noch hat man nützliche Monitoring Tools dafür.

mfg Stefan Betz

encbladexp schrieb:

Gegenwärtig ist Deduplizierung noch relativ rudimentär in btrfs, es geht weder In-Band noch hat man nützliche Monitoring Tools dafür.

Vollkommen richtig. Bei meinem letzten Test vor ein paar Monaten habe ich mal eine große Mediendatei (ein paar GB) genommen und mit

cp --reflink file file.copy

kopiert. Das hat in der Tat keinen weiteren physischen Speicherplatz belegt. Aber bis zu dieser Stelle hätte ich auch einfach einen Hardlink nehmen können. Dann habe ich die Kopie im Hexeditor geöffnet und ein Bit gekippt. Resultat: Die komplette Datei wurde dupliziert, nicht etwa nur der entsprechende Block.

unbuntuS12 schrieb:

Dann habe ich die Kopie im Hexeditor geöffnet und ein Bit gekippt. Resultat: Die komplette Datei wurde dupliziert, nicht etwa nur der entsprechende Block.

Weil beim Speichern die Datei komplett neu geschrieben wurde. Da btrfs keine In-Band-Deduplizierung bietet ist das soweit auch logisch (ließe sich aber durch ausführen von duperemove oder bedup beheben).

Du kannst alternativ auch dd in Verbindung mit conv=notrunc nutzen, um beispielsweise nur das erste Megabyte einer größeren Datei zu überschreiben. Dann wird auch nur das neu geschrieben, der Rest bleibt gleich (d.h. dieser wird auch nicht dupliziert).

Developer92 schrieb:

Da btrfs keine In-Band-Deduplizierung bietet ist das soweit auch logisch (ließe sich aber durch ausführen von duperemove oder bedup beheben).

Wo du's sagst, fällt's mir wieder ein - mit duperemove habe ich gearbeitet. Ich glaube, der Punkt an dem ich aufgegeben habe, war, als duperemove über diese beiden Dateien trotzdem keinen einzigen Block dedupliziert hat. Aber ich kann's echt nicht mehr genau sagen. Hatte es jedenfalls intensiv getestet und dann unter "geht noch nicht" abgehakt.

Moin,

mein Stand ist das btrfs so wie es in den Video https://forum.ubuntuusers.de/topic/btrfs-aktueller-stand/3/#post-8493968 zu sehen doch brauchbar ist und auch von mir genutzt wird.

Aber! auf einem Serversystem würde ich es nicht haben wollen, da nutzte ich lieber ext4 und einen guten Datensicherungsplan. Soweit mein Kenntnissstand ist btrfs im Raid 5/6 auch immer noch nicht besser geworden Also ein gewisser Stillstand?

Gerade auf Servern finde ich btrfs sehr nett: Container und Backups.

Container weil systemd-nspawn oder auch einige andere sehr gut damit auskommen, noch nie war es billiger neue Instanzen eines Dienstes zu haben.

Backups, weil ein einfaches rsync von A=>Backup schnell geht, aber das lästige rsync mit Hardlinks Ewigkeiten braucht. Bei btrfs einfach einen Snapshot erstellt, dauert keine Sekunde und erreicht das gleiche wie ein rsync mit Hardlinks. Dazu kann man mit btrfs-send/recieve auch prima die Änderungen an die Gegenstelle übertragen, ohne das rsync die CPU Minutenlang quälen muss. Dein Dateisystem weiß ja was sich geändert hat, und muss nicht raten.

mfg Stefan Betz

encbladexp schrieb:

Gerade auf Servern finde ich btrfs sehr nett: Container und Backups.

Container weil systemd-nspawn oder auch einige andere seh................... mfg Stefan Betz

Moin,

na gut da bin ich inzwischen raus seit einigen Jahren aber btrfs nur mit Raid 0/1. Lieg ich da auch falsch?

peace

Edit:Ja mit snapshot ist OK, man kann sogar damit booten.

unbuntuS12 schrieb:

Hatte es jedenfalls intensiv getestet und dann unter "geht noch nicht" abgehakt.

Komisch - duperemove liest ja nur die Hashsumme der einzelnen Blöcke ein und gibt Duplikate dann an den Kernel weiter. Das macht selber gar nicht so viel.

V0LKER schrieb:

Soweit mein Kenntnissstand ist btrfs im Raid 5/6 auch immer noch nicht besser geworden

Eher schlechter^^

Mittlerweile hat man ein paar gravierende Bugs im Code der RAID56 Implementierung gefunden, wenn ich das richtig verstanden habe wird der Code hierfür als broken beyond repair angesehen. RAID56 muss also nochmal neu implementiert und stark überdacht werden. Und hoffentlich wird dabei auch das berühmt berüchtigte write hole umgangen, welches es bei ZFS beispielsweise auch nicht gibt (wobei ich jetzt auch nicht sagen kann, ob die das für alle RAID-Level entsprechend implementiert haben oder ob das nur für einen spezielle/ein paar Level gilt. Weiß da jemand mehr?).

Developer92 schrieb:

Mittlerweile hat man ein paar gravierende Bugs im Code der RAID56 Implementierung gefunden, wenn ich das richtig verstanden habe wird der Code hierfür als broken beyond repair angesehen. RAID56 muss also nochmal neu implementiert und stark überdacht werden. Und hoffentlich wird dabei auch das berühmt berüchtigte write hole umgangen, welches es bei ZFS beispielsweise auch nicht gibt (wobei ich jetzt auch nicht sagen kann, ob die das für alle RAID-Level entsprechend implementiert haben oder ob das nur für einen spezielle/ein paar Level gilt. Weiß da jemand mehr?).

Moin,

Raid 0 läuft bei mir mit 2 SSD bislang ohne Probleme, allerdings ist das ganze eine reine private Nutzung, also kein Streß im System.

peace

V0LKER schrieb:

Moin,

Raid 0 läuft bei mir mit 2 SSD bislang ohne Probleme, allerdings ist das ganze eine reine private Nutzung, also kein Streß im System.

Raid 0 sollte auch problemlos laufen, nur Raid 5/6 bereitet wie gesagt Probleme.

Es gibt da übrigens seit ein paar Tagen eine nette Statusseite welceh den Stand der aktuellen Implementierung zeigt: Klick

Moin,

danke für den Link!

ich liste hier mal meine konfiguration mit 2 SSD's

$ sudo btrfs filesystem usage /

Overall:
    Device size:                 448.20GiB
    Device allocated:             97.06GiB
    Device unallocated:          351.14GiB
    Device missing:                  0.00B
    Used:                         93.80GiB
    Free (estimated):            354.01GiB      (min: 354.01GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              240.00MiB      (used: 0.00B)

Data,RAID0: Size:96.00GiB, Used:93.13GiB
   /dev/sda4      48.00GiB
   /dev/sdb1      48.00GiB

Metadata,RAID0: Size:1.00GiB, Used:685.20MiB
   /dev/sda4     512.00MiB
   /dev/sdb1     512.00MiB

System,RAID0: Size:64.00MiB, Used:16.00KiB
   /dev/sda4      32.00MiB
   /dev/sdb1      32.00MiB

Unallocated:
   /dev/sda4     166.79GiB
   /dev/sdb1     184.35GiB

und subvolume

$ sudo btrfs subvolume list -p .
ID 258 gen 2315 parent 5 top level 5 path @
ID 259 gen 2314 parent 5 top level 5 path @home
ID 262 gen 2280 parent 5 top level 5 path @Daten
ID 264 gen 2142 parent 5 top level 5 path @pkg
ID 265 gen 2142 parent 5 top level 5 path @snapshots
ID 397 gen 1469 parent 265 top level 265 path @snapshots/OLDSTABLE
ID 400 gen 1478 parent 265 top level 265 path @snapshots/STABLE
ID 401 gen 1480 parent 265 top level 265 path @snapshots/HOME_STABLE
ID 402 gen 1480 parent 265 top level 265 path @snapshots/DATEN_STABLE

Die snapshot lassen sich ebenfalls booten. Weiter läuft noch ein backup auf einer externen Platte leider klappt es nicht System-snapshots auf der externen zu hinterlegen. Man könnte es nur aufwendig kopieren. Es ist auch nicht vorgesehen snapshots auf ext. Datenträger zu erstellen. Ansonsten kann man btrfs schon einsetzen zumindest mit kernel 4.4.x.

peace

Edit:Starten/booten von verschiedenen Desktopsoberflächen über snapshots problemlos, es kommt sich keiner in die Quere, was ja gerne mal zwischen gtk und Qt passiert (seit neustem).