btrfs

[ulukay]

ich hoffe mal alle stammposter im linux forum kennen es
gibts vielleicht auch leute die das aktiv nutzen?
ich bau mir grad einen backupserver auf, auf dem ich es nutzen werde.
die moeglichkeit simpel snapshots anzulegen gefaellt mir

das 1x die woche ins crontab

btrfs subvolume delete /backup/.other_weekly3
mv /backup/.other_weekly2 /backup/.other_weekly3
mv /backup/.other_weekly1 /backup/.other_weekly2
btrfs subvolume snapshot /backup/other /backup/.other_weekly1

und schon rennts

drwxr-x--- 1 othback root 42 Mar 11 17:36 other
drwxr-x--- 1 othback root 42 Mar 11 17:36 .other_weekly1
drwxr-x--- 1 othback root 42 Mar 11 17:36 .other_weekly2
drwxr-x--- 1 othback root 42 Mar 11 17:36 .other_weekly3

ebenso das checksumming finde ich gut, vor allem wenn man mit btrfs einen mirror aufbaut. dann gibts nie mehr korrupte daten die ohne fehlermeldung geliefert werden
bin mal gespannt wie stabil das sein wird. ich mach jeden tag nen snapshot (7 tage lang), jede woche (3 wochen lang) und jeden monat (3 monate lang)

 

[Colttt]

naja gibt verschiedene meinungen dazu..

debianforum.de • Thema anzeigen - btrfs

 

[ulukay]

naja, zfs ist auf x86 keine alternative.

 

[wodim]

ich hoffe mal alle stammposter im linux forum kennen es
gibts vielleicht auch leute die das aktiv nutzen?

Ich kenne es seit gestern. Vom ersten Eindruck her: Läuft fix und stabil. Ohne "Haken", will ich mal sagen, wenn auch noch nicht ganz ohne "Ecken und Kanten". Die erste war (nach der Umstellung einer 200GiB - Partition mit vielleicht 10GiB Dateien drauf von ext3 auf btrfs), dass das Image des alten Dateisystems mir genauso groß angezeigt wurde wie die ganze Partition und sich absolut nicht löschen ließ (die Datei schon, aber das Verzeichnis nicht, es heißt immer, es wäre noch nicht leer).

Nächstes Problem: Die Komprimierung. Hab's so gemountet:

mount -o compress /dev/sdb3 /Data

Aber komprimiert wird definitv nichts. Das in bewährter Manier in der fstab funktioniert gar nicht:

# <file system> <mount point> <type> <options> <dump> <pass>
UUID=....   /Data    btrfs    compress    0   0

Was habe ich da falsch gemacht?

 

[ulukay]

naja nur neu geschriebene daten werden komprimiert

 

[wodim]

naja nur neu geschriebene daten werden komprimiert

Das habe ich auch schon probiert, funktioniert das bei dir? Bei mir nicht, also irgendwas muss da schief gelaufen sein. Ich nehme an, schon bei der Konvertierung. Darauf deutet ja auch das Problem mit dem automatisch angelegten Snapshot hin. Und dass die Partiton sich zwar "händisch" mounten lässt, aber nicht mittels fstab.

Was sehen wir denn da:

blkid
... 
/dev/sdb3: UUID="3877ee3d-5af2-4acc-bbd8-0b99a4c3a1b5" UUID_SUB="6e515bd2-9332-4202-898f-f4e4cba48786" TYPE="btrfs"

Zwei UUIDs? Welcher ist nun der "richtige"? Kann es sein, dass einer für das alte, einer für das neue Dateisystem gilt? (Aber keiner stimmt mit dem alten überein) ...

 

[ulukay]

naja compress funzt bei mir 100%ig
Data: total=257.01GB, used=255.81GB
danach 10gb 0en in ne datei geschrieben
Data: total=257.01GB, used=256.12GB

mit du -sh sind insgesamt 277gb daten drauf (recht schwer komprimierbare)
btw. er kompimiert ja auch ned alle dateien sondern nur dateien von denen man weiss dass die komprimiertbar sind. wenn du mp3s, filme oder archive draufkopierst dann isser so intelligent und versuchts garned zu komprimieren

zwecks konvertierung ... da kann ich wohl nix weiterhelfen, hab noch nie ein fs konvertiert.
du kannst immer noch mit ner livecd booten, deine root partition taren, die parititon sauber mit btrfs formatieren und das tar entpacken

 

[wodim]

Jo, ich habe die Partition neu formatiert, jetzt geht's. Auch das Mounten per fstab. Nur beim Kopieren den falschen UUID erwischt.

Wie lange arbeitest du jetzt schon damit, welche Erfahrungen hast du betreffs Stabilität? Im Netz liest man fast nur Warnungen.

Vorweg gleich eine Warnung: btrfs ist definitiv noch nicht stabil! Ich habe während meiner Experimente mit btrfs zwar keine Daten verloren, aber mehrere Kernelabstürze ausgelöst (zugegebenermaßen oft aus Unverständnis über btrfs-Konzepte). In der btrfs-Mailingliste berichten nahezu jede Woche btrfs-Tester und -Entwickler über Dateisysteme, die sich plötzlich nicht mehr nutzen lassen (mount funktioniert nicht mehr), Kernelmeldungen mit Prüfsummenfehlern etc. Vertrauen Sie btrfs keine Daten an, zu denen Sie nicht aktuelle Backups besitzen!

Insbesondere warnt die btrfs-Website, dass ein plötzlicher Stromausfall oder Absturz zur unwiderruflichen Zerstörung des Dateisystems führen kann. Ein Teil des Problems besteht darin, dass es für btrfs noch kein funktionierendes fsck-Kommando gibt. btrfsck führt zwar einen recht simplen Integritätstest durch, kann ein kaputtes Dateisystem aber nicht reparieren.

Michael Koflers Blog | kofler.info

Na gut, das hat er vor einem halben Jahr geschrieben. Ich arbeite mit Linux Mint 9 (Kernelversion 2.6.32-29), und obwohl auch mich z.B. gparted warnt "BTRFS wird noch nicht unterstützt", ist noch nichts passiert. Gut, in zwei Tagen.

 

[ulukay]

seit 9 tagen
jeden tag wird mit rdiff-backup dorthin gebackupt und ein snapshot gezogen.
wenn das FS hops geht dann fehlt halt mein backup ... wayne

 

[wodim]

wenn das FS hops geht dann fehlt halt mein backup ...

Ähm, darf ich mal korrigieren:

wenn das FS hops geht dann fehlt halt auch mein backup ...

Dann ist also alles im Eimer, oder? Lebst ziemlich gefährlich, würde ich sagen.

 

[ulukay]

Ähm, darf ich mal korrigieren:

Dann ist also alles im Eimer, oder? Lebst ziemlich gefährlich, würde ich sagen.

noe du darfst mich NICHT korrigieren, ich meine schon was ich schreibe
wenns FS hops geht ist mein BACKUP weg und sonst garnichts.
lese post1, da steht drin dass dies mein BACKUPserver ist

 

[wodim]

wenns FS hops geht ist mein BACKUP weg und sonst garnichts.
lese post1, da steht drin dass dies mein BACKUPserver ist

Schön, dann wäre aber nicht nur ein Backup flöten, sondern alle. Das würde dir im Moment wohl noch nicht allzuviel ausmachen, aber lass mal in einem halben Jahr alles kaputtgehen, u.a. auch das, was du zum letzten Mal heute gesichert hast (weil du ja inkrementell arbeitest). Das dürfte es dann wohl gewesen sein.

Also sagen wir mal so: Ich lebe weniger gefährlich als du, indem ich zwei (mit rsync) praktisch "gespiegelte" btrfs - Partitions + Increments habe, ein zweites Backup komprimiert auf meiner Wechselplatte, und das nochmal "häppchenweise" via FTP auf den Server bei meinem Hoster schiebe - so ungefähr denke ich mir das?

 

[ulukay]

aehm
also:

1. server - linux mit:
-3x sas raid5 auf intel hw controller. dort liegen meine wichtigen daten
die werden taeglich auf
3x sata @ sw raid5 im selben server gespielt
sowie nochmal auf eine einfache sata platte im selben server

ergo allein in diesem server habe ich die daten 3x (3x auf xfs)
1x woechentlich werden die daten auf eine externe platte gesynct (ext4)

und die daten werden (bald) zusaetzlich 1x pro nacht auf den 50km entfernten server mit btrfs gesynct.

ergo:
- 2 server durch 50km getrennt
- eine externe wechselfestplatte
- ein hardware raid array mit sas platten
- ein sw raid array
- eine einzelne platte
- ein hw raid1 im 2. server
- 3 verschiedene filesysteme (ergo kann ich auch durch einen grandiosen filesystembug in xfs/ext4 oder btrfs auch nix verlieren)

wo gehe ich also noch schnell ein risiko ein?

 

[wodim]

wo gehe ich also noch schnell ein risiko ein?

Das kann ich nicht beurteilen, von RAIDs und so hab ich Null Kennung. Aber du kannst mir sicher sagen, ob mein Ansatz - zwei btrfs - Partitions mit rsync synchron halten (Vergleich mittels Prüfsummen) und Increments - nicht schon "doppelt gemoppelt" ist - was rsync kann, kann btrfs doch schon fast "von alleine" (eben nur noch nicht "bis auf's letzte Bit" ausgetestet), oder ?

 

[ulukay]

rsync geht imho nur auf dateigroesse und datumsstempel
wenn du das ueber internet abgleichen willst wuerde ich dir rdiff-backup empfehlen
wenn sich z.b. in einer grossen datei nur ein paar mb aendern uebertraegt rdiff-backup nur die aenderung, rsync wuerde die gesamte datei neu uploaden.

desweiteren wuerd ich auch snapshots verwenden wenn du mal was ueberschreibst und da erst nach tagen draufkommst.

 

[wodim]

rsync geht imho nur auf dateigroesse und datumsstempel

Nö, optional auch mit Prüfsummen, und zwar ziemlich "idiotensicher" (Kollisionen praktisch ausgeschlossen): rsync
Und ziemlich fix dazu (und mit btrfs noch fixer, wie gesagt, meine jetzt ~5GiB Arbeitsdateien vielleicht 10 Minuten, und etliche ziemlich große drunter). Erst mal lokal.

wenn sich z.b. in einer grossen datei nur ein paar mb aendern uebertraegt rdiff-backup nur die aenderung, rsync wuerde die gesamte datei neu uploaden.

Nö, das macht rsync genauso: rsync

desweiteren wuerd ich auch snapshots verwenden wenn du mal was ueberschreibst und da erst nach tagen draufkommst.

Döööös is ja das Beste an rsync: Das syncronisiert nicht nur, findet optional auch den alten Stand von allem wieder, was du seit dem letzten Lauf geändert oder gelöscht hast und kopiert es (samt Verzeichnisstruktur) in ein Verzeichnis, das du angibst. (Ich nenne es halt "/Increments/Daten_Datum_Uhrzeit", das sind also "echte" Increments.) Und angefangen, echt physisch zu überschreiben, wird ja erst, wenn die Partition ziemlich voll ist, oder ist das bei btrfs anders?

 

[ulukay]

Nö, optional auch mit Prüfsummen, und zwar ziemlich "idiotensicher" (Kollisionen praktisch ausgeschlossen): rsync
Und ziemlich fix dazu (und mit btrfs noch fixer, wie gesagt, meine jetzt ~5GiB Arbeitsdateien vielleicht 10 Minuten, und etliche ziemlich große drunter). Erst mal lokal.

500gb - 90 sekunden
rdiff

Nö, das macht rsync genauso: rsync

siehe oben. macht keinen sinn jeden tag das gesamte backup von den platten zu lesen und eine checksum zu machen. und das auf beiden seiten

Döööös is ja das Beste an rsync: Das syncronisiert nicht nur, findet optional auch den alten Stand von allem wieder, was du seit dem letzten Lauf geändert oder gelöscht hast und kopiert es (samt Verzeichnisstruktur) in ein Verzeichnis, das du angibst. (Ich nenne es halt "/Increments/Daten_Datum_Uhrzeit", das sind also "echte" Increments.) Und angefangen, echt physisch zu überschreiben, wird ja erst, wenn die Partition ziemlich voll ist, oder ist das bei btrfs anders?

ka, habs bei rsync nie benutzt. bei btrfs kann ich jedenfalls lesend (und imho sogar schreibend) auf jeden snapshot zugreifen
kannst also ein
diff /backup/hansiburli/wichtigedatei /backup/hansiburli.3weeksago/wichtigedatei
machen, usw...
warum sollte man snapshots nicht direkt von btrfs nutzen wenn es das schon kann

 

[wodim]

500gb - 90 sekunden
rdiff

Bist du sicher, dass da kein Kommafehler drin ist? Und wie wird verglichen? Dann aber höchstens reichlich oberflächlich (Größe und Timestamp oder so).

siehe oben. macht keinen sinn jeden tag das gesamte backup von den platten zu lesen und eine checksum zu machen. und das auf beiden seiten

Auf zwei quasi "gespiegelten" lokalen Partitions schon. Aber auch nicht jeden Tag, sondern wenn ich weiß, dass ich was geändert / gelöscht / neu angelegt habe. Kann auch mehrmals am Tag sein (weiß ich doch jetzt noch nicht, welche Dateien welche Programme für mein Projekt anlegen, außer denen, die schon da sind), und ich kann rsync ja schließlich die Pfade sagen, die's snchronisieren soll oder ausschließen ...

Ach so - zu meinem Projekt, wen's interessiert: Melina - Forum anzeigen - Das Konzept

bei btrfs kann ich jedenfalls lesend (und imho sogar schreibend) auf jeden snapshot zugreifen
kannst also ein
diff /backup/hansiburli/wichtigedatei /backup/hansiburli.3weeksago/wichtigedatei
machen, usw...
warum sollte man snapshots nicht direkt von btrfs nutzen wenn es das schon kann

Ja doch, aber die allgegenwärtigen Warnungen ... Läuft's inzwischen wirklich stabil?

 

[ulukay]

Bist du sicher, dass da kein Kommafehler drin ist? Und wie wird verglichen? Dann aber höchstens reichlich oberflächlich (Größe und Timestamp oder so).

per checksumme
warum sollte er die checksummen jedesmal neu berechnen (wie rsync das tut) wenn die datei seit dem letzten backup nicht veraendert wurde?

Ja doch, aber die allgegenwärtigen Warnungen ... Läuft's inzwischen wirklich stabil?

das werden wir rausfinden oder?
schoen dass btrfs warnungen auswirft usw..
zfs ist "stable", da gibts keine warnungen und nichtmal ein fsck. ich kann ein 10gb zfs filesystem in ner stunde schrotten und das ohne stromausfaelle oder sonstiges, nur mit ganz normalen schreib operationen und reboots. auf multipler hardware und sogar in ner virtuellen maschine. trotzdem geilt sich die halbe nerdwelt daran auf. so what
ich kann mich an fruehe filesystem wars erinnern. da wurde ueber reiserfs gemeckert (welches pre 2.4.19 ja wirklich probleme hatte) und alle haben darueber gezetert und gemeckert und wie stabil ext3 doch sei.
ich hab unsere suse linux server bis auf 2 maschinen alle auf reiserfs gehabt. und was passierte wenn man bei der tokenring karte den link zog? das ext3 war geschrottet dank kernelbug
bei reiserfs habe ichm seit ichs verwende keine einzige verlorene datei, und das auf zig linux servern in der firma und auch privat.

 

[wodim]

per checksumme
warum sollte er die checksummen jedesmal neu berechnen (wie rsync das tut) wenn die datei seit dem letzten backup nicht veraendert wurde?

Ach so, rdiff vergleicht also nicht die Dateien selber, nur Checksummen? Und die sind schon irgendwo gespeichert? Dann ist zwar die affenartige Geschwindigkeit einleuchtend, aber woher willst du dann wissen, dass die Dateien selber nicht verändert wurden (und wenn's "Bitkipper" durch Festplatten- oder Übertragungsfehler sind - also der "Ernstfall", nach dem du das Backup wirklich mal brauchst, und dann ist es im A... )? Und nach welchem Algorithmus werden die Checksummen berechnet? Stichwort: Kollisionen, d.h. die Wahrscheinlichkeit, dass zwei verschiedene Dateien dieselbe Prüfsumme ergeben (je nach Dateigröße und Berechnungsalgorithums mehr oder weniger wahrscheinlich). Und je höher die Sicherheit des Algorithmus, desto mehr Rechenaufwand. Aber das soll's mir wert sein. Besonders nach dem Crash vor kurzem, bei dem mir ein paar schöne große Dateien flöten gegangen waren und mir das Backup auch nichts mehr genützt hat. Da lass ich ihn doch lieber etwas länger im Hintergrund werkeln.

schoen dass btrfs warnungen auswirft usw..

Nein, ich meine doch nicht irgendwelche Warnungen von btfs (hatte ich auch noch keine), sonder vor btrfs - die du ja massenweise im Netz finden kannst, positive Erfahrungen bislang kaum.

 

[ulukay]

Ach so, rdiff vergleicht also nicht die Dateien selber, nur Checksummen? Und die sind schon irgendwo gespeichert?

genau

Dann ist zwar die affenartige Geschwindigkeit einleuchtend, aber woher willst du dann wissen, dass die Dateien selber nicht verändert wurden (und wenn's "Bitkipper" durch Festplatten- oder Übertragungsfehler sind - also der "Ernstfall", nach dem du das Backup wirklich mal brauchst, und dann ist es im A... )?

aehm? wofuer gibts btrfs denn bitteschoen? die daten auf btrfs sind von haus aus mit checksummen gesichert. da faehrst 1x im monat sowas wie "zfs scrub". sprich er liest alle daten. sollte es fehler geben siehst du es dann.
und wie soll er bei der uebertragung ein bit kippen?
er hat die checksummen ja fuer source und destination. wenn die nicht passen dann passen die daten auch nicht.

Und nach welchem Algorithmus werden die Checksummen berechnet? Stichwort: Kollisionen, d.h. die Wahrscheinlichkeit, dass zwei verschiedene Dateien dieselbe Prüfsumme ergeben (je nach Dateigröße und Berechnungsalgorithums mehr oder weniger wahrscheinlich). Und je höher die Sicherheit des Algorithmus, desto mehr Rechenaufwand. Aber das soll's mir wert sein. Besonders nach dem Crash vor kurzem, bei dem mir ein paar schöne große Dateien flöten gegangen waren und mir das Backup auch nichts mehr genützt hat. Da lass ich ihn doch lieber etwas länger im Hintergrund werkeln.

bevor 2 dateien diesselbe checksum haben und dir das im backup passiert und das obwohl nur 1 bit kippt, hast du einen euromillionenlottogewinn.
aber schau her: "rdiff-backup is a program written in Python and C that uses the same rolling-checksum algorithm that rsync does. Although rdiff-backup and rsync are similar and use the same algorithm, they do not share any code and must be installed separately."

Nein, ich meine doch nicht irgendwelche Warnungen von btfs (hatte ich auch noch keine), sonder vor btrfs - die du ja massenweise im Netz finden kannst, positive Erfahrungen bislang kaum.

das meinte ich ja mit meinen ausfuehrungen oben.
damals gabs auch horrormeldungen vor reiserfs und nur lob fuer ext3. trotzdem hat suse reiserfs 3.6 als standard fs vertrieben. ich gebe idr. nix auf irgendwelche warnungen oder empfehlungen von leuten die irgendein filesystem auf ihrer homekiste laufen haben und das dann allen empfehlen (oder davon abraten) weils auf der einen kiste bei ihnen zuhause gut rennt (oder eben garnicht).
das test ich lieber selber

in deinem fall kann ich aber verstehen wenn du die daten NUR auf btrfs partitionen hast, dass du dir da gedanken machst. deshalb hab ich meine daten ja auch auf verschiedene filesysteme verteilt damit bei filesystembugs nicht alle partitionen betroffen sind

 

[wodim]

bevor 2 dateien diesselbe checksum haben und dir das im backup passiert und das obwohl nur 1 bit kippt, hast du einen euromillionenlottogewinn.

Kommt ganz auf den Algorithmus an, wie gesagt. Und je sicherer, desto aufwändiger. Und wenn Bits mal "kippen", dann gewöhnlich nicht nur eins. Das kommt natürlich ähnlich selten vor wie ein Lottogewinn, aber wenn du ihn mal hast, dann garantiert nicht nur ein Euro.

aber schau her: "rdiff-backup is a program written in Python and C that uses the same rolling-checksum algorithm that rsync does. Although rdiff-backup and rsync are similar and use the same algorithm, ...

Soso. Dann erkläre mir mal einer, warum rsync nur mit Prüfsummen so (relativ) "langsam" ist. Weil's die eben neu berechnet (und zwar sowohl auf der Server- wie auf der Clientseite), nicht nur irgendwelche gespeicherten vergleicht. (Die von möglichen neuen Fehlern in Dateien, die du nicht mehr angefasst hast, ja nichts mehr mitkriegen - in die außerdem ja schon Fehler "eingebaut" sein können.)

in deinem fall kann ich aber verstehen wenn du die daten NUR auf btrfs partitionen hast, dass du dir da gedanken machst. deshalb hab ich meine daten ja auch auf verschiedene filesysteme verteilt damit bei filesystembugs nicht alle partitionen betroffen sind

Jo, ich "teste" btrfs ja auch nicht mit sämtlichen Daten. Ein Backup ist nach wie vor ext3, und mit welchem Dateisystem der Virtual Server arbeitet, den ich jetzt bei Host Europe gemietet habe, entzieht sich (bislang) meiner Kenntnis. Sollte aber auch nicht von Belang sein, außerdem habe ich darauf wohl recht wenig Einfluss. Ich muss mich "nur" mal schlau machen, was man damit so alles anstellen kann, komme mir aber andererseits ziemlich blöd vor, die Leute dort mit meinen Fragen zu nerven.

 

[ulukay]

Kommt ganz auf den Algorithmus an, wie gesagt. Und je sicherer, desto aufwändiger. Und wenn Bits mal "kippen", dann gewöhnlich nicht nur eins. Das kommt natürlich ähnlich selten vor wie ein Lottogewinn, aber wenn du ihn mal hast, dann garantiert nicht nur ein Euro.

Soso. Dann erkläre mir mal einer, warum rsync nur mit Prüfsummen so (relativ) "langsam" ist. Weil's die eben neu berechnet (und zwar sowohl auf der Server- wie auf der Clientseite), nicht nur irgendwelche gespeicherten vergleicht. (Die von möglichen neuen Fehlern in Dateien, die du nicht mehr angefasst hast, ja nichts mehr mitkriegen - in die außerdem ja schon Fehler "eingebaut" sein können.)

1. habe ich das schon geschrieben dass rsync so lahm ist WEILS dauernd sinnlos checksummen berechnet
2. solltest du nicht saetze aus dem zusammenhang reissen.
fuer datenintegritaet gibts btrfs. das hat sowieso checksummen. also gibts beim besten willen keinen grund ZWEIMAL checksummen fuer diesselben daten zu berechnen (einmal btrfs beim lesen der daten und einmal rsync)

Jo, ich "teste" btrfs ja auch nicht mit sämtlichen Daten. Ein Backup ist nach wie vor ext3, und mit welchem Dateisystem der Virtual Server arbeitet, den ich jetzt bei Host Europe gemietet habe, entzieht sich (bislang) meiner Kenntnis. Sollte aber auch nicht von Belang sein, außerdem habe ich darauf wohl recht wenig Einfluss. Ich muss mich "nur" mal schlau machen, was man damit so alles anstellen kann, komme mir aber andererseits ziemlich blöd vor, die Leute dort mit meinen Fragen zu nerven.

na dann ist eh alles halb so schlimm

 

[wodim]

fuer datenintegritaet gibts btrfs. das hat sowieso checksummen. also gibts beim besten willen keinen grund ZWEIMAL checksummen fuer diesselben daten zu berechnen (einmal btrfs beim lesen der daten und einmal rsync)

Das war ja meine Frage, ob das nicht doppelt gemoppelt ist. Unter der Voraussetzung, dass btrfs wirklich stabil läuft - was eben noch von allen Seiten angezweifelt wird. Klar, bei einem totalen Blackout (also Netzausfall) können im Extremfall alle Dateisysteme inkonsistent bis hinüber sein, in denen du gerade 'rumrührst, aber das ist selbst mir noch nie passiert.

 

[ulukay]

also ich denke in sachen checksum der daten laeuft btrfs stabil. stromausfaelle sind imho noch die groesste gefahr bei btrfs. aber man hat ja ne usv davor.
ausserdem machts sinn das backup-volume als readonly mounten und nur bei backupbeginn ein remount auf readwrite zu machen.
dann ist auch ein stromausfall komplett egal wenn nicht grad das backup laeuft. ein wirklich funktionierendes fsck ist ja leider noch nicht verfuegbar.

 

[wodim]

dann ist auch ein stromausfall komplett egal wenn nicht grad das backup laeuft.

Jo, das muss aber dann innerhalb von Sekunden passieren. Für die Stromversorgung hier, für die irgendwelche Spannungsschwankungen (die mein Netzteil nicht mehr wegstecken könnte) oder gar Ausfälle Fremdworte sind, habe ich mich kürzlich bei unserem Netzbetreiber bedankt.

ein wirklich funktionierendes fsck ist ja leider noch nicht verfuegbar.

Reparieren noch nicht, checken schon. Macht das btrfs auch "automatisch" beim soundsovielten Mounten, oder gibt's dafür ein explizites Kommando? (Vermute ich mal stark, weil viele Linux - Befehle, die mit anderen Datesiystemen funktionieren, auf btrfs nicht anwendbar sind.)

 

[ulukay]

naja btrfsck zum checken
und ein cat von allen dateien auf /dev/null zum checken der checksums

 

[wodim]

und ein cat von allen dateien auf /dev/null zum checken der checksums

Das mache ich doch lieber vorher, dann brauche ich nichts mehr zu checken. Aber so kannste bleiben, verstehe dich schon.

 

[ulukay]

hab noch was intressantes gefunden
ich dachte ja immer zfs und brtfs sind mit ihren features die einziges neuen filesysteme. allerdings gibts da wohl noch eines. nennt sich HAMMER und ist seit 2008 produktiv!

liest sich alles SEHR intressant.
DragonFlyBSD: hammer

 

[wodim]

naja btrfsck zum checken

Funktioniert das bei dir? Bei mir kommt da nur:

Could not open /dev/sda6

Egal, ob's nun gemountet ist oder nicht.

hab noch was intressantes gefunden
ich dachte ja immer zfs und brtfs sind mit ihren features die einziges neuen filesysteme. allerdings gibts da wohl noch eines. nennt sich HAMMER und ist seit 2008 produktiv!

liest sich alles SEHR intressant.
DragonFlyBSD: hammer

Na schön, probier's aus und berichte dann von deinen Erfahrungen. Ich baue jetzt nicht zum ...zigsten Mal um, will und muss auch irgendwann mal produktiv werden - s. der Link in meiner Signatur.