Hallo, ich wäre für Tips dankbar, die mir die folgende Entscheidung erleichtern: Ich habe hier einen Debian Rechner mit 5 Platten als md Raid 6 und einem seit Ur-Zeiten (so knapp 10 Jahre, denke ich) aktualisierten Debian (aktuell stretch). Das Motherboard ist auch in etwa so alt, die Platten sind neuer. Ich schraube gerade ein neues System zusammen, das mit 32 GB ECC Ram und einem Xeon D Prozessor ausgerüstet ist, also etwas moderner. Es gibt ein Backup aller wichtigen Daten, das Raid dürfte also bei der anstehenden Umrüstung zerstört werden. Ich liebäugele damit, auf FreeNAS umzustellen, komme aber leider, weil ich praktisch keine Erfahrung mit BSD habe, nicht wirklich auf eigenen grünen Zweig. Anforderung: Zugriff über TimeMachine, AppleShare Fileserver AFP, SMB Schreiben auf das Volume per rsync cron rsync reads mit ssh authentication müssen auf dem System ausgeführt werden Nach meinen Recherchen müsste das soweit mit FreeNAS problemlos gehen. Vorteile Debian: Ich brauche das raid volume nicht zerstören. Ich könnte den Rechner auch für andere Aufgaben nutzen, wobei ich aktuell als Vision höchstens eine lokale MediaWiki und einen iTunes Media Server sehe. Ich kenne mich mit Debian einigermaßen aus Nachteile Debian: Das installierte System ist zwar aktuell, aber echt schon sehr alt und es gibt immer wieder überraschende und damit nervige Inkonsistenzen, zum Beispiel kaputte Alternatives. Das Filesystem ist anfälliger für Defekte als ZFS. Das letzt Raid rebuilden und fsck hat Tage gedauert, was wirklich nervt, weil während dieser Zeit das System nicht für Backups zur Verfügung steht Vorteile FreeNAS Wenn ich das richtig sehe, kann FreeNAS alles was ich will von Haus aus. ZFS scheint, weil es transaktional ist, recht robust zu sein. Die neue Hardware ist ok für FreeNAS und durch die jungfräuliche Installation wäre auch alles aktuell und konsistent. FreeNAS bootet schnell. Nachteile FreeNAS Die Paketverwaltung unter BSD macht mir Sorgen, da entsteht auf jeden Fall ein hoher Lernaufwand. Wenn man schon FreeNAS benutzt, dann auch eher als das, was es eben ist, eine Appliance und kein LAMP Server. Ich kann das Raid später nicht mehr erweitern, habe aber eh alle 6 Sata Ports des Mainboards voll. Eventuell: Ist es eine praktikable Idee, wenn ich dann das System doch mal LAMP mäßig benutzen will, einfach ein Debian in einer Virtuellen Maschine auf dem FreeNAS laufen zu lassen? Danke für jeden Hinweis. Timm
Mal unabhängig von deiner OS-Wahl würde ich BTRFS nutzen, ob Debian das unterstützt weiß ich nicht, aber Ubuntu Server kann das und FreeNAS ziemlich sicher auch. Von der Lizenz ist das wesentlich netter als ZFS, weil es eben frei verfügbar ist. Außerdem kann man "Subvolumes" anlegen, also praktisch Unterpartitionen, die aber nicht größenbeschränkt sind. Das finde ich persönlich für ein Datengrab, was aber noch andere Aufgaben übernehmen soll (Bei mir verwaltet mein Server neben einem Backup meiner Daten noch eine Owncloud) äußerst praktisch. Und du könntest halt Ubuntu (wahrscheinlich auch Debian, aber so groß ist der Unterschied ja nun auch nicht) verwenden, was du halt mehr oder weniger schon kennst.
Rufus Τ. F. schrieb: > Wozu braucht ein NAS 32 GB RAM? FreeNAS mit ZFS ist ziemlich speicherhungrig wenn man es performant betreiben möchte - ansonsten würde wesentlich weniger reichen. Du kennst dich gut mit Debian aus - warum nicht neu aufsetzen u. deine Daten migrieren? Für den Privatbereich? ein solche Kiste als nur-NAS zu betreiben wäre mir zu overdressed u. aufgrund der Strompreise zu teuer - da würd ich eher eine VM-Kiste mit Proxmox gestalten, welche mehr Dienste separiert zur Verfügung stellen könnte u. somit flexibler im Einsatz wäre. jm2c
Vielleicht ist ja hier etwas für Dich dabei: https://www.wdc.com/de-de/products/wd-recertified.html Kennst Du OpenMediaVault? Basiert auf debian: https://de.wikipedia.org/wiki/OpenMediaVault
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Wozu braucht ein NAS 32 GB RAM? Bei XFS bespielsweise scheint es einen Zusammenhang zwischen der Filesystem-Grösse und dem für einen Filesystem-Check erforderlichen RAM zu geben.
Hallo Rufus, Rufus Τ. F. schrieb: > Wozu braucht ein NAS 32 GB RAM? das hatte ich nur erwähnt, damit klar ist, dass das System grundsätzlich für ZFS ausreichend Speicher hat und FreeNAS deswegen nicht schon deswegen ausscheidet. vlg Timm
Rufus Τ. F. schrieb: > Wozu braucht ein NAS 32 GB RAM? Faustregel für FreeNAS jedenfalls lautet: pro 1TB Storage 1GB RAM...
Timm R. schrieb: > Nachteile FreeNAS > Die Paketverwaltung unter BSD macht mir Sorgen, da entsteht auf jeden > Fall ein hoher Lernaufwand. Oder du lässt FreeNAS einfach, wie's ist, und installierst dir mithilfe der FreeNAS-Jails einfach zusätzlich ein Debian - oder eine der zig fertigen Knopfdruck-VMs. Dann wäre auch dein Xeon nicht so unterbeschäftigt... :)
Hallo, jz23 schrieb: > Mal unabhängig von deiner OS-Wahl würde ich BTRFS nutzen also ich muss zugeben, dass sich BTRFS extrem interessant liest! Allerdings lese ich gerade auf https://btrfs.wiki.kernel.org/index.php/RAID56: >The parity RAID code has multiple serious data-loss bugs in it. >It should not >be used for anything other than testing purposes. das klingt eher so, als ob man mit sowas doch lieber noch ein paar Jahre warten sollte. FreeNAS ZFS und md raid sind ja beide sehr alt und erprobt. Trotzdem vielen Dank! vlg Timm
Rufus Τ. F. schrieb: > Wozu braucht ein NAS 32 GB RAM? z.b. fs-caches
1 | 13:39# /home/cam/ time rsync -WHvan -e ssh server://home/ /tmp/ 2>&1 | wc -l |
2 | 29230 |
3 | |
4 | real 0m7.106s |
5 | user 0m0.148s |
6 | sys 0m0.088s |
7 | 13:39# /home/cam/ time rsync -WHvan -e ssh server://home/ /tmp/ 2>&1 | wc -l |
8 | 29230 |
9 | |
10 | real 0m0.862s |
11 | user 0m0.104s |
12 | sys 0m0.032s |
aber 16G reichen, je nach laufender software und nutzungsprofil, natürlich auch.
Timm R. schrieb: > Allerdings lese ich gerade auf > https://btrfs.wiki.kernel.org/index.php/RAID56: > >>The parity RAID code has multiple serious data-loss bugs in it. >>It should not >be used for anything other than testing purposes. Das kannte ich noch nicht. Aber ich nutze bei mir auch nur eine einzelne Festplatte.
Timm R. schrieb: > Nachteile Debian: > ... > Das Filesystem ist anfälliger für Defekte als ZFS. Und welches Dateisystem soll das sein? ext2? ext3? ext4? reiserfs? Hier mal eine kleine Auswahl an Dateisystemen: https://wiki.debian.org/FileSystem Einfach zu sagen "das Dateisystem ist kacke" funktioniert nicht, weil es das eine Dateisystem nicht gibt, schon gar nicht unter Linux. Keiner hier weiss, was du da wie installiert hast. Von daher ist deine Aussage, dass das Dateisystem von Debian ein Nachteil waere, schlicht mist.
Kaj G. schrieb: > Timm R. schrieb: >> Nachteile Debian: >> ... >> Das Filesystem ist anfälliger für Defekte als ZFS. > Und welches Dateisystem soll das sein? ext2? ext3? ext4? reiserfs? > Hier mal eine kleine Auswahl an Dateisystemen: > https://wiki.debian.org/FileSystem > > Einfach zu sagen "das Dateisystem ist kacke" funktioniert nicht, weil es > das eine Dateisystem nicht gibt, schon gar nicht unter Linux. > Keiner hier weiss, was du da wie installiert hast. Von daher ist deine > Aussage, dass das Dateisystem von Debian ein Nachteil waere, schlicht > mist. Hinsichtlich des Kriteriums "transactional", gibt es keinen Unterschied zwischen ext2, ext3, ext4 und ReiserFS. Ich meinte allerdings ext4. vlg Timm
Timm R. schrieb: > vorteile ... nachteile dein problem ist: du willst es dir einfach machen - es soll einfach funktionieren. das dilemma ist: freenas unter freebsd verspricht das, aber wenn irgendwas nicht geht hast du wieder viel arbeit weil du dir freebsd reinziehen musst. > Anforderung: > Zugriff über TimeMachine, AppleShare Fileserver AFP, SMB > Schreiben auf das Volume per rsync > cron rsync reads mit ssh authentication müssen auf dem System ausgeführt > werden wenn debian oder ubuntu das kann, würde ich bei dem betriebssystem bleiben das ich kenne. und zum thema RAID5/6 rebuild zeiten… TB-platten brauchen so lange - je mehr gemacht werden muss desto länger dauerts, um mal das offensichtliche in worte zu packen. mehr geschwindigkeit bekommst du durch ssd's und hardware-raid controller, aber nicht die billigen für 50€ ^^ obwohl… hm… https://www.ebay.de/sch/i.html?_nkw=perc+controller
Wenn die gewählte Hardware die Ansprüche an das NAS wiederspiegeln, dann ganz klar FreeNAS. Wenn die Hardware "gerade über war", dann einfach das, womit du am besten klarkommst.
Timm R. schrieb: > das klingt eher so, als ob man mit sowas doch lieber noch ein paar Jahre > warten sollte. FreeNAS ZFS und md raid sind ja beide sehr alt und > erprobt. RAID 1 ist ok, aber Finger weg von RAID 5.
Jupp schrieb: > Wenn die gewählte Hardware die Ansprüche an das NAS wiederspiegeln, dann > ganz klar FreeNAS. Also es saugt abends so 5 bis 8h Backups von diversen Servern, insgesamt so etwas unter 500 GB und tagsüber wird als Höchstlast im Verlauf von vielleicht 8 bis 9 Stunden etwa die selbe Menge von maximal 4 Usern lokal gelesen und vielleicht 10-20 GB geschrieben. Viel ist das nicht, aber das aktuelle System ist damit komplett am Limit und die Hoffnung wäre, dass das neue System ein klein wenig Luft rein bringt. Ein Grund für die Hoffnung ist, dass zB bei rsync Transfers ganz klar die CPU bremst. Und dass eben jetzt das Filesystem beschädigt war, weil der Rechner unerwartet neugestartet ist. Das sollte ja bei ZFS verträglicher ablaufen. vlg Timm
:
Bearbeitet durch User
Timm R. schrieb: > Also es saugt abends so 5 bis 8h Backups von diversen Servern, insgesamt > so etwas unter 500 GB und tagsüber wird als Höchstlast im Verlauf von > vielleicht 8 bis 9 Stunden etwa die selbe Menge von maximal 4 Usern > lokal gelesen und vielleicht 10-20 GB geschrieben. > > Viel ist das nicht, aber das aktuelle System ist damit komplett am Limit > und die Hoffnung wäre, dass das neue System ein klein wenig Luft rein > bringt. Ein Grund für die Hoffnung ist, dass zB bei rsync Transfers ganz > klar die CPU bremst. Richtig, diese Anforderungen sind ziemlich überschaubar. Da Du ohnehin für dickere Hardware gesorgt hast, ist es IMHO sinnlos, das bekannte System und die bekannte Software wegzuwerfen. FreeNAS und die BSDs sind feine Software, wenn man sich damit auskennt. Wenn man sich nicht damit auskennt, ist es totaler Quatsch, sich in ein weiteres UNIXoides System einzuarbeiten, das man am Ende nur auf einem einzigen System betreibt und mit dem man ansonsten wenig Berührung (und damit Training!) hat. Denn das bedeutet, daß man bei jeder Konfiguration, und noch mehr bei jedem Fehler, sich wieder in die Besonderheiten dieses Systems einarbeiten muß. Das heißt: schon wenn Du einzelne Einstellungen umsetzen willst, dauert das im Zweifelsfall bedeutend länger als mit dem bekannten System. Und im Disasterfall leiden RTO und eventuell RPO. Been there, done that, got no fun but a t-shirt. Ein anderer Punkt ist, daß Du moderne Hardware mit 1 GBE-Netzwerk- plus Disk-I/O auf rotierendem Rost ohnehin nicht ausgereizt bekommst. Ob Deine CPU sich nun unter Debian, Ubuntu, *BSD oder FreeNAS langweilt, und unter welchem System Dein Arbeitsspeicher nicht genutzt wird, spielt eigentlich nicht wirklich eine Rolle, oder? Wenn Du ein paar Euro übrig hast und Deinem Netzwerk einen echten Boost spendieren willst, dann rüste mit 10 GBE nach -- einen 8-Port-Switch mit RJ45 gibt es schon für unter 800 und NICs für unter 210 EUR pro Stück. So Du dann auch noch was für Deinen Disk-I/O tun willst, sind SSDs schneller als gedrehter Rost -- gerade im wahlfreien Zugriff -- und für besonders performante "Festplatten" mit einer gestackten Speicherlösung bieten sich die extrem performanten PCIe-SSDs an, die können bis zu knapp 5 GB/s lesen und 4 GB/s schreiben. Aber dafür braucht man dann ein nochmals deutlich schnelleres Netzwerk als 10 GBE, und dann wird es ziemlich teuer. In so einem Fall kann man dann vielleicht auch mal über Dateisysteme, Logical Volume Management, Hard- versus Software-RAID und ähnliche Dinge reden. Bis dahin solltest Du Dein Augenmerk IMHO stärker auf Ease-of-use sowie Deine Kenntnisse und Erfahrungen richten. Diese Softskills sind im langfristigen Betrieb von Systemen und Software viel wichtiger als die vergleichsweise unwichtige Frage nach bestimmten Implementierungen. Deswegen probiert man neue, unbekannte Software nicht ausgerechnet auf Systemen aus, die der Datensicherheit und -Verfügbarkeit dienen. Da setzt ein professioneller Admin auf langfristig stabile Systeme, mit denen er sich sehr gut auskennt, und die er zur Not morgens um vier betrunken im Halbschlaf bedienen kann. Wenn Du FreeNAS und / oder *BSD ausprobieren willst: nur zu, das ist tolle Software, keine Frage. Aber vielleicht solltest Du das erstmal in einer VM ausprobieren, ein paar Monate lang benutzen (!), und ein wenig Erfahrungen damit sammeln, bevor Du ernsthaft erwägst, es produktiv zu nutzen. YMMV. > Und dass eben jetzt das Filesystem beschädigt war, weil der Rechner > unerwartet neugestartet ist. Das sollte ja bei ZFS verträglicher > ablaufen. Normalerweise startet eine Linux-Maschine nicht "einfach so" unerwartet neu. An Deiner Stelle wäre ich da wißbegierig, was der Grund dafür war. Und: warum hat so eine wichtige Büchse keine USV?
A. K. schrieb: > Timm R. schrieb: >> das klingt eher so, als ob man mit sowas doch lieber noch ein paar Jahre >> warten sollte. FreeNAS ZFS und md raid sind ja beide sehr alt und >> erprobt. > > RAID 1 ist ok, aber Finger weg von RAID 5. Ich hab' hier ein NAS mit OpenMediaVault und RAID 6 zu laufen, weil ich befürchtet habe, dass ausgerechnet beim Rebuild nach einem Einzelplattenausfall eine zweite Platte den Geist aufgibt. Meinst du dieses Szenario mit "Finger weg" oder gibt's da noch weitere Probleme, die ich mit mit RAID 6 auch einfange? Ich hab' davon wenig Ahnung, aber es funktioniert gerade so schön...
Matthias L. schrieb: >> RAID 1 ist ok, aber Finger weg von RAID 5. > > Ich hab' hier ein NAS mit OpenMediaVault und RAID 6 zu laufen, weil ich > befürchtet habe, dass ausgerechnet beim Rebuild nach einem > Einzelplattenausfall eine zweite Platte den Geist aufgibt. Ich hatte schlecht gequotet. Das bezog sich nur auf btrfs.
A. K. schrieb: > RAID 1 ist ok, aber Finger weg von RAID 5. Mit dieser Aussage bezog ich mich nur auf btrfs: >The parity RAID code has multiple serious data-loss bugs in it. >It should not >be used for anything other than testing purposes.
Ah, verstehe, danke! Mein Szenario war/ist nämlich ähnlich wie das des OP: Es soll zwar individuell konfigurierbar sein, aber andererseits out of the box schon mal ohne großen Aufwand laufen. Und das hab' ich als Linux-Dummie mit OMV problemlos hinbekommen.
A. K. schrieb: > Matthias L. schrieb: >>> RAID 1 ist ok, aber Finger weg von RAID 5. >> >> Ich hab' hier ein NAS mit OpenMediaVault und RAID 6 zu laufen, weil ich >> befürchtet habe, dass ausgerechnet beim Rebuild nach einem >> Einzelplattenausfall eine zweite Platte den Geist aufgibt. > > Ich hatte schlecht gequotet. Das bezog sich nur auf btrfs. Ich würde generell von BTRFS und auch ZFS abraten. Beide Filesysteme sind noch relativ neu, zumindest wenn man sie mit direkten Konkurrenten wie XFS oder EXT4 vergleicht. Dazu kommt noch, daß beide mehr oder weniger am Tropf von Oracle hängen und was deren langfristigen Support von Open Source angeht - da traue ich denen nicht weiter, als ich spucken kann. So wie es aussieht, brauchst du die zusätzlichen Features ohnehin nicht. Insofern schließe ich mich klar Sheeva Plug an: bleib bei dem was du kennst und was funktioniert. Sprich: Debian, md RAID und ein herkömmliches Filesystem ohne internen RAID-Support. LVM als Zwischenschicht ist auch eine gute Sache. Habe ich hauptsächlich wegen Crypto.
Axel S. schrieb: > Ich würde generell von BTRFS und auch ZFS abraten. Beide Filesysteme > sind noch relativ neu, zumindest wenn man sie mit direkten Konkurrenten > wie XFS oder EXT4 vergleicht. ZFS und ext4 sind etwa gleich alt.
Hallo, Axel S. schrieb: So wie es aussieht, brauchst du die zusätzlichen Features > ohnehin nicht. naja, dass ZFS transaktional ist finde ich schon sehr sehr heiß. Und die Snapshots, wenn sie denn so schnell sind, wie alle sagen wären auch sehr nett, ich könnte vor einem rsync poll einen Snapshot machen und wenn rsync fehlerfrei durchgelaufen ist und die Daten auf logische Konsistenz geprüft wurden den Snapshot löschen, oder vielleicht sogar erst einen order zwei Tage später. Das wäre schon sehr nett. Wenn ich das richtig verstanden habe, ist bei ZFS auch kein fsck mehr nötig und die Korrektur läuft durchgehend und ohne spürbare Performanceverluste. Dass es kein Write Hole bei ZFS gibt ist egal, weil es bei Raid 6 eh unwahrscheinlich genug ist und deduplikation brauche ich nicht und würde ich sowieso nicht benutzen. Vielleicht kann mir ja jemand sagen, wie der letzte Störfall mit ZFS ausgesehen hätte? Auf dem NAS befindet sich ein Image, dass von entfernten Rechnern gemounted wird, durch einen Fehler meinerseits ist das Image in der Größe explodiert, von etwas über 500 GB auf 1,5 TB, damit kommt der AFP Server (netatalk) auf meinem aktuellen System nicht klar (vermutlich RAM Problem?) jedenfalls führt jeder Schreibvorgang, Datei löschen, Datei neu anlegen oder auch die Volume Indexierung, egal ob auf das Image, oder ein anderes AFP Volume wenn das Image gemounted ist nach kurzer Zeit dazu, dass der AFP Server sang und klanglos stirbt. Was dazu führt, dass der Client versucht das Image wieder zu mounten, etc ... Ich glaube, dass dadurch das Filesystem beschädigt wurde, jedenfalls trat der letzte Defekt genau in diesem Rahmen auf. Dass die Daten selbst defekt sein können ist nur logisch, aber dass das Filesystem defekt war, war schon super nervig. Nach einem manuell herbeigeführten Neustart fuhr das System dann nicht mehr hoch, weil ja fsck nicht durchlief, ich konnte nicht mehr arbeiten und für die Wartung musste ich ja vor Ort an den NAS ran, mit den fscks die dann fällig waren, Sicherungskopien etc. pp. hat das schon Tage gedauert. Meine Erwartung wäre jetzt, dass mit ZFS nur die Datei beschädigt werden kann, die in dem Moment beschrieben wird, die Datei die neu angelegt wird eventuell nicht existiert oder deren Inhalt defekt, aber das Filesystem selbst sollte durch sowas eigentlich nicht berührt werden? Der Wartungsmodus durch ein defektes Filesystem ist eine sehr schlimme Sache und da dachte ich, könnte ZFS punkten? Vlg Timm
:
Bearbeitet durch User
Timm R. schrieb: > Und die Snapshots, wenn sie denn so schnell sind, Der Trick bei Snapshots in transactional filesystems liegt im CoW Verfahren. Snapshots entstehen da quasi als Nebeneffekt. Indem man den alten Zustand nicht löscht, wenn der neue committed wird, sondern aufhebt. Vereinfacht ausgedrückt. Folglich ist das eine sehr flotte Operation. Löschen kann schon etwas länger dauern, aber da wartet man nicht drauf. Es tut folglich auch nicht weh, auf gut genutzten Fileservern stündliche Snapshots anzulegen und nach 1-2 Tagen alle bis auf einen pro Tag wegzuwerfen (Erfahrung mit NetApp). Wie immer kommt das aber mit einem Preis, zumindest bei HDDs: Überwiegend partiell geschriebene Files fragmentieren. Beispielsweise Datenbanken und VM-Images. Mögen die anfangs am Stück gelegen haben, geht es nach einer Weile recht wild durcheinander zu. Bei Backups und full table scans von DBs auf HDDs kann recht spürbar werden. Bei SSDs ist das freilich egal. Snapshots in anderen Filesystemen arbeiten anders, etwa in NTFS. Da können Snapshots den Betrieb etwas ausbremsen, weil Inhalte beim Überschreiben von Daten live kopiert werden. CoW FSs schreiben stets an eine andere Stelle und ändern die Metadaten, klassische FSs mit Snapshots kopieren statt dessen vorher die alten Daten weg. > Wenn ich das richtig verstanden habe, ist bei ZFS auch kein fsck mehr > nötig Yep. Das war aber eigentlich auch schon bei journalling filesystems nicht mehr nötig. Oder hätte es nicht sein sollen. Bei JFS/JFS2 (AIX) hat das auch gut funktioniert. > und die Korrektur läuft durchgehend und ohne spürbare > Performanceverluste. Es läuft eher drauf raus, dass man keine Korrektur benötigt. Weil zumindest vom Prinzip her keine Inkonsistenzen entstehen können. > Vielleicht kann mir ja jemand sagen, wie der letzte Störfall mit ZFS > ausgesehen hätte? Transactional filesystems sichern dir zu, dass die Metadaten konsistent bleiben. Nach einem Crash hast du den letzten committed state intakt, was danach passierte ist weg. Ein File ist also entweder einmal da, oder weg, aber nicht zweimal da. Und Blöcke sind entweder frei oder belegt, nicht aber beides. Was es nicht zusichert: Dass ein DB- oder Disk-Image, in dem du eine halbe Stunde lang drin rumgeschrieben hast, nach einem Crash automatisch den Inhalt von vor dieser halben Stunde hat. Es hat den von vor ein paar Sekunden. Du kannst aber das File aus dem letzten Snapshot ziehen. > Der Wartungsmodus durch ein defektes Filesystem ist eine sehr schlimme > Sache und da dachte ich, könnte ZFS punkten? Das gehört zum Sinn solcher Filesysteme. Allerdings sollten eigentlich auch schon journalling filesystems per Grundansatz auch ohne stundenlangem fsck/chkdsk konsistent bleiben. Nur wird das da auf andere Art erreicht.
:
Bearbeitet durch User
A. K. schrieb: > Transactional filesystems sichern dir zu, dass die Metadaten konsistent > bleiben. Nach einem Crash hast du den letzten committed state intakt, > was danach passierte ist weg. Ein File ist also entweder einmal da, oder > weg, aber nicht zweimal da. Und Blöcke sind entweder frei oder belegt, > nicht aber beides. Für diese Zusicherung verlassen sich die Filesysteme aber auf die nächste Ebene darunter, die Controller und die Platten sowie deren Caches. Und gerade die Caches können zum Problem werden wenn sie die Daten in einer anderen Reihenfolge schreiben als sie das Filesystem gesendet hat. Eigentlich gibt es für dieses Problem Barriers in den Caches. Zum einen werden die aber nicht in jeder Kombination von Blockdevice-Stack unterstützt und weitergereicht, zum anderen habe ich auch schon Fälle von Filesystemfehlern bei Consumerplatten mit aktivierten Write-Cache gesehen, die ich darauf zurückführe daß die Barriers bei diesen Platten nicht funktionierten wie in der SATA-Spec vorgegeben. Die Barriers von SAS sind da außerdem sauberer spezifiziert.
Gerd E. schrieb: > Für diese Zusicherung verlassen sich die Filesysteme aber auf die > nächste Ebene darunter, die Controller und die Platten sowie deren > Caches. Yep. Das erklärt auch, weshalb NTFS trotz journalling eine ausgeprägte Neigung zu Filesytem-Checks hat. Microsoft kann sich nicht wirklich darauf verlassen, dass die I/O-Ebene korrekt arbeitet. AIX(JFS) und NetApp beispielsweise schon. Wobei mit SSDs dank der Metadaten des wear levelling noch eine möglicherweise inkonsistente Ebene hinzu kommt.
:
Bearbeitet durch User
Axel S. schrieb: > Ich würde generell von BTRFS und auch ZFS abraten. Beide Filesysteme > sind noch relativ neu, zumindest wenn man sie mit direkten Konkurrenten > wie XFS oder EXT4 vergleicht. Von Wikipedia:
1 | ext4: Erstveröffentlichung - 14.10.2008 |
2 | BTRFS: Erstveröffentlichung - 12.06.2007 |
3 | ZFS: Erstveröffentlichung - 06.2006 |
4 | XFS: Erstveröffentlichung - 1994 |
#JustMy2cent
A. K. schrieb: > Axel S. schrieb: >> Ich würde generell von BTRFS und auch ZFS abraten. Beide Filesysteme >> sind noch relativ neu, zumindest wenn man sie mit direkten Konkurrenten >> wie XFS oder EXT4 vergleicht. > > ZFS und ext4 sind etwa gleich alt. Angesichts des Track-Records der extN Filesysteme neige ich dazu, ext4 einen gewissen Vertrauensvorschuß einzuräumen ;) Gerd E. schrieb: > A. K. schrieb: >> Transactional filesystems sichern dir zu, dass die Metadaten konsistent >> bleiben. ... > Für diese Zusicherung verlassen sich die Filesysteme aber auf die > nächste Ebene darunter, die Controller und die Platten sowie deren > Caches. Das ist trivial. Und für journaling Filesysteme genau das gleiche. Oder Datenbanken. Allerdings funktionieren write-barriers ausgesprochen unauffällig. Zumindest auf unixoiden Systemen hatten wir damit noch nie Probleme. Die einzigen (letztendlich nie sauber aufgeklärten) Probleme gab es mal mit Windows. Da haben sich MS und der Treiberhersteller so lange gegenseitig den Schwarzen Peter zugeschoben, bis es keinen mehr interessiert hat.
Ich hab derzeit eine CentOS 7 box mit einem raid 1 und zwei weiteren Platten im Einsatz. In zwischen habe ich mit OpenMediaVault und Rockstor sowie FreeNAS angeschaut. Ich würde FreeNAS wegen ZFS nehmen, unter anderem wegen den Snapshots. Großteil lässt sich über eine GUI einrichten. Updates sollte es eh ewig gehen. Dazu hat iXsystems die größere kommerzielle Vertretung im Vergleich zu OMV und Rockstor. Weitere Sachen kannst du dann in Jails oder VMs nachinstallieren.
Hallo, die Sache mit den Festplattencaches: Kann ich an irgendeiner Kennzahl erkennen, ob die verwendeten HDDs da ein Problem haben? Ich habe WD Red, wegen des timeouts beim Lesen defekter Sektoren. vlg Timm
:
Bearbeitet durch User
Timm R. schrieb: > die Sache mit den Festplattencaches: > > Kann ich an irgendeiner Kennzahl erkennen, ob die verwendeten HDDs da > ein Problem haben? Mir ist keine zuverlässige bekannt. Wenn Du sicher gehen willst, schaltest Du die Write-Caches der Platten aus. Das kostet aber sehr kräftig Write-Performance. Klassischerweise kompensiert man das dann durch einen Hardware-RAID-Controller mit integriertem Cache und Batterie-Backup für diesen Cache. Da ist dann auch die Unterstützung von Barriers egal weil nach einem Stromausfall, hartem Reset etc. die Daten alle immer noch im batteriegepufferten Cache liegen und von dort bei nächster Gelegenheit auf die Platte wandern. Aber natürlich kann der Controller selbst auch sterben.
Ubuntu Server 16.04 LTS, alternativ CentOS oder Arch Linux. unRAID erfreut sich zunehmender Beliebtheit; ich fand's etwas komisch, daß es nur von USB-Stick läuft und nicht auf SSD installieren läßt. Finger weg von OpenMediaVault! Wenn irgendetwas unter der Oberfläche von OMV nicht funktioniert und man ergänzend 'manuell' in der Shell Änderungen vornimmt, fängt OMV erst recht an herumzuzicken.
Gerd E. schrieb: > kompensiert man das dann durch einen Hardware-RAID-Controller mit > integriertem Cache und Batterie-Backup für diesen Cache. Heutzutage sichert man den Cache besser mit Flash+Caps ab.
Matthias L. schrieb: > Ich hab' hier ein NAS mit OpenMediaVault und RAID 6 zu laufen, weil ich > befürchtet habe, dass ausgerechnet beim Rebuild nach einem > Einzelplattenausfall eine zweite Platte den Geist aufgibt. Ein NAS ersetzt kein Backup!
Hallo, jetzt habe ich noch mal eine Rückfrage, ich hatte ja einen Filesystem Defekt, meine Theorie war ja der mehrfach abstürzende AFP Server. Wenn ich das richtig verstanden habe, kann das aber auch bei einem journaling Filesystem (EXT4) nicht die Ursache sein, richtig? Was kann denn die Ursache sein? Ein Plattendefekt? 2 Drives haben einen Read-Error: ID# ATTRIBUTE_NAME VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 200 200 051 Pre-fail Always - 1 Kann das der Grund sein? Was können denn Gründe sein? Auf welche SMART Parameter würdet ihr achten um ein drive auszutauschen? Würdet ihr die mit dem Read Error schon austauschen? vlg Timm
Wie aus dem Wiki der ubuntuusers oder dem normalen Wikipedia-Eintrag hervorgeht, existiert keine Kennzahl im eigentlichen Sinne. Selbst eine Prüfung durch SMART ist IMHO mehr oder weniger Kaffeesatzleserei. Deshalb der ganze Aufwand mit Raid: Wäre eine genaue Vorhersage über Ausfälle möglich, würde man zumindest für private Zwecke liebend gerne auf ein Raid verzichten und es bei einem einfachen Backup belassen.
Markus schrieb: > Finger weg von OpenMediaVault! Wenn irgendetwas unter der Oberfläche von > OMV nicht funktioniert und man ergänzend 'manuell' in der Shell > Änderungen vornimmt, fängt OMV erst recht an herumzuzicken. Hast du da ein oder mehrere konkrete Beispiele? Ich stehe/ stand kurz davor OMV zu installieren.
Michi schrieb: > Hast du da ein oder mehrere konkrete Beispiele? Ich stehe/ stand kurz > davor OMV zu installieren. Ich hatte zwei neue Festplatten, für die erfolgreich ein Raid1 erzeugt wurde. Anschließend baute ich zwei vorher in einer Synology benutzte Platten in den Rechner ein, die von OMV sogar erfolgreich als weiterer Raid1-Verbund erkannt wurden. Dabei hätte ich es belassen können, dachte aber, es sei vielleicht doch besser, die zwei Platten nochmal komplett neu zu installieren. Also alles auf den Platten gelöscht und nochmal ein Raid1 erzeugt. Nach Stunden der Synchronisierung schien alles erfolgreich durchgelaufen zu sein, aber nach einem Neustart war alles weg. Das ganze habe ich mehrmals durchprobiert, immer dasselbe Ergebnis. Anschließend hatte ich die mdadm-Befehle in der Shell durchgespielt, aber irgendwie wollte OMV meine Änderungen in den config-Dateien der mdadm und der fstab nicht akzeptieren. Der blöde Sync dauert bei 2x8 TB und 2x5 TB fast einen ganzen Tag, mehrmaliges Ausprobieren kostet also eine Woche, danach hatte ich die Faxen dicke und hab' alles plattgemacht... Vermutlich irgendwelche Probleme mit initramfs (?). Außerdem basiert OMV 3 auf Debian 8, eine Installation auf einer über PCIe angeschlossenen SSD ist nur auf Umwegen möglich (Installation von Debian samt Backports, manuelle Installatio von OMV). Weiterhin störte es mich, daß ich nie genau wußte, was OMV im Hintergrund ausheckt oder auch nicht. Last but not least scheint mir der Support gering auszufallen: Außer dem Entwickler sind im OMV-Forum hauptsächlich zwei-drei Leute unterwegs, die imstande sind inhaltlich korrekte Antworten zu liefern.
Pete K. schrieb: > Ein NAS ersetzt kein Backup! Hab' ich das irgendwo behauptet?? Nein, hab' ich nicht.
Timm R. schrieb: > jetzt habe ich noch mal eine Rückfrage, ich hatte ja einen Filesystem > Defekt, meine Theorie war ja der mehrfach abstürzende AFP Server. Das ergibt keinen Sinn. "AFP Server" ist ein Server-Prozeß auf der Büchse, ja? Wenn der abstürzt, kann es natürlich sein, daß er Daten nicht oder nur halb auf die Platte geschrieben hat. Das Filesystem geht davon aber nicht kaputt. > Wenn ich das richtig verstanden habe, kann das aber auch bei einem > journaling Filesystem (EXT4) nicht die Ursache sein, richtig? Journaling ist ein Schutz gegen einen Absturz des Betriebssystems oder einen Stromausfall. Abtürzende Server-Prozesse können höchstens die Files beschädigen, die sie beim Absturz zum Schreiben geöffnet hatten. > Was kann denn die Ursache sein? > > Ein Plattendefekt? 2 Drives haben einen Read-Error: > ID# ATTRIBUTE_NAME VALUE WORST THRESH TYPE UPDATED WHEN_FAILED > RAW_VALUE > 1 Raw_Read_Error_Rate 200 200 051 Pre-fail Always - Ich sehe hier keinen SMART Fehler. Der Parameter beschreibt die Lesefehlerrate vor der Fehlerkorrektur. Und die Metrik ist so, daß der Wert bei Alterung sinkt. Du kriegst hier 200, was der Maximalwert (vulgo: bestmögliche Wert) sein dürfte. Ein Wert kleinergleich 51 wäre als Warnung vor einem kurz bevorstehenden Plattentod zu werten. > Auf welche SMART Parameter würdet ihr achten um ein drive auszutauschen? 5 Reallocated_Sector_Ct 7 Seek_Error_Rate 9 Power_On_Hours (vs. MTBF) 197 Current_Pending_Sector Das einzige harte Kriterium ist #197. Das ist die Anzahl nichtlesbarer Sektoren (nach Fehlerkorrektur). #5 ist theoretisch hilfreich, allerdings habe ich noch keine Platte gehabt, die da einen Wert != 0 gezeigt hätte. Auch definitiv kaputte Platten. #9 habe ich bei keiner Platte ausschöpfen können. Meine älteste Platte hat jetzt 77035h runter = 3210 Tage = 8 Jahre, 9 Monate, 3 Wochen.
Axel S. schrieb: >> Auf welche SMART Parameter würdet ihr achten um ein drive auszutauschen? > > 5 Reallocated_Sector_Ct > 7 Seek_Error_Rate > 9 Power_On_Hours (vs. MTBF) > 197 Current_Pending_Sector > > Das einzige harte Kriterium ist #197. Das ist die Anzahl nichtlesbarer > Sektoren (nach Fehlerkorrektur). #5 ist theoretisch hilfreich, > allerdings habe ich noch keine Platte gehabt, die da einen Wert != 0 > gezeigt hätte. Ich hab schon so einige Platten mit einigen wenigen Reallocated Sectors gesehen die dann kurz drauf Ärger machten. Wenn Reallocated Sectors > 0 fliegen die Platten bei mir sofort raus. Bei Current Pending > 0 natürlich auch.
Matthias L. schrieb: > Ich hab' hier ein NAS mit OpenMediaVault und RAID 6 zu laufen, weil ich > befürchtet habe, dass ausgerechnet beim Rebuild nach einem > Einzelplattenausfall eine zweite Platte den Geist aufgibt. Das ist berechtigt, denn bei meinem Webserver mit RAID1 ist genau dieses Szenario eingetreten, dass die zweite Disk sich beim Rebuildprozess auch noch verabschiedet hatte. Daher wäre es wohl zu empfehlen, bei RAIDs nicht völlig identische Disks einzusetzen.
Johnny B. schrieb: > Daher wäre es wohl zu empfehlen, bei RAIDs nicht völlig identische Disks > einzusetzen. Was bei HDDs freilich nur in sehr kleinem Umfang möglich ist. Versuch mal 5 neue und technisch verschiedene HDDs gleicher Bauform und Geschwindigkeitsklasse zu kaufen. ;-) > dass die zweite Disk sich beim Rebuildprozess auch > noch verabschiedet hatte. Mir ist das in zig Jahren Serverbetrieb trotz gleicher Disks erst einmal passiert, und das war in den ersten Tagen nach Lieferung. Die Ersatzbeschaffung erwies sich als schwierig, weil Serienfehler beim Hersteller, weshalb recht viele Kunden das gleiche Problem hatten.
:
Bearbeitet durch User
A. K. schrieb: > Johnny B. schrieb: >> Daher wäre es wohl zu empfehlen, bei RAIDs nicht völlig identische Disks >> einzusetzen. > > Was bei HDDs freilich nur in sehr kleinem Umfang möglich ist. Versuch > mal 5 neue und technisch verschiedene HDDs gleicher Bauform und > Geschwindigkeitsklasse zu kaufen. ;-) Ganz so verschieden hat er wohl nicht gemeint. Aber ein paar Wochen oder besser Monate Altersdifferenz können ganz hilfreich sein. >> dass die zweite Disk sich beim Rebuildprozess auch >> noch verabschiedet hatte. > > Mir ist das in zig Jahren Serverbetrieb trotz gleicher Disks erst einmal > passiert, und das war in den ersten Tagen nach Lieferung. Das war Glück. > Ersatzbeschaffung erwies sich als schwierig, weil Serienfehler beim > Hersteller, weshalb recht viele Kunden das gleiche Problem hatten. Ich erinnere mich dunkel an Berichte über einen Firmwarefehler, der Platten nach einer gewissen Betriebsdauer aussteigen ließ. Wenn nun alle Platten im RAID gleich alt sind ... Mein letztes RAID war ein RAID-5 über 7 Platten (+ 1 spare) WD Green 2TB. Wegen des schwächlichen Rechners dauerte ein Rebuild um die 8 Stunden. Da habe ich auch immer gezittert, ob die restlichen Platten durchhalten. Jetzt bin ich seit gut einem Jahr auf RAID-6. Rebuild war bislang nicht nötig. Alles in allem habe ich ein besseres Gefühl. Apropos: braucht jemand einen Highpoint RocketRAID 2320 controller? 8x SATA-II, PCIe x4. Eigene CPU (Hardware RAID möglich - von mir nur als JBOD genutzt).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.