welches Filesystem für größere Datenmengen? btrfs schlechte wahl?

[me777]

Ich habe zur Zeit btrfs auf Server und Backup-Server, aber leider hat es schon zum 2. mal beim inkrementellen Backup das Filesystem auf dem Backup-Server zerschossen.
Zum Glück habe ich für den Notfall ein Backup auf einem mehr traditionellem FS gemacht (ext4).

Was mich an btrfs angesprochen hat ist wie schnell sich ein Snapshot machen lässt und das Namensänderungen nachverfolgt werden, und somit im neuen Snapshot nur steht "Datei X heist jetzt XY", und nicht nochmals Platz braucht... und somit auch das inkrementelle Backup über Netzwerk sehr schnell ist.

jetzt ein paar Daten:
beide Server sind debian jessie mit ausgetauschetem kernel 4.1.3 #1 SMP und btrfs-progs v4.1.2
der 24/7 hat ein raid6 und direkt drauf des btrfs.
der backup hat 2 kleinere raid5 und darüber ein lvm2 und darüber das btrfs. (ist das lvm das problem? eigentlich dachte ich das wäre ausgereift...)

Falls jemand Ahnung von btrfs hat hänge ich mal des kern.log von Sonntag an...

Aber auch Tipps wie "xfs macht keine solche zicken und für die snapshots kannst du Tool X nutzen" sind gerne gesehen.

Danke für alle Tipps.
Michael

(A23 = kern.log vom 23.August)
Anhang anzeigen A23.zip

 

[MusicJunkie666]

ZFS wäre wohl fast optimal - aber leider noch nicht recht implementiert unter Linux.
Mein letzter Wissensstand ist, dass ZFSonLinux noch in einer sehr frühen Phase ist...

 

[fax668]

Ich habe zur Zeit btrfs auf Server und Backup-Server, aber leider hat es schon zum 2. mal beim inkrementellen Backup das Filesystem auf dem Backup-Server zerschossen.
...
Was mich an btrfs angesprochen hat ist wie schnell sich ein Snapshot machen lässt und das Namensänderungen nachverfolgt werden, und somit im neuen Snapshot nur steht "Datei X heist jetzt XY", und nicht nochmals Platz braucht... und somit auch das inkrementelle Backup über Netzwerk sehr schnell ist.

Ähnliche Erfahrungen habe ich auch mit btrfs gemacht. Aber bei einem Dateisystem interessiert mich vor allem die Zuverlässigkeit und dann kommt lange erst mal nichts und dann die Performance und dann der Rest.

der backup hat 2 kleinere raid5 und darüber ein lvm2 und darüber das btrfs. (ist das lvm das problem? eigentlich dachte ich das wäre ausgereift...)

Glaube kaum. Ich setze schon seit Ewigkeiten LVM mit diversen Dateisystemen ein und hatte noch nie Probleme damit. btrfs hat es mir dagegen schon mehrmals zerschossen.

Für den Normalgebrauch nehme ich normalerweise LVM mit ext4, für große Dateien (Videoplatte) LVM mit XFS. Für MySQL benutzen wir bei der Arbeit auch XFS.

LVM Snapshots sollten mit XFS und mit ext4 auf einem aktuellen System kein Problem sein: https://en.wikipedia.org/wiki/XFS#Snapshots.

 

[zos]

ZFS wäre wohl fast optimal - aber leider noch nicht recht implementiert unter Linux.
Mein letzter Wissensstand ist, dass ZFSonLinux noch in einer sehr frühen Phase ist...

Das stimmt heute so nicht mehr (siehe 2 Jahre alte heise-Meldung). Das einzige Problem von ZFSonLinux ist bestenfalls die fehlende Kernel-Integration (im Gegensatz zu btrfs). Diese wird es aufgrund verschiedener Lizenzen auf absehbare Zeit auch nicht geben.

So einen Stress mit Snapshots hast Du unter ZFS definitiv nicht. Falls Du mit reinen Unix-Systemen nicht auf Kriegsfuß stehst, könntest Du auch einen Blick auf FreeBSD, OmniOS (nur CLI) oder OpenIndiana werfen (siehe auch OpenZFS-Site). Alle mit echter ZFS-Integration, die beiden letzten sind auch noch echte OpenSolaris-Forks. Aber ZFSonLinux sollte inzwischen dennoch gut zu gebrauchen sein.

 

[me777]

ne, bin schon ans debian gewöhnt und nutze einige Programme aufm x Desktop, außerdem bin ich froh Software für meinen aquaere unter linux gefunden zu haben..

momentan habe ich den Backup Server platt gemacht, und habe als xfs neu erstellt; aber bis das Backup durch ist wirds wohl leider noch dauern

irgendwie läuft des rsync nur mit 16,78 Mbps, das ist mir zu wenig für gigabit LAN und alle CPUS idle...
och nee... 2 Festplatten machen zicken aufm backupserver, ich dachte das lag an den sata-Kabeln und wäre jetzt weg, aber das kann auch der Fehler beim btrfs gewesen sein, blos komisch das das ca 1 Monat weg war und jetzt plötzlich wieder auftaucht, im log von Sonntag habe das auch nicht gesehen...

also erst mal Hardware checken, mit Glück iss ja n Wackelkontakt oder mit Pech sind die Platten kaputt...

 

[MusicJunkie666]

Check mal mit smartmontools, ob die HDDs in Ordnung sind.

 

[me777]

ich glaube das smart will mich ärgern: des sagt insgesamt ok aber listet jede Menge Attribute auf die schlecht aussehen.

Anhang anzeigen sdj-fehler.txt Anhang anzeigen sdj-smart.txt

Ich werden nochmal ausschalten und die 2 Festplatten mit neuen Kabeln an einen anderen Port anschließen...

*edit*
Toller Fehler: mit neuem Kabel ist der Fehler auf 2 andere Festplatten gewechselt, ich habe extra die Seriennummern der Festplatten notiert...
Ob das jetzt ein Hardware-Problem mit dem Netzteil, dem Controller, kabeln etc., oder ein Software-Problem ist? keinen Schimmer...
*edit2*
es war der Controller... egal wie ich platten und Kabel getauscht habe der Fehler war immer auf 2-3 Platten von dem Controller.
wahrscheinlich ein kernel-Problem weil mit dem 4er Kernel hat es anscheinend besser funktioniert (oder der Fehler wurde nicht gelogged)
weis wer was zu dem Controller bzw wie der unter linux zum laufen zu bringen ist?:

 

[Shipley]

Wie wär's mit einem von 3ware oder Adaptec, oder halt Intel? In den hw desc
von Fedora liest man über JMicron chips, dass die nur proprietär unterstützt werden.
Ok Du hast Debian, das ist eine andere Welt als wie Fedora......

Ich werfe hier mal die Frage in die Runde ob das Vorhaben mit ReiserFS
nicht auch geht. Muss es ext3 oder -4 sein?

 

[Colttt]

Guck die ZFSonLinux an das läuft schon oft produktiv und ist stabil..

 

[reha1]

Ähnliche Erfahrungen habe ich auch mit btrfs gemacht.

Kann ich nachvollziehen. Ich arbeite mit btrfs, praktisch seit es das gibt. Inzwischen ist es "aus den Kinderschuhen 'raus", soll heißen:

btrfs hat es mir dagegen schon mehrmals zerschossen.

Das habe ich nie geschafft (außer mit Hardwarefehlern). Extremfall mal: Ein totaler Netz-Blackout, während er gerade auf zwei btrfs-Partitions schreibend 'rumgerührt hat.

 

[fax668]

Extremfall mal: Ein totaler Netz-Blackout, während er gerade auf zwei btrfs-Partitions schreibend 'rumgerührt hat.

Das letzte Mal war ein Blitzeinschlag in der Nähe, worauf der PC abgestürzt ist. Irgendwie habe ich das Volume mit viel Bastelei wieder so hingekriegt, dass ich es mounten konnte, aber Hunderte Dateien waren Schrott, so dass ich lieber alles flach gemacht und vom Backup wieder eingespielt habe. Ich hatte vor zwei Jahren einen HTPC mit XFS und ext4 und einem Hardwarefehler, der mir jeden Tag mehrfach abgestürzt ist. Den habe ich viele Monate noch benutzt und kein einziges Problem mit der Integrität der Dateisysteme gehabt. Von einem Dateisystem mit Journal erwarte ich eigentlich genau das, nämlich dass es jeden Hardwarecrash überlebt, sonst kann ich auch etwas verwenden, das weniger Ressourcen verbrät.

 

[BYTE64]

Siehe Raid-6 System in meiner Signatur.

Habe es jetzt seit ~3 Jahren im Einsatz, funktioniert alles einwandfrei.
Ich kann auf jedenfall EXT4 nur empfehlen !
Es ist zuverlässig, robust, effizient und man kann mit fast jedem Linux system
darauf zugreifen da es in fast jedem kernel standardmässig drin ist.