Empfehlung Dateisystem

Probleme mit Samba, NFS, FTP und Co.
trg2889
Beiträge: 137
Registriert: 01.07.2015 08:45:36

Empfehlung Dateisystem

Beitrag von trg2889 » 14.03.2017 11:04:31

Hallo zusammen,
ich baue mir hier mein erstes NAS zusammen. Grundlage bietet mir dafür zum testen mein alter PC.
Jetzt stellt sich für mich die Frage nach dem richtigen Dateisystem. Debian Stretch ist bereits auf einer seperaten SSD installiert. Derzeit sind 4 Festplatten zusätzlich verbaut mit jeweils unterschiedlichen Größen. Zuerst wollte ich alle Platten mit LVM versehen, aber bei genauerer Betrachtung kommt das für mich nicht infrage, da bei einem Ausfall einer Platte ich keinen Zugriff mehr auf die anderen Platten habe. Deswegen suche ich ein anderes Dateisystem. Wäre glusterfs ähnlich leicht zu handhaben oder gibt es Alternativen ?

Danke schonmal

gbotti
Beiträge: 846
Registriert: 16.07.2010 14:24:43
Wohnort: München

Re: Empfehlung Dateisystem

Beitrag von gbotti » 14.03.2017 12:00:51

Hallo.

GlusterFS ist etwas ganz anderes. Das ist ein verteiltes Dateisystem, welches über mehrere Rechner verteilt läuft. Theoretisch könnte man das verteilen auch in einem Rechner allein machen, jedoch ist das nicht der Sinn dahinter.

Ich würde mir mal BTRFS ansehen. Damit kannst du ein RAID aufbauen und hast gleich noch so Vorzüge wie Snapshots.
Georg
RTFM, LMGTFY, Orakel... Ach... Warum muss man suchen...
Schrödingers Backup --- "Der Zustand eines Backups ist unbekannt, solange man es nicht wiederherstellt" --- Quelle: Nixcraft

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Empfehlung Dateisystem

Beitrag von smutbert » 14.03.2017 12:09:59

Glusterfs ist etwas anderes - afaik bietet das gar kein Dateisystem, das Daten auf Datenträgern organisiert sondern ledigleich eines, das die Daten auf Servern organisiert - die Server verwenden dann auf den Datenträgern ein anderes, herkömliches Dateisystem wie zB xfs. (Zumindest glaube ich, dass es so ist, man möge mich bitte korrigieren, wenn ich falsch liege.)

Dafür kann man mit lvm auch gespiegelte logische volumes anlegen und zwar mit der Option "-mX" von lvcreate, wobei X die Zahl der Spiegel ist. Mit "-m2" würde sich also lvm darum kümmern, dass die Daten auf insgesamt drei verschiedenen physical volumes gespeichert werden (1 Original und 2 Spiegel).
(lvm würd ich wahrscheinlich mit ext4 kombinieren, obwohl mir sonst xfs auch immer recht gut gefallen hat.)


Abhängig davon wofür das NAS genutzt wird, könnten aber Dateisysteme mit Prüfsummen "beruhigen", also btrfs, nilfs(2) und zfs. Erfahrungen habe ich nur mit btrfs, mit dem ich sehr zufrieden bin. Nilfs kenn ich nur dem Namen nach und zfs hab ich zwar kurz ausprobiert, aber mich hat abgeschreckt, dass man entweder die fuse-Variante nehmen oder erst ein Kernelmodul bauen muss (geht automatisch, aber mich erinnert das zu sehr an die Probleme mit proprietären Grafiktreibern ☺)

trg2889
Beiträge: 137
Registriert: 01.07.2015 08:45:36

Re: Empfehlung Dateisystem

Beitrag von trg2889 » 15.03.2017 10:32:07

Okay also werde ich mir mal btrfs näher anschauen. Das was ich aber bisher gelesen habe gibt es keine Möglichkeit unter btrfs alle Festplatten zu einem einzigen Volume zusammenzulegen oder ?

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von rendegast » 15.03.2017 10:54:38

ZBsp.

Code: Alles auswählen

mkfs.btrfs -d raid5 -m raid5 /dev/sdxy /dev/sdxy /dev/sdxy /dev/sdxy /dev/sdxy
(Vergrößern/verkleinern ( im Betrieb! ) per

Code: Alles auswählen

btrfs device add|delete ... ...
Immer mal wieder ein 'btrfs device scan' einflechten,
wenn mit dem Dateisystem offline gearbeitet wird.)

Test mit loops,
wird kein '-d raid[1|5] -m raid[1|5]' angegeben,
so wird ein "single"-Data erstellt.
-->> Schalte ich vom Verbund 1 ab, bekomme ich das System nicht mehr gemountet.

Mit dieser Voraussetzung jedoch habe ich mit 'mount -o degraded' problemlos Zugang.
Für das Ersetzen eines failed resp. fehlenden device dann nach Internet.
Üben mit ein paar loop-devices.



--------------------------
Hier konnte ich single->raid wechseln, wenn das Dateisystem leer war,
nach Beschreibung funktioniert es auch mit Daten(?)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Empfehlung Dateisystem

Beitrag von Tintom » 15.03.2017 12:51:08

Ich erlaube mir mal, mich hier einzuklinken, weil ich gerade vor einem ähnlichen Problem stehe.
BTRFS sieht auf dem Papier ganz nett aus, aber ist es auch so stabil wie ext* oder gibt es noch die plötzlich auftretenden Datenverluste wie in der Anfangszeit?

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Empfehlung Dateisystem

Beitrag von smutbert » 15.03.2017 13:49:17

Bei mir läuft es schon lange problemlos, aber ein zwei Dinge sollte man vielleicht beachten, zum Beispiel, dass raid5/6 noch problematisch ist ([1], [2]).

Ich verwende btrfs bis jetzt nur mit single und raid1. Der Umstieg von single auf raid1 war auch mit Daten überhaupt kein Problem. Beachten sollte man vielleicht noch, dass raid1 bei btrfs nur 2 Kopien (also Original+Kopie) der Daten macht und nicht so viele wie Datenträger im Verbund sind.

Nicht ganz so kooperativ hat btrfs sich bei einmal mit einem (simulierten) Ausfall verhalten: Ich konnte zwar noch lesend auf das Dateisystem zugreifen (nach dem Mounten mit "-o degraded"), aber ich konnte das ausgefallene Laufwerk nicht ersetzen. Das war aber glaube ich nur ein Problem mit dieser speziellen btrfs-progs/-tools-Version.

[1] https://btrfs.wiki.kernel.org/index.php/RAID56
[2] https://www.phoronix.com/scan.php?page= ... -All-Clear

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von scientific » 15.03.2017 14:15:58

Ich verwende btrfs auch schon seit es offiziell für stabil erklärt wurde.

Am Laptop hatte ich bisher noch nie ein Problem.
Wo ich allerdings Instabilitäten bemerkt habe ist bei der Verwendung auf einer externen HD zur Datensicherung der Snapshots.
Ob es daran liegt, dass ich gelegentlich irrtümlich den Stecker abziehe, während noch eine Transaktion aktiv ist, oder ob durch das Bewegen der Festplatte und damit einhergehend der Steckverbindung und einer Kontaktunterbrechung liegt, konnte ich bislang noch nicht rausfinden.
Meistens konnte ich die Daten der externen Festplatte nicht mehr wieder herstellen. Eine Zeit lang ging es mit einem balance und scrub und danach war das Dateisystem wieder verwendbar. Was aber jetzt nicht so tragisch ist, da dies "eh nur" das Backup ist. Ist das kaputt, schreib ich es neu.

Leider hab ich noch keine Möglichkeit, mir ein NAS zuzulegen und dort btrfs zu verwenden, wohin dann mein Laptop übers Netz die Daten sichern könnte... Eventuell liegt es ja auch an btrfs send/receive und nicht an der USB-Verbindung.

Ansonsten finde ich die Features von btrfs echt genial. Und die lokalen (wie auch jene auf der externen Platte) haben mir schon oft "das Leben gerettet", wenn ich mal wieder irrtümlich eine Datei gelöscht oder überschrieben habe... Oder wenn ich zuviel an der Installation geschraubt habe und mir das System kaputt gemacht habe... da reicht es dann einfach in den letzten bekannten funktionierenden Snapshot zu booten (meist lege ich so einen manuell an, bevor ich irgend eine Action vorhabe), und mache dort weiter, wo ich zuvor aufgehört habe.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Empfehlung Dateisystem

Beitrag von Lord_Carlos » 15.03.2017 15:05:52

Am einfachsten und bewerte Methode ist mdadm unter linux wenn du raid 5 oder 6 willst. (Oder andere)
https://wiki.ubuntuusers.de/Software-RAID/ So habe ich es momentan auch laufen.

btrfs geht zwar auch, aber gerade bei raid5/6 waere ich da sehr sehr vorsichtig.

zfs gibt es auch, weis aber nicht wie gut das under linux funktioniert.

Snapraid: Das werde ich wohl das naechstes versuchen. http://www.snapraid.it/ (Mehr dazu auf deutsch)
raid5 soll ja nicht mehr so der hamme sein auf modernen Festplatten.
Ich werde mir das ganze nochmal ueberlegen in ein paar Monaten wenn ich mein NAS neu baue.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Empfehlung Dateisystem

Beitrag von breakthewall » 15.03.2017 18:24:36

trg2889 hat geschrieben:Hallo zusammen,
ich baue mir hier mein erstes NAS zusammen. Grundlage bietet mir dafür zum testen mein alter PC.
Jetzt stellt sich für mich die Frage nach dem richtigen Dateisystem. Debian Stretch ist bereits auf einer seperaten SSD installiert. Derzeit sind 4 Festplatten zusätzlich verbaut mit jeweils unterschiedlichen Größen. Zuerst wollte ich alle Platten mit LVM versehen, aber bei genauerer Betrachtung kommt das für mich nicht infrage, da bei einem Ausfall einer Platte ich keinen Zugriff mehr auf die anderen Platten habe. Deswegen suche ich ein anderes Dateisystem. Wäre glusterfs ähnlich leicht zu handhaben oder gibt es Alternativen ?

Danke schonmal
Die Wahl des Dateisystems hängt sehr vom Einsatzzweck ab. Für ein NAS sollte es in jedem Fall erprobt und absolut zuverlässig sein, in jeder Hinsicht. Ergo fällt Btrfs schon mal komplett weg, auch wenn es nützliche Funktionen beinhaltet, sind diese nicht alle reif für den Einsatz. Würde generell zu Ext4 raten, womit im Grunde nichts falsch machen kannst, im Bezug auf Zuverlässigkeit und Geschwindigkeit. Auch hier wäre Btrfs erheblich langsamer als XFS und Ext4. Wenn zuverlässiges Löschen von Daten ein Kriterium ist, dann XFS, zumal hier eine Wiederherstellung von Daten nicht vorgesehen ist. Unter Ext4 lassen sich Daten auch sicher überschreiben, doch unter Btrfs nicht wirklich. Das liegt am Design des Dateisystems, was stark auf Datensicherheit ausgelegt ist, und absolut alles wiederherstellen kann auf längere Sicht. Wird eine Datei gelöscht, ist sie nie wirklich weg, auch wenn sie überschrieben wird, wird die aktualisierte Version der Datei einen neuen Speicherplatz bekommen, ohne den originalen Datensatz unmittelbar zu überschreiben. Hier sollte man also eine komplette Festplattenverschlüsselung in Betracht ziehen wenn das relevant ist, oder man deaktiviert CoW was einen Vorteil von Btrfs wieder zunichte macht. Allerdings hätte Btrfs im Bezug auf Verschlüsselung auch Vorteile, im Vergleich zu allen anderen Dateisystemen. Nämlich die Konsistenzprüfung des Dateisystems mit CRC-Checks, und dasselbe gilt auch für die Metadaten. Somit wäre Btrfs bspw. in der Lage, Offline-Manipulationen der Datensätze zu erkennen und entsprechend mit Backups zu korrigieren. Also sollte man genau darüber nachdenken was man haben, oder vl. in Zukunft umsetzen will.

gbotti
Beiträge: 846
Registriert: 16.07.2010 14:24:43
Wohnort: München

Re: Empfehlung Dateisystem

Beitrag von gbotti » 16.03.2017 14:24:22

BTW. Ich laß neulich darüber dass es am sinnvollsten für alle Softwarebasierten RAID-Lösungen ist ECC-RAM zu verwenden. Der ist zwar etwas teuerer als der normale und nicht alle Boards unterstützen ihn, jedoch würde ich (falls möglich) immer nur ECC-RAM für Storages verwenden. Deswegen verwende ich Beispielsweise auch keine BilligschrottNAS-Systeme mit mehr als 2 Festplatten (RAID 1) und/oder CRC-Prüfsummen für Dateien, da diese mit nicht-ECC-RAM eher fehlerhaft sein können als mit ECC.

Bei ZFS würde ich niemals mit normalem RAM hantieren, bei BTRFS soll es angeblich nicht nötig sein. Ich würds wie gesagt nicht riskieren...
Georg
RTFM, LMGTFY, Orakel... Ach... Warum muss man suchen...
Schrödingers Backup --- "Der Zustand eines Backups ist unbekannt, solange man es nicht wiederherstellt" --- Quelle: Nixcraft

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Empfehlung Dateisystem

Beitrag von Lord_Carlos » 16.03.2017 14:41:27

ZFS ohne ECC ist nicht schlechter als andere datensysteme ohne ECC.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von schorsch_76 » 16.03.2017 15:26:39

Zu btrfs
http://blog.fefe.de/?q=btrfs

Meine klare Empfehlung ext4, lvm und drunter nach Bedarf mdadm.

trg2889
Beiträge: 137
Registriert: 01.07.2015 08:45:36

Re: Empfehlung Dateisystem

Beitrag von trg2889 » 16.03.2017 20:02:53

Danke erstmal für eure zahlreichen Antworten. Wie schon eingangs erwähnt möchte ich kein LVM nutzen. Btrfs mit raid5 wie es hier vorgeschlagen worden ist läuft jetzt seid 2 Tagen ununterbrochen keine Fehler bis dato festzustellen selbst bei einem simulierten Ausfall einer Platte kam ich noch an meine anderen Daten dran. Snapraid sieht auf dem ersten Blick auch passend aus. Ich werde das mal auf einem zweiten Testsystem versuchen. In erster Linie möchte ich gerne meine Festplattensammlung reduzieren damit auch die Backups einfacher und zentralisiert werden.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 17.03.2017 16:09:29

gbotti hat geschrieben: Bei ZFS würde ich niemals mit normalem RAM hantieren, bei BTRFS soll es angeblich nicht nötig sein
In keinen Server gehört non-ECC RAM, völlig egal welche aufgaben er erfüllt... Idealerweise nutzt man auch gleich regECC, für Vollbestückung ist das ohnehin fast immer Voraussetzung.
Wenn unterstützt, nutze ich auch auf Desktops mittlerweile nur noch ECC. Der Preisunterschied ist nur noch marginal und die Zeit- und Nervenersparnis wg. defektem/schrottigem Consumer-RAM ist unbezahlbar...

BTRFS würde ich nichtmal in die Nähe von ansatzweise wichtigen Daten lassen. ZFS und gut is - das wurde von beginn an auf "production ready" im enterprisebereich entwickelt, nicht wie BTRFS: "wir basteln mal eben ein neues FS, stabil und sicher machen wir es später". Auf Betriebssystemen bei denen ZFS ein "first class FS" ist (illumos, FreeBSD), ist die Integration ins system und viele systemtools hervorragend, was vieles vereinfacht und noch viel mehr überhaupt erst ermöglicht. Unter Linux ist das eher ein ziemliches patchwork.
Größte Schwachstelle ist nach wie vor GRUB - der fliegt ständig in die luft bzw mit ZFS noch öfter als sowieso schon. Ich habe noch ein einzelnes system mit debian und ZFS laufen - im schnitt bei jedem zweiten kernelupdate oder änderung der Plattenkonfiguration kann GRUB das system nicht mehr booten. Dem BSD loader ist komplett wurscht wo und wie die platten am system hängen - solang genug da sind um den pool zu aktivieren wird gebootet. Auf storagesystemen sollte man zudem den storagepool separat vom pool bzw den Platten fürs OS halten, das macht Migrationen wesentlich einfacher.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Empfehlung Dateisystem

Beitrag von Lord_Carlos » 17.03.2017 16:25:49

r4pt0r hat geschrieben: In keinen Server gehört non-ECC RAM, völlig egal welche aufgaben er erfüllt... Idealerweise nutzt man auch gleich regECC, für Vollbestückung ist das ohnehin fast immer Voraussetzung.
Wenn unterstützt, nutze ich auch auf Desktops mittlerweile nur noch ECC. Der Preisunterschied ist nur noch marginal und die Zeit- und Nervenersparnis wg. defektem/schrottigem Consumer-RAM ist unbezahlbar...
Gerade vor ein paar Tagen die Prise fuer microATX mainboards fuer ein Intel Pentium angeguckt das auch HDMI/DP out hat. Ohne ECC kann man ein gutes fuer ~80 EUR bekommen, mit ECC konnte ich welche ab 220 EUR finden. Ist jetzt nicht gerade Marginal. Ram preise dann garnicht mehr angeguckt.

Durch lesen von anderen Diskussionen habe ich mir sagen lassen das es wahrscheinlicher ist das man selber was loescht, als das ein bit flip eine Datei komplett unleserlich macht.
Wie siehst du das? Wie oft passiert es dir?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 17.03.2017 17:03:20

Lord_Carlos hat geschrieben: Intel Pentium angeguckt das auch HDMI/DP
Pentium und HDMI hat nix mit Server am hut ;)

Die neuen Xeon D von Supermicro fangen bei <400 eur für die 2-kern Varianten an (1508). Da hat man dann sogar bereits 2x 10GBit onboard im SoC bei 25W TDP und ein vollwertiges IPMI. ASRock kommt mit noch günstigeren Varianten, ohne IPMI und ASRock-typisch eben mit billigkomponenten und vermutlich auch kaputtem UEFI :roll:
Sobald die neuen Atom C3000 kommen dürften die preislich noch etwas drunter liegen, bzw die C2xxx werden noch weiter im preis fallen (sind aber auch ziemliche krücken...).
8GB regECC DDR4-2133 RAM gibts für ~75EUR (Kingston Value), vergleichbarer non-ECC kostet gerade mal 10EUR weniger.

Für <500 EUR (exkl. platten) kann man also schon ne anständige plattform bekommen die wirklich für serverbetrieb konzipiert und geeignet ist. Da braucht man nicht lange mit Desktophardware rumbasteln. Hab das selber leider lange genug für meine Heimserver gemacht und unterm strich meistens mehr draufgezahlt. Bei Gehäusen für storagesysteme kann ich auch nur noch empfehlen nach gebrauchten servergehäusen ausschau zu halten - das ist immer noch zuverlässiger und günstiger als irgendwelche 5.25" Wechselgehäuse. Zudem ist es einfacher ein Servergehäuse, das schon einen sehr optimierten Luftstrom hat, leise zu bekommen als ein umfunktioniertes Desktopgehäuse das plötzlich die Abwärme von 8...14...20... Platten wegschaffen muss... (Bei mir läuft auch noch so eine "jugendsünde" :oops: )

Durch lesen von anderen Diskussionen habe ich mir sagen lassen das es wahrscheinlicher ist das man selber was loescht, als das ein bit flip eine Datei komplett unleserlich macht.
Wie siehst du das? Wie oft passiert es dir?
Festplatten sterben und geben auch falsche daten zurück, speziell wenn daten sehr lange nicht gelesen/geschrieben wurden - da hat ZFS schon mehrfach angeschlagen bevor z.b. bei SATA irgend ein SMART-Wert auffällig gewesen wäre. Meistens reicht es dann die platte mit random i/o zu "thrashen" um fehler zu frovozieren oder sogar endgültig ins jenseits zu befördern.

Mit ZFS lasse ich von entsprechenden datasets (z.b. /usr/home) 10-minütig snapshots erstellen mit Vorhaltezeiten um ~3h (+ längere/long-term snapshots für backup / replication). Dadurch konnte ich schon oft daten die durch dicke user-finger gelöscht oder überschrieben wurden wiederherstellen (über verstecktes .zfs-verzeichniss, da brauchts nichtmal nen rollback). Auch ein cryptlocker-verseuchter client der nen netzwerkshare verschlüsseln wollte konnte aufgehalten werden bzw der letzte snapshot wurde zurückgeholt. Seitdem lasse ich überwachen ob das delta zwischen zwei snapshots einen zu großen anteil der gesamtgröße ausmacht. Dann wird der vorherige snapshot geklont, readonly gemountet und der vermeintlich kompromittierte snapshot bleibt zur analyse erhalten, den kann ich ggf zurückholen oder einfach löschen...

trg2889
Beiträge: 137
Registriert: 01.07.2015 08:45:36

Re: Empfehlung Dateisystem

Beitrag von trg2889 » 17.03.2017 18:15:39

Hallo zusammen,
im Moment ist ein Serverboard mit reg-ECC wie Kanonen auf Spatzen schießen. Es sind keine wichtigen Daten die im NAS verteilt werden Hauptsächlich Musik, Serien und Musikvideos. Also, nichts was man vermissen würde wenn mal eine Platte seinen Dienst versagt Zumal es ja auch noch Backups gibt. Da ich noch Hardware hatte, die ehh hier langsam verstaubt, wollte ich mich mal an das Projekt heranwagen. Zumal das NAS auch nur und einen Teil für die Hausautomation darstellt.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von scientific » 17.03.2017 18:21:34

Weil grub angeblich so kaputt und instabil wäre...
Nun, ich nutze nun seit ein paar Monaten die Fähigkeiten des Linux-Kernels, sie mit UEFI selbst zu booten...
Grub hab ich zwar noch installiert, aber das fliegt bald von der Platte.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Maik aus MS
Beiträge: 596
Registriert: 19.08.2005 17:01:19
Wohnort: Greven
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von Maik aus MS » 18.03.2017 09:47:15

Bei mir habe ich es so geloest. BS auf SSD mit ext4. Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.

Die Datenplatten haben BTRFS. Habe dadurch jeweils 2 Platten zu einer Verbunden. Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind. Also wenn wie gefordert die Platten immer ganze Dateien enthalten sollen
dann muss man es anders machen. Z.B. Platte1 - Musik, Platte2 - Video usw.

Maik
Die mich kennen mögen mich.
Die mich nicht mögen können mich.

Benutzeravatar
DEBIANUNDANDREAS
Beiträge: 1304
Registriert: 01.06.2013 10:37:46

Re: Empfehlung Dateisystem

Beitrag von DEBIANUNDANDREAS » 18.03.2017 11:15:36

Hallo ich nutze für ubuntuserver 16.04.2 ext 4, immer nur ext4 das ist ausgereift und kein Dateisystemexot wie btrfs.

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von rendegast » 18.03.2017 12:02:40

Maik aus MS hat geschrieben: Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind.

Ups, hatte ich oben erwähnt, mir in der Brisanz gar nicht bewußt geworden
rendegast hat geschrieben: Test mit loops,
wird kein '-d raid[1|5] -m raid[1|5]' angegeben,
so wird ein "single"-Data erstellt.
-->> Schalte ich vom Verbund 1 ab, bekomme ich das System nicht mehr gemountet.
Ein mehr-device-btrfs OHNE explizite Option für raid[1|5] entspricht einem hochgefährdeten raid0.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 20.03.2017 10:31:54

Maik aus MS hat geschrieben:Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Das kann einem ganz schnell das Wochenende retten. Hier läuft z.B. ein älteres gatewaysystem auf Intel S5000 Basis, das nicht so 100%ig dem PCIe-hotplug Standard folgt. Freitag Nachmittag noch ein Upgrade durchgeführt bei dem auch Code für PCIe-HP aktualisiert und HP per default aktiviert wurde ->system crashte beim booten und startete sofort neu (endlosschleife).
Dank Bootenvironments lief das System nach wenigen Minuten wieder mit Stand vor dem Update (nur OS, userdaten liegen ja nicht auf BE-relevanten datasets), die User haben mir nicht mehr die Ohren vollgejammert und ich konnte in aller ruhe noch kurz über die crashdumps schauen und dann ins Wochenende - das BE mit dem aktualisierten system (und crashdumps) konnte ich dann am Montag analysieren und mit deaktiviertem HP läuft das System seither anstandslos...

Mit BEs kann man größere upgrades auch anderst herum angehen: BE erstellen, in diesen datasets die updates installieren während das system weiterhin im normalen Betrieb weiterläuft, ggf noch configdaten überprüfen/anpassen, BE für nächsten start aktivieren und system neu starten. Hat man eine angepasste Kernelkonfiguration kann man den neuen Kernel im neuen BE auch gleich vorab bauen - im Endeffekt ist die Downtime dann selbst bei sehr umfangreichen updates nur ein einziger Neustart. Ist doch was schiefgelaufen lädt man das alte BE und kann dann ohne Zeitdruck analysieren was nicht passt...

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von scientific » 20.03.2017 12:04:41

r4pt0r hat geschrieben:
Maik aus MS hat geschrieben:Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Das kann einem ganz schnell das Wochenende retten. Hier läuft z.B. ein älteres gatewaysystem auf Intel S5000 Basis, das nicht so 100%ig dem PCIe-hotplug Standard folgt. Freitag Nachmittag noch ein Upgrade durchgeführt bei dem auch Code für PCIe-HP aktualisiert und HP per default aktiviert wurde ->system crashte beim booten und startete sofort neu (endlosschleife).
Dank Bootenvironments lief das System nach wenigen Minuten wieder mit Stand vor dem Update (nur OS, userdaten liegen ja nicht auf BE-relevanten datasets), die User haben mir nicht mehr die Ohren vollgejammert und ich konnte in aller ruhe noch kurz über die crashdumps schauen und dann ins Wochenende - das BE mit dem aktualisierten system (und crashdumps) konnte ich dann am Montag analysieren und mit deaktiviertem HP läuft das System seither anstandslos...

Mit BEs kann man größere upgrades auch anderst herum angehen: BE erstellen, in diesen datasets die updates installieren während das system weiterhin im normalen Betrieb weiterläuft, ggf noch configdaten überprüfen/anpassen, BE für nächsten start aktivieren und system neu starten. Hat man eine angepasste Kernelkonfiguration kann man den neuen Kernel im neuen BE auch gleich vorab bauen - im Endeffekt ist die Downtime dann selbst bei sehr umfangreichen updates nur ein einziger Neustart. Ist doch was schiefgelaufen lädt man das alte BE und kann dann ohne Zeitdruck analysieren was nicht passt...
Sorry für die blöde Frage... Bootenvironment? Ich hab mal gegooglet und das im Zusammenhang mit BSD gefunden.

Ist das auch unter Linux vorhanden?

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 20.03.2017 17:05:05

Sorry, ich dachte ich hatte das eingangs erwähnt - es handelt sich um FreeBSD systeme. Ich habe mal angefangen/versucht etwas ähnliches mit einem devuan/ZFS system zu bauen, aber da debian bzw linux allgemein systemdaten relativ wild im dateisystem verteilt ist das doch recht umständlich bzw nicht im selben Umfang möglich. BSD hat hier einfach eine _sehr_ saubere trennung von systemdaten, konfiguration, laufzeitdaten und userdaten, die das konzept von BEs begünstigt bzw erst ermöglicht.

Mit etwas Aufwand und Aufräumarbeiten wäre sowas theoretisch auch unter linux mit ZFS möglich - dann bleibt aber immer noch der Kropf namens GRUB der ja schon mit 'einfachem' ZFS oft Schwierigkeiten macht. Dem auch noch das Konzept von BootEnvironments beizubringen endet wohl eher im chaos (u.a. deshalb wurde auch bei illumos GRUB rausgeworfen und der BSD-Loader portiert).


Grundsätzlich kann man aber auch manuell einen snapshot vom gesamten Pool erstellen bevor man ein größeres update durchführt. Man kann dann in grub einfach das '@snapshotname' anhängen um in den snapshot zu booten. Änderungen an userdaten werden dabei natürlich auch zurückgesetzt bzw man müsste die entsprechenden datasets ggf manuell in der neueren variante mounten oder einzelne dateien aus .zfs/snapshot kopieren. (overlay-mounts sollte man dabei erfahrungsgemäß unter linux aber vermeiden, das Konzept ist hier irgendwie nicht ganz fertiggedacht worden und funktioniert nicht wirklich)

Antworten