Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
21.10.2019, 02:29:26

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
Statistiken
  • Beiträge insgesamt: 614466
  • Themen insgesamt: 49660
  • Heute online: 501
  • Am meisten online: 992
  • (17.11.2018, 20:17:55)
Benutzer Online
Mitglieder: 5
Gäste: 405
Gesamt: 410

Autor Thema: [erledigt] [LM17.3] Welches Dateisystem für großes RAID (16TB+)?  (Gelesen 4335 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

[erledigt] [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« am: 15.02.2016, 21:36:45 »
Da ich beim letzten Aufbau meines RAID's doch ein paar Fehler gemacht habe (siehe hier: https://forum.ubuntuusers.de/topic/resize2fs-die-neue-groesse-kann-nicht-mehr-mit/) und ich es nun neu bauen muss, möchte ich mich vorab mal bei euch Informieren, was Ihr mir zum Thema Dateisystem auf einem RAID6-Laufwerk 8x4TB HDD's (16TB+) empfehlen könnt.

Ansprüche:
  • RAID6
  • 7 x 4TB HGST Deskstar NAS (bin am Überlegen ob ich nicht gleich noch auf 8 HDD's aufstocke; wahrscheinlich werde ich das tun)
  • Eine einzige Große Partition
  • Datengrab: Daten werden eigentlich nur abgelegt, selten geändert oder gelöscht; Art NAS
  • Nur Nutzerdaten; Überwiegend Filme (samt Untertiteldateien, mehrere Bilder und nfo's für jeden Film); weiterhin Images, Musik, Bilder und Dokumente
  • Da ich es mir als Privatperson nicht leisten kann von 16TB und mehr ein Backup zu machen, sollte das ganze schon robust sein

Ich hatte mich damals absichtlich für ext4 entschieden, da es ausgereift und erprobt ist und alle meine Spezifikationen erfüllt hat. Nun bin ich natürlich dieser plöden 16TB Grenze in den e2fsprogs (resize2fs) auf den Leim gegangen, so dass ich das RAID eben neu bauen muss. btrfs ist mir eigentlich noch zu experimentell, aber ich lasse mich auch gerne eines besseren belehren. XFS weiß ich gar nicht wie es damit ausschaut.

Könnt ihr mir mal bitte eure Meinungen dazu posten!?

Weiterhin hab ich in dieser Anleitung hier: http://www.unix-ninja.com/p/Formatting_Ext4_volumes_beyond_the_16TB_limit/ gelesen, dass ich die e2fsprogs auch noch aus dem git-repo händisch kompilieren muss, um die Möglichkeit zu haben das ext4 auf 64Bit zu bauen. Bin immer nicht so ein Fan von selber kompilieren. Bessere Lösung? Gibts ein Repo mit aktueller Version (hab ich leider nicht gefunden)? Besten Dank schon mal an alle.
« Letzte Änderung: 27.03.2016, 23:54:29 von Arny80Hexa »

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #1 am: 15.02.2016, 22:04:41 »
Ich frage mich immer wieder, warum manche so Raid-Versessen sind....aber ich war auch nicht anders!
;-)

Die enorme Geschwindigkeit eines Raid 5 / 6 nutzt man ohnehin nur mit 10GB-Lan aus ... oder wenn zumindest 5...6...7 etc. User es gleichzeitig nutzen.
Raid 6 kann dazu den Ausfall zweier Platten kompensieren. Allerdings dauert das Neueinbinden je nach Hardware-Power zig Stunden (Ausnahme: Hardware-Raid-Controller um die EUR 400,- +). Fällt das Raid aus, ist es fast unmöglich bis zumindest extrem schwer, wieder an die Daten zu kommen.

Ich habe zum Bsp. auch anfangs ein Raid6 haben wollen. Ich muss jetzt sagen, dass ich keine Ahnung hatte, was das alles bedeutet.
Ich fand ein Forum, die sich super-gut mit Servern / NAS etc. auskennen. Dort ließ ich mich von den Vorteilen eines Snapraid /  AUFS überzeugen:
http://www.technikaffe.de/anleitung-242-snapraid_und_aufs_unter_openmediavault_als_raid_5_6_ersatz

Ein Snapraid mit 6Platten (4Daten + 2Paritätsplatten) bietet die Sicherheit von Raid 6; jede Platte ist einzeln ansprechbar und alle Daten zu sehen; es läuft nur die Platte, die gerade Daten liefert -> Stromersparnis!; man kann zum Bsp. einmal am Tag einen Snapschot anlegen -> reicht in der Regel vollkommen aus...oder auch beliebig öfter ... etc.

Genaueres siehe link...
:-)

zu den Filesystemen....
- BTRFS wäre auch mein Favorit, aber unter Debian / OMV wohl noch nicht verfügbar
- ZFS -> nur bei extrem potenter Hardware und auch nicht gänzlich unproblematisch

ach ja ... zum Thema "Geschwindigkeit" mal noch ein paar super Gedanken:
http://forum.nas-portal.org/content.php?50-Wie-schnell-ist-mein-NAS-%96-Das-sollten-Sie-beachten!
« Letzte Änderung: 15.02.2016, 22:49:19 von Michelle_Br »

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #2 am: 16.02.2016, 20:13:58 »
Danke @Michelle_Br für diese super Tips. Ich werde die mir mal schnellstmöglich Angucken und dann dir noch mal Feedback geben, ich denke ich hab da nachher noch ein paar Fragen zu!  ;)

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #3 am: 16.02.2016, 21:54:11 »
gern .....*lächelt
Lese Dir mal bei technikaffe.de die diversen Bauanleitungen zu den Projekten durch - das erläutert unwahrscheinlich viel. Auch im Forum dort sind tolle Leute zum Thema NAS / Server und Linux

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #4 am: 21.02.2016, 15:55:18 »
@Michelle_Br: So, ich hab jetzt mal ausführlich bei http://www.snapraid.it/ gelesen, was das Ding so alles kann. Zu AUFS hab ich leider sehr wenig gefunden, kann mir aber denken wozu das gut ist. Wie ich ja schon ankündigte hab ich dazu noch ein paar Fragen. Vorab möchte ich aber noch ein paar Dinge zur Erläuterung meines Themas hinzufügen.

  • Der Rechner in dem sich das RAID befindet ist kein NAS im klassischen Sinne. Ich nutze ihn als richtige Workstation und arbeite damit täglich.
  • Der Rechner läuft NICHT 24/7! Gelegentlich kommt das vor, aber im allgemeinen Schalte ich ihn ein und aus, wie ich ihn brauche. (Also oft wird er einmal am Tag eingeschalten und läuft dann durch, bis ich ins Bett gehe  ;) )
  • Der Rechner läuft mit LM17.x. Ein Wechsel des Betriebssystems kommt selten vor, kann aber schon mal sein. Bleibe im allgemeinen aber bei Debian-basierenden Distributionen.
  • Betriebssystem liegt natürlich nicht im RAID (hat ne SSD).
  • Hardware: ASRock Z87 Extreme6/ac (10 SATA 6GB/s-Ports OnBoard auf 2 Controllern), Intel Cor i7 4770T (TDP 45Watt),2x8GiB RAM, 500er SSD
  • Es sind jetzt doch 8x4TB Platten geworden (HGST Deskstar NAS)

Warum (bisher) RAID6?
  • Weil es mich im gewissen Maße gegen Festplattenausfälle schützt (ist gerade wieder eine nach gerade mal 6500h ausgefallen).
  • Weil ich (bisher) von Alternativen wie SnapRAID noch nichts wusste. (Vielen Dank für diese Information!!! :) )
  • Weil ich dann ein riesen Großes Laufwerk habe, auf dem ich bequem meine Daten verteilen kann, wie es mir beliebt.

Fragen

  • Da ich hier kein Stand-Alone-NAS System einrichten will: Bekomme ich sowohl SnapRAID als auch AUFS unter Debian-basierten Distributionen (besonders LM) problemlos zum laufen?
  • Wenn ich das richtig verstanden habe sind die Paritäten nicht über alle Platten verteilt (vergleichbar RAID5/6), sondern auf 1+ zusätzlichen Parity-Disks (vergleichbar RAID4) vorhanden?
  • Nur der Information halber: Kann das sein, dass auf die Paritätsplatten häufiger zugegriffen (read/write) wird, als auf die Storage Platten (mir gehts hier um die "Abnutzung" der HDD's
  • Ich hatte zunächst erstmal nur mich über SnapRAID informiert. Wie oben geschrieben ist es sehr angenehm für mich gewesen, ein riesen Laufwerk zu haben, wo ich einfach alle Daten rein schieben kann. Hier hab ich dann eine entsprechende Ordnerstruktur angelegt, mit der ich gut zurecht komme. Allerdings ist alleine einer der Stammordner 9,5TB groß ist. Passt also niemals auf eine Platte. Ich hab nun während des Lesens über SnapRAID mich schon langsam damit abgefunden, dass ich das in Zukunft wohl leider anders lösen muss, was einen ziemlich Mehraufwand bedeutete. Nun gibts zwar hier auch noch die Möglichkeit des Poolings, allerdings ist das ja auch immer nur lesend. Nun hab ich beispielsweise ein Tool (Mediaelch, kann ich sehr empfehlen!) Welches eben genau in diesem riesen Ordner (samt Unterordner) rumarbeitet. Im Falle dass ich Die Dateien über mehrere Platten verteilen müsste würde alleine hier der Aufwand sehr steigen. So weit ich das lesen konnte kommt hier AUFS ins Spiel, welches in der Lage ist einen pool anzulegen, der auch schreibbar ist. Ist das richtig? Wie funktioniert das in der Praxis? Entstehen Nachteile dadurch?
  • Auch wenn Geschwindigkeit eher zweitrangig ist: So weit ich verstanden habe läuft das pooling über SAMBA/NFS. Wie schaut es da mit der Geschwindigkeit aus, da die Daten ja sicher über einen Virtuellen Netzwerkadapter geschleift werden? Erreiche ich hier wenigstens annähernd die Plattengeschwindigkeit (ca. 120MB/s read)? (Was mir durchaus reichen würde)
  • Ich bin am überlegen, wie ich in meinem Fall das einfach und bequem mit den Snapshots realisiere. Wie gesagt, der Rechner läuft nicht 24/7, da wird es mit einem cronjob ja schon schwierig. Irgendwelche Ideen / Vorschläge?
  • Kann ich während der sync-, scrub-, check- Prozesse, usw. auf die Daten zugreifen (Schreiben? Lesen?)?
  • Wie schaut es generell mit der Stabilität von dem ganzen aus? Läuft das alles gut? Gibts vielleicht auch negative Erfahrungen damit? (Nur damit ich weiß, auf was ich mich ein lasse)
  • Kann ich (wenn der Rechner aus ist), so eine Datenplatte auch einfach mal kurz irgendwo hin mit nehmen, um beispielsweise Daten von ihr herunter zu kopieren? Oder könnte das zu Problemen führen?
  • Wie schaut es mit Limitierungen (auch im Zusammenhang mit AUFS) aus? Hab ich hier auch wieder ne 16TB-Grenze oder ähnliches?
  • Auch wenn mir nun schon mehrfach zu btrfs geraten wurde. Mein Bauch sagt mir: Sofern es möglich ist, sollte ich lieber beim etablierten ext4 bleiben. Ich sehe in der Konstellation mit dem SnapRAID auch keinen nennenswerten Vorteil von btrfs gegenüber ext4, oder gibts da doch was?
  • Wenn ext4: Welche Parameter sind hier sinnvoll? Vielleicht "large" oder "64Bit"?
  • Laufen beim sync / scrub / check dann eigentlich wieder alle Platten, oder bleibt auch hier ein Teil im Standby?
  • Hast du Erfahrungen, wenn ich mit Programmen wie Kodi oder Plex auf das SnapRAID zugreife? Laufen dann wieder alle Platten an (Kodi liest ja die Bilder und nfo's ein)?
  • Was ist, wenn das System herunter gefahren / neu gestartet wurde, bevor der Sync durchgeführt wurde?

Pro
  • Ich kann bereits beschriebene Platten verwenden. Killer-Feature!!! Die Platten in meinem jetzigen RAID6 haben die nächsten Wochen schon ne ganze Menge auszuhalten, weil ich das RAID nach und nach verkleinern und die Daten auf die frei gewordenen HDD's auslagern muss. Würde ich wieder ein RAID bauen würde das ganze noch mal so viel Zeit und Arbeit fressen diesen wieder nach und nach zu bauen. Ergo, die Platten verschleißen weniger.
  • Nur die Platte auf der die Daten - auf die ich zugreife - liegen, wird aus dem Standbye geholt. Muss mich zwar dann wieder dran gewöhnen dass es einen Moment dauert, biss ich auf die Platte zugreifen kann (beim RAID6 ist der Zugriff ja instant) aber das ist schon ne feine Sache. Alleine was man da an Strom/Wärme/ Lautstärke und Verschleiß einsparen kann. Feine Sache. In der Praxis hab ich eine HDD mit rund 15W (an der Steckdose) gemessen. Das macht bei 8 Platten: 8*15=120Watt (abgezogern der einen die auch beim SnapRAID läuft)
  • Verwendung unterschiedlich großer Platten. Wird für mich dann mal relevant, wenn die jetzigen Laufwerke voll sind und ich auf 8TB Platten upgraden muss. Das ist bei RAID5/6 schon erheblich mehr Aufwand.
  • Durch das Snapshotting habe ich eine begrenzte Möglichkeit Daten wieder herzustellen die versehentlich gelöscht wurden.

Contra
  • Eigentlich nur eine Sache: Das ich nicht ein Großes Laufwerk habe, aber das lässt sich hoffentlich mit AUFS kompensieren!?

Unterm Strich bin ich total begeistert von deinem Vorschlag und werde gleich mal eine VM mit einem entsprechenden Testszenario aufsetzen. Bis dahin Entschuldigung für den doch sehr ausführlichen Post und die vielen Fragen. Ich bin dir sehr dankbar! :) Beste Grüße, Arny.
« Letzte Änderung: 21.02.2016, 18:22:32 von Arny80Hexa »

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #5 am: 21.02.2016, 17:59:23 »
*lacht
Deine förmlich spürbare Begeisterung und Neugier haut mich ja quasi vom Hocker!
;-)

So ging es mir damals auch, als der Admin (Joogie) vom Technikaffe - Forum mich dafür sensibilisierte; er kennt sich da richtig (!) aus.
Nun zu Deinen Fragen.....

Die meisten Antworten findest Du in dem verlinkten Artikel von technikaffe.de:
http://www.technikaffe.de/anleitung-242-snapraid_und_aufs_unter_openmediavault_als_raid_5_6_ersatz
... dort ist auch die Einrichtung super beschrieben - die Pro´s und Contra´s desgleichen.

btrfs hat enorme Vorteile, die bislang nur auf Plattformen mit ECC-Speicher UND Raid5 / 6 + unter ZFS zu erreichen waren ... bei entsprechend hoher Hardware-Anforderung. Standardgemäß setzt bislang SuseLinux btrfs ein.

Einzelne Fragen kann ich beantworten - einige andere (noch) nicht. Ich habe meinen Server noch nicht fertig - ich warte auf OMV 3 (Debian 8-Basis). Also fehlt mir noch total die Praxis und all das, was ich weiß, ist Grundlagenwissen - theoretisches.
;-)

1. Frage wäre, warum die Workstation und Server nicht trennst. Das wäre gerade unter dem Aspekt der Datensicherheit und Verfügbarkeit durchaus sinnvoll. Sicher - man hat zwei "Kisten" rumstehen .... aber durch die Auswahl geeigneter Komponenten kann man sozusagen ziel-spezifisch konfigurieren und arbeiten. ... was auch zu mehr Energie-Effizienz führen kann. Dann OMV als System drauf - et voilà

"Da ich hier kein Stand-Alone-NAS System einrichten will: Bekomme ich sowohl SnapRAID als auch AUFS unter Debian-basierten Distributionen (besonders LM) problemlos zum laufen?"
.... müßte klappen. OMV läuft ja auf Debian-Basis und gerade DARUM geht es ja bei der Verlinkung.

"Wenn ich das richtig verstanden habe sind die Paritäten nicht über alle Platten verteilt (vergleichbar RAID5/6), sondern auf 1+ zusätzlichen Parity-Disks (vergleichbar RAID4) vorhanden?"
.... es gibt x Daten-Platten, die beliebig erweiterbar sind (fließend ....) und ein (quasi wie Raid5) bis zwei Paritätsplatten (quasi Raid6 .... bis zu zwei Datenplatten können ausfallen). D.h. wann immer ein Datenplatten voll ist -> neue Datenplatte rein - das war´s .... zu beachten ist nur, dass die Paritäten die größten Platten oder zumindest gleich groß sein müssen

"Nur der Information halber: Kann das sein, dass auf die Paritätsplatten häufiger zugegriffen (read/write) wird, als auf die Storage Platten (mir gehts hier um die "Abnutzung" der HDD's"
..... *schmunzelt
      Und DAS fragt ein Raid6 - Benutzer (?) ... wo IMMER alle Platten laufen? *grins
       Sicher müssen die Paritätsplatten zu jedem Snapschot laufen - geht ja nicht anders ... aber sie schalten nur dann ein (zumindest habe ich das so verstanden)
      Aber im Vergleich zu einem "normalen" Raid dürfte die Laufzeit eines Snapraid ein Kindergeburtstag sein. ;-)

"Ich hatte zunächst erstmal nur mich über SnapRAID informiert. Wie oben geschrieben ist es sehr angenehm für mich gewesen, ein riesen Laufwerk zu haben, wo ich einfach alle Daten rein schieben kann. Hier hab ich dann eine entsprechende Ordnerstruktur angelegt, mit der ich gut zurecht komme. Allerdings ist alleine einer der Stammordner 9,5TB groß ist. Passt also niemals auf eine Platte. Ich hab nun während des Lesens über SnapRAID mich schon langsam damit abgefunden, dass ich das in Zukunft wohl leider anders lösen muss, was einen ziemlich Mehraufwand bedeutete. Nun gibts zwar hier auch noch die Möglichkeit des Poolings, allerdings ist das ja auch immer nur lesend. Nun hab ich beispielsweise ein Tool (Mediaelch, kann ich sehr empfehlen!) Welches eben genau in diesem riesen Ordner (samt Unterordner) rumarbeitet. Im Falle dass ich Die Dateien über mehrere Platten verteilen müsste würde alleine hier der Aufwand sehr steigen. So weit ich das lesen konnte kommt hier AUFS ins Spiel, welches in der Lage ist einen pool anzulegen, der auch schreibbar ist. Ist das richtig? Wie funktioniert das in der Praxis? Entstehen Nachteile dadurch?"
..... Genau dafür ist ja AUFS da .... es sorgt für dieses Pooling.....wie beim Raid.....

"Auch wenn Geschwindigkeit eher zweitrangig ist: So weit ich verstanden habe läuft das pooling über SAMBA/NFS. Wie schaut es da mit der Geschwindigkeit aus, da die Daten ja sicher über einen Virtuellen Netzwerkadapter geschleift werden? Erreiche ich hier wenigstens annähernd die Plattengeschwindigkeit (ca. 120MB/s read)? (Was mir durchaus reichen würde)"
.....Nun ... die Geschwindigkeit ist ja von mehreren Faktoren abhängig ... auch von der Hardware.
     http://forum.nas-portal.org/content.php?50-Wie-schnell-ist-mein-NAS-%96-Das-sollten-Sie-beachten! mal dazu....

"Ich bin am überlegen, wie ich in meinem Fall das einfach und bequem mit den Snapshots realisiere. Wie gesagt, der Rechner läuft nicht 24/7, da wird es mit einem cronjob ja schon schwierig. Irgendwelche Ideen / Vorschläge?"
 ....... ja ... Trennung von NAS / Server und Workstation ;-)
         mal ehrlich ... notfalls fällt halt ein Snapshot aus oder er wird nachgeholt. DAS geht zwar MASSIV zu Lasten der Sicherheit (*zwinker) ... ganz ehrlich ..... wenn Du Dir solche Gedanken um die Sicherheit machst, MUßT DU geradezu den Server trennen; ECC-Ram, eine Hardware, die das auch unterstützt; USV ist zwingend etc.  ... verstehst Du, was ich meine? Es wird IMMER ein gewisses Restrisiko bleiben - je nach Aufwand, den Du betreibst.....

"Wie schaut es generell mit der Stabilität von dem ganzen aus? Läuft das alles gut? Gibts vielleicht auch negative Erfahrungen damit? (Nur damit ich weiß, auf was ich mich ein lasse)"
..... hierzu kann ich nur an Joogie verweisen .... DER Experte für Snapraid / AUFS

"Kann ich (wenn der Rechner aus ist), so eine Datenplatte auch einfach mal kurz irgendwo hin mit nehmen, um beispielsweise Daten von ihr herunter zu kopieren? Oder könnte das zu Problemen führen?"
.... eben nicht! Das ist es doch!
     Jede Platte kann beliebig raus genommen werden - ist einzeln lesbar (!) - es muss kein Raid aufgedröselt oder migriert werden - die Platte ist einzeln kopierbar; lesbar etc.

"Wie schaut es mit Limitierungen (auch im Zusammenhang mit AUFS) aus? Hab ich hier auch wieder ne 16TB-Grenze oder ähnliches?"
    keine Ahnung ..... davon habe ich nichts gelesen -> Joogie.....

"Auch wenn mir nun schon mehrfach zu btrfs geraten wurde. Mein Bauch sagt mir: Sofern es möglich ist, sollte ich lieber beim etablierten ext4 bleiben. Ich sehe in der Konstellation mit dem SnapRAID auch keinen nennenswerten Vorteil von btrfs gegenüber ext4, oder gibts da doch was?"
... doch .. wie bereits beschrieben!
    btrfs verbindet die Vorteile "richtiger" Systeme (mit entsprechend hohem Hardware-Aufwand) mit real vorhandener Häufigkeit des Vorhandenseins, soll weniger
    anspruchsvoll sein - drastisch
    http://www.technikaffe.de/anleitung-337-rockstor__linux_nas_loesung_auf_centos_7_basis_mit_btrfs .... ein Stück weiter runter intensiv über btrfs ....

"Wenn ext4: Welche Parameter sind hier sinnvoll? Vielleicht "large" oder "64Bit"?"
..... keine Ahnung ... ich überlasse das OMV....

"Laufen beim sync / scrub / check dann eigentlich wieder alle Platten, oder bleibt auch hier ein Teil im Standby?"
.... na ... muss ja ... wie soll sonst die Paritätserstellung erfolgen für ALLE Daten?
;-)

"Hast du Erfahrungen, wenn ich mit Programmen wie Kodi oder Plex auf das SnapRAID zugreife? Laufen dann wieder alle Platten an (Kodi liest ja die Bilder und nfo's ein)?"
... wie gesagt - praktische Erfahrungen habe ich selbst noch nicht, weil mein Server noch auf OMV 3 wartet. Ich hatte keine Lust, jetzt alles mit OMV 2.x aufzusetzen und
    dann nochmal neu anzufangen. OMV 2.x basiert ja auf Debian 7 - OMV 3 auf Debian 8
    Aber Du kannst davon ausgehen, dass bei JEDEM Zugriff aus logischen Gründen ja auch die Platten anlaufen müssen, es sei denn, Du hättest Anwendungen, die eine Art
    Datenbank für Medien etc. haben, und diese nicht laufend aktualisiert wird

"Was ist, wenn das System herunter gefahren / neu gestartet wurde, bevor der Sync durchgeführt wurde?"
... ich vermute mal, dass das den Sync abbricht.....

"Nur die Platte auf der die Daten - auf die ich zugreife - liegen, wird aus dem Standbye geholt. Muss mich zwar dann wieder dran gewöhnen dass es einen Moment dauert, biss ich auf die Platte zugreifen kann (beim RAID6 ist der Zugriff ja instant) aber das ist schon ne feine Sache. Alleine was man da an Strom/Wärme/ Lautstärke und Verschleiß einsparen kann. Feine Sache. In der Praxis hab ich eine HDD mit rund 15W (an der Steckdose) gemessen. Das macht bei 8 Platten: 8*15=120Watt (abgezogern der einen die auch beim SnapRAID läuft)"
... *grins
    Man kann nicht ALLES haben ..... *lol

"Verwendung unterschiedlich großer Platten. Wird für mich dann mal relevant, wenn die jetzigen Laufwerke voll sind und ich auf 8TB Platten upgraden muss. Das ist bei RAID5/6 schon erheblich mehr Aufwand."
... und zwar heftigst (!), wenn Du nicht gerade einen 400EUR+ Hardware-Controller hast.....

"Durch das Snapshotting habe ich eine begrenzte Möglichkeit Daten wieder herzustellen die versehentlich gelöscht wurden."
.... nun ... eine gwisse Eigenverantwortung traue ich Dir zu ... auch die, eine Art Papierkorb einzurichten *schmunzelt

"Eigentlich nur eine Sache: Das ich nicht ein Großes Laufwerk habe, aber das lässt sich hoffentlich mit AUFS kompensieren!?"
... Genau DAS macht AUFS ja ..... *lächelt

"Unterm Strich bin ich total begeistert ...."
.... freut mich sehr zu hören .....

"....von deinem Vorschlag ........"
*knicks Danke .....

"....und werde gleich mal eine VM mit einem entsprechenden Testszenario aufsetzen......"
...sehr schön *schmunzelt
Wenn Männer was zum Spielen haben, sind sie friedlich *lol

".... Bis dahin Entschuldigung für den doch sehr ausführlichen Post und die vielen Fragen. ...."
never mind .... you´re welcome .... wie der Brite sagt.....

" .... Ich bin dir sehr dankbar! :) ..."
... sehr gern ... freut mich, wenn ich kleines Menschlein und selbst noch Linux-Anfängerin etwas sinn- und geistvolles beitragen konnte. *knicks

"...Beste Grüße, Arny."
Alles Liebe
Michelle







Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #6 am: 21.02.2016, 19:02:01 »
Danke für deine Antworten! :) Und ja, mit einem neuen Spielzeug sind die Männer im allgemeinen friedlich! ;) Wobei sich in den letzten Wochen IT-Technisch so viele Probleme gehäuft haben, dass ich auch froh bin, wenn mal wieder alles einfach nach meinen Vorstellungen läuft. Neben dem Homeserver, wo ich mich um das RAID und den bech...eidenen "DTS Passthrou" (ja auch schaue mit der Kiste auch meine Filme) kümmern muss, muss ich auch noch meinen Root-Server komplett neu einrichten. Da ist auch noch mal ne Hürde für sich. Aber wie sagt man so schön? In der Ruhe liegt die Kraft!? :)

Eine Frage muss ich dir noch mal konkret stellen: Kann ich mit AUFS auch auf den pool schreiben? Wenn ja, wie läuft da die Datenverteilung?

Dein Vorschlag mit Workstation/Homeserver trennen ist prinzipiell gut und richtig, aber derzeit für mich (preislich) nicht umsetzbar und auch nicht notwendig. Die Kiste ist für mich schon genau richtig so, wie ich sie gebaut habe. Der Core i7 4770T ist stromsparend (45Watt) und dennoch flott genug. Samt 16GB RAM und SSD, gepaart mit der Möglichkeit hier 3 Monitore anzuschließen (aktuell hängen 2 + 1 Fernseher für Filme dran), ist es das Ideale Arbeitsgerät für den heimischen Schreibtisch (für mich). Und am Ende stört es doch keineswegs, dass er noch zusätzlich die Funktionalität des NAS erfüllt!? Am Ende greife ich eh (fast) alleine auf die Daten zu. Daher ist auch einfach keine Notwendigkeit dass die Kiste 24/7 läuft. Ein weiterer nicht unerheblicher Vorteil für mich: ich muss nur 1 Kiste Pflegen! Als Admin kann ich dir sagen: je mehr Geräte, um so mehr Arbeit / Ärger. Das ist ein Naturgesetz! ;) Meine Zukünftige "Workstation" wird auch eher ein Laptop werden. Aber da gibt es Momentan einfach nichts was mir zusagt und das Geld muss man ja auch erstmal übrig haben! :) Aber das steht alles auf einem anderen Blatt. Wie gesagt, ich stimme dir unterm Strich zu, aber ich hab da meinen eigenen - für mich sehr gut funktionierenden - Weg gefunden.

Zu OVM: auch wenn in der 3er Version da nachher ein Debian 8 drunter ist, so bleibt es abgespeckt. Wenn es danach ging hätte hier heute auf dem Rechner schon etwas wie OVM drauf sein können. Aber, wie soll ich sagen... ich mag solche beschnittenen Betriebsysteme einfach nicht, weil sie mir zu unflexibel sind. Außerdem bin ich dann immer auf eine kleine Scharr von Entwicklern angewiesen, die daran arbeiten. Wenn ich ein vollwertiges Linux benutze erhalte ich mir alle Möglichkeiten und genieße den Vorteil einer großen Entwickler-Community. Schau mal. Ein Arbeitskollege hatte sich damals zum selben Zeitpunkt wo ich mir den Homeserver eingerichtet habe auch ein (kleineres) NAS zusammen gebaut und auch einer dieser fertigen NAS-Distributionen drauf gehauen (glaub FreeNAS). Hätte ich ihm gleich getan, hätte ich Heute den ganzen Kram, den ich mit meinem RAID veranstalte nicht machen können. Ich kann dir aus meiner Admin-Tätigkeit heraus sagen: es gibt niemals die Eierlegende-Wollmilchsau die ALLE mit Allem glücklich macht. Es gibt immer nur ein System, was für diesen einen Anwendungsfall besonders gut funktioniert! ;) Das QNAP was wir damals in der Firma am laufen hatten war ein ähnlicher Fall. Eigentlich ein Debian-Basiertes Betriebssystem mit vielen Funktionen. Aber dennoch beschnitten. Weiterhin war da ein Softwarebug drinne, der uns richtig bösen Ärger gemacht hat. Wahrscheinlich ist dieser bis Heute nicht behoben. Und QNAP nimmt auch noch Geld (und nicht wenig) für so etwas. Nee nee... In manchen Fällen machen solche Embedded-Betriebsysteme sinn (Unser Router mit pfSense war super! ;) ) aber ich mag dann doch lieber die Freiheit eines Vollwertigen Betriebssystems! ;) Mich stört es auch überhaupt nicht, dass ich dann für SnapRAID keine hübsche Klicki-Bunti-Oberfläche habe. Ich bin eh so ein Consolen-Heini (Serveradmin eben)! :D

BTRFS: Mal ehrlich: welcher normale Heimanwender hat heute schon ECC-Speicher in seinem PC? Und das Performance-Argument macht man doch an anderer Stelle wieder zu nichte, da hier ganz andere Flaschenhälse sind. Als Contra spricht (für mich) gegen btrfs immer noch, dass ich es noch nicht für ausgereift halte (und standardmäßig nicht in Debian-basierten Systemen enthalten ist). Hier greift wieder eine der Informatik-Grundregeln: "Don't touch a running System". Ext4 läuft und erfüllt voll und ganz meine Bedürfnisse. Wie gesagt, so lange ich keinen erheblichen Mehrwert (für mich) erkennen kann, werde ich doch lieber bei ext4 bleiben. Und dank vollwertigem Betriebssystem kann ich das später auch noch ändern. ;)

Zum Abschluss bleibt wohl nur zu erwähnen, dass eben genau das schöne in der Linux-Welt ist. Ich kann mir alles meinen Bedürfnissen entsprechend so zurecht basteln, wie ich es brauche. Ich kann ein paar Sachen übernehmen, und bei anderen bleibe ich, wo ich gute Erfahrungen gemacht habe. So werde ich wohl deinem Vorschlag folgen und SnapRAID + AUFS einsetzen, aber den Rest mache ich dann lieber nach meinen Gutdünken. Aber für Heute ist Feierabend und Morgen werde ich dann mal meine neue VM quälen. :)

Lieben Gruß
Arny

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #7 am: 21.02.2016, 19:29:13 »
lese Dir mal zu btrfs den verlinkten Artikel durch ....
http://www.technikaffe.de/anleitung-337-rockstor__linux_nas_loesung_auf_centos_7_basis_mit_btrfs

Lese Dir bitte auch noch einmal diesen Artikel durch, der für "normale" Anwender gedacht ist und super erklärt:
http://www.technikaffe.de/anleitung-242-snapraid_und_aufs_unter_openmediavault_als_raid_5_6_ersatz
« Letzte Änderung: 21.02.2016, 19:58:42 von Michelle_Br »

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #8 am: 21.02.2016, 19:50:07 »
lese Dir mal zu btrfs den verlinkten Artikel durch ....

Welchen genau meinst du?

Lese Dir bitte auch noch einmal diesen Artikel durch, der für "normale" Anwender gedacht ist und super erklärt:
http://www.technikaffe.de/anleitung-242-snapraid_und_aufs_unter_openmediavault_als_raid_5_6_ersatz

Hab ich gleich als erstes schon ausführlich. Und danach hab ich noch die komplette Homepage von snapraid.it gelesen ;)
Ich weiß, mit OMV ist es sehr einfach, aber einfach ist nicht immer der beste Weg! ;)


Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #10 am: 21.02.2016, 23:08:37 »
Danke dir!  :)

PPA ist auch immer schön! ;) https://launchpad.net/~tikhonov/+archive/ubuntu/snapraid

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #11 am: 21.02.2016, 23:16:31 »
*lacht
Lass´das ja mal die Spezi´s hier nicht hören......
... Fremde ppa´s gefährden Ihr System ......

;-)

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #12 am: 21.02.2016, 23:19:26 »
Zitat
... Fremde ppa´s gefährden Ihr System ......
Falsch.
"Konnen ihr System beschädigen" und das ist auch schon öfter vorgekommen, kommt immer auf das PPA an.
Und PPA's sind immer "fremd".  :P

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #13 am: 21.02.2016, 23:25:10 »
Und die Spezis haben ja auch recht! ;) Ich mag sie halt, das muss eben jeder für sich selbst entscheiden.

Mal noch ne Frage an dich: Warum eigentlich noch SnapRAID, wenn brfs selber schon alle Funktionalitäten abbilden kann die SnapRAID auch kann? Das ist doch Doppelgemoppel!?

Re: [LM17.3] Welches Dateisystem für großes RAID (16TB+)?
« Antwort #14 am: 21.02.2016, 23:30:47 »
SO fit bin ich nun auch nicht ....*lacht
Aber nach dem, was ich so gelesen habe, ist es ja so, dass brfs eben noch neu ist; sich noch nicht so etabliert hat ... genau kann ich Dir das auch nicht sagen. Vor allem sollte man IMMER den neuesten Kernel einsetzen. Ich glaube, dass DAS eines der Hauptgründe ist, warum es kaum verwandt wird - bisher. Die gängigen Distro´s setzen ja in der Regel auf Stabilität; auf Bewährtes..... LM aktuell auf die 3.19 - bis LM 17.1 war´s sogar noch 3.13 (?) ... aktuell ist 4.4 glaube ich...... (?)