wie ernst nehmen wir READ-errors im Zpool?

pit234a

Well-Known Member
Ausgangslage ist mein alter, interner Fileserver, zahlreiche HW-Updates hinter sich, aber immer noch mit einem FreeBSD-7.x am Laufen, weil ich zu faul bin, das neu zu machen, was ich damit habe. Zuletzt gab es eines neues MB, davor einige andere Änderungen und schließlich vor etwa 26500 Betriebsstunden neue Festplatten.

Die neuen Festplatten waren WD-RED, aber nun nicht die teuersten.
Trotzdem.
26500 Betriebsstunden ist schon am unteren Ende (nach meiner bisherigen Erfahrung), aber so ist das nun mal, Festplatten sterben wie Leute manchmal unerwartet.
Das hätte mich nicht an-gefressen.

Aber die erste wackelige Platte hatte nur READ-errors, was mir merkwürdig war.
Als sie aber doch mehr als hundert (100) am Tag produzierte, tauschte ich sie aus.

Sofort danach fing eine zweite an zu spacken:
Code:
  pool: raid1
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
    attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
    using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-9P
 scrub: resilver completed after 30h38m with 0 errors on Thu Feb 24 00:09:41 2022
config:

    NAME        STATE     READ WRITE CKSUM
    raid1       ONLINE       0     0     0
      raidz2    ONLINE       0     0     0
        ad8     ONLINE       0     0     0  1,39G resilvered
        ad10    ONLINE       0     0     0  1,36G resilvered
        ad12    ONLINE      71     0     0  1,40G resilvered
        ad14    ONLINE       0     0     0  1,37G resilvered
        ad16    ONLINE       0     0     0  1,39G resilvered
        ad18    ONLINE       0     0     0  2,22T resilvered

errors: No known data errors

___________________________________________

 7:19pm  up 20 days,  1:51, 1 user, load averages: 0,01 0,04 0,01
___________________________________________
OK, das sind nun etwa 70 errors in 20 Tagen gewesen, aber soeben habe ich diese Platte auch ersetzt, weil doch jeden Tag immer wieder einige errors dazu kamen.

Und natürlich habe ich nicht nur das MB, auch das Netzteil und die Kabel und alles probiert, weshalb es auch so lange dauerte, mich zu einem Wechsel der Platten durch zu ringen.

Ich will das nun nicht nachrechnen, aber in den ersten 25000 Betriebsstunden gab es keinen einzigen Error.
Nun eben diese recht harmlosen und relativ seltenen Read-Errors bei zwei Platten hintereinander.

Weil ich selbst da nicht so viel Erfahrung habe und ja nur ein privater Endanwender bin, könnten mich eure Antworten vielleicht erleuchten.
Bin ich zu empfindlich?

Also nochmal: es wurde alles getan, um diese Fehler wirklich eindeutig den (beiden) Platten und nicht der restlichen HW zuschreiben zu können.
 
26500 Betriebsstunden ist schon am unteren Ende (nach meiner bisherigen Erfahrung), aber so ist das nun mal, Festplatten sterben wie Leute manchmal unerwartet.
Jein. Ich hab noch mehrere Platten fehlerfrei mit über 75k Stunden im Einsatz, gestorben sind welche mit nichtmal 4000h und auch erst Richtung 90000h waren welche dabei. Gestorben heißt für mich ZFS vermeldet Fehler und da tausche ich sofort, rigoros. Oder wenn mir eine Platte fischig/zu langsam vorkommt, dann schaue ich mal mit smartctl nach und wenn da kaputte Sektoren sind, ist die Platte auch für mich am Ende und ich tausche.

Es mag Todestendenzen innerhalb Baureihen/Chargen geben, aber daraus Laufzeit zu schätzen bringt nichts.
Dass direkt nach einem resilver (oder währenddessen) die nächste Platte stirbt, ist nicht ungewöhnlich. Deswegen nimmt man kein heutzutage bei großen Platten kein raid5/raidz1 mehr. Rebuild/resilver dauern dann zu lange für das gefährliche Zeitfenster.
Wann hast du zuletzt einen scrub auf diesem pool gefahren? Ich vermute nämlich, dass die beiden Platten schon länger unentdeckt vor sich hin 'bitrotten' und das erst durch den resilver sichtbar wurde, der automatisch auch ein scrub ist. Hintergrund: Datei A,B und C liegen seit Ewigkeiten unberührt auf dem Pool, sind aber von defekten Platten via bitrot beeinträchtigt, du hast sie in 5 Jahren nicht angefasst und nur Dateien X,Y und Z gelesen, bearbeitet. Daher meldet dein Pool keine Fehler. Erst wenn man die Dateien aufruft oder durch einen kompletten scrub wird das Problem sichtbar.

Magst du mal ein smartctl -x /dev/ad12 in code-tags posten? Da sollte man nämlich auch rauslesen können, ob die Platte nen Schlag weg hat.

Bin ich zu empfindlich?
Nein, je mehr Daten und Platten man hat, umso sorgfältiger muss man agieren. :)
Sehr passend und aktuell dazu:
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
Ich will das nun nicht nachrechnen, aber in den ersten 25000 Betriebsstunden gab es keinen einzigen Error.
Ich hatte mal 3 WD RED (3TB, EFRX, A80 Firmware), welche innerhalb von 2 Wochen ausfielen, alle so um die 27.000 - 29.000 Betriebs-h
Der Ausfall selber war auch ganz spaßig, alle 3 funktionieren noch, zeigen aber nur noch 700 GB Größe an - könnte man also glatt als 0.7T Platten weiterverwenden; ZFS meldete damals Pool sei degraded (Fehler traten gottseidank immer einzeln auf - aber für sowas hätte man ja ein Backup seiner Daten, gell)

Lies mal mit smartmontools (smartctl -a /dev/adaX) die Daten der Platte(n) aus - und schau auf die Werte "197, Current_Pending_Sector" und "198, Offline_Uncorrectable"

Wenn die nicht auf 0 stehen, dann würd ich die Platte austauschen.
 
Zunächst mal Dank an euch
Es ist vielleicht ein wenig schockierend für mich gewesen, dass die viel gelobten WD-RED scheinbar doch nicht anders sterben, als andere Platten, die ich vorher so benutzt hatte. Und dann, vielleicht auch das Zögern, meinen Vorrat an Ersatzplatten gleich innerhalb weniger Tage auf zu brauchen. Zusammen mit den sechs Platten des Pools, hatte ich nämlich nur zwei Ersatzplatten bestellt und hoffte, damit laaange über die Runden zu kommen, denn ewig will ich diesen Fileserver ja eh nicht mehr betreiben.
Die beiden Platten haben meine Zielvorstellung nur zur Hälfte erreicht und das hat mich nun vor die Frage gestellt, neuen Ersatz zu ordern oder gleich alles neu machen?
Eigentlich war mein Entschluss bereits gefasst, dass auch die zweite Platte raus muss und das habe ich noch während dieses Threads getan. Wenn hier jemand gesagt hätte: "vergiss read-Errors", hätte ich mich vielleicht anders orientiert.
Aber, war ja klar...

Das ist die letztere Platte, bei der ich noch nicht so ganz bereit zum Tausch war:
Code:
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
Und das ist die erste, bei der selbst ich keine Bedenken hatte, zu tauschen:
Code:
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       4
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0

Nun.
Ist ja eigentlich alles klar. Eigentlich sind die beiden Platten Schrott. Ich habe auch eigentlich keine sinnvolle Verwertung für sie.
Aber uneigentlich hoffe ich darauf, doch noch irgendeine Verwendung dafür zu finden.
Was denkt ihr?
Sofort entsorgen?
Ich meine, so schlecht sind die nun doch noch nicht?
Vielleicht an einem Adapter als externe Platten, wo sie nur alle paar Monate mal benutzt werden?
 
So Fehler können auch durch Probleme mit der Stromversorgung kommen, etwa Spannungsspitzen, die beim Netzteil durchschlagen. Oder es könnte ein wackeliger SATA Stecker sein etc..

So SMART Zeug kann ich immer nicht so gut interpretieren. Aber ich habe auch schon WD Red NAS gewechselt. Ist halt so. Wenn möglich will man die Platten auch nicht alle aus einem Batch haben, damit ein Produktionsfehler nicht das ganze RAID zerstört weil alle Platten gleichzeitig kaputt gehen.
 
Aber uneigentlich hoffe ich darauf, doch noch irgendeine Verwendung dafür zu finden.
Was denkt ihr?
Sofort entsorgen?
Deswegen fragte ich nach smartctl -x für Details, evtl. gibts Hinweise auf weitere Defekte.
Angenommen, die Anzahl pending sectors bleibt so gering (würde ich nach Schreibvorgängen checken), dann könnte man sie als externe Platte für Datentransport oder meinetwegen 'kostenloses' Drittbackup nutzen. Keineswegs aber mehr darauf verlassen, denn oft genug steigt die Zahl der pending sectors nach dem ersten Auftreten rasant und daraus werden dann Offline_Uncorrectable. Dann ist das Ding so gut wie tot. Ja, Platten haben genügend Reservesektoren, aber will man sich im Ernstfall darauf verlassen und vor allem wie lange? Ich rate aber wirklich davon ab, denn wenn ZFS Lesefehler meldet, dann bedeutet es, dass die Platte Daten von sich gab, die so niemals draufgeschrieben wurden und würde die Kette von Reparaturfunktionen der Platte funktionieren, dann würde ZFS es nicht bemerken.

Ich meine, so schlecht sind die nun doch noch nicht?
Wenn deine Daten futsch sind, spielt es keine Rolle mehr, wie gut eine Platte war oder noch ist. Du siehst aber hier sehr gut, warum ein raidz2 oder sogar raidz3 Mehrwert hat. Vor allem ein Kaltbackup! :)
Einfach Nachschub kaufen und resilvern, ob du den Server mal irgendwann neu installierst oder nicht, ist davon akut ja nicht abhängig. Du musst dann irgendwann wenn du einen neuen Server frisch einrichtest ja auch nicht zwingend nagelneue Platten kaufen. Einfach recyclen und resilvern nach Bedarf und weiter gehts...so handhabe ich das zumindest.
 
Current_Pending_Sector zeigt an, wieviele Sektoren die Platte bereits nicht mehr lesen kann, welche aber noch nicht neu zugeordnet (ersetzt) wurden - jede Platte hat ja ne gewisse Anzahl an Reservesektoren für solche Fälle zur Verfügung.
Da die Daten in diesem Falle ja bereits nicht mehr gelesen werden können, ist somit also schon Datenverlust eingetreten - sofern in diesen Sektoren bereits Daten lagen.

Ich starte in so nem Fall immer ein Rettungslinux (FreeBSD u.ä. hab ich dazu nie probiert, ginge ggf mit deren FS und Tools auch) und lösche die darauf befindlichen Partition(en), lege eine Partition über die ganze Platte neu an, und formatiere diese Partition mit ext4.

Danach starte ich ein e2fsck -cc /dev/sdX und lasse mittels der -cc das e2fsck ein badblocks auf der Platte starten (die 2x -cc sorgen für ein read-write-badblocks, mit einem -c wärs ein read-only).
Das nudelt dann ein badblocks über die ganze Platte und - sofern "bad blocks" gefunden werden, sollten die neu auf Reserveblöcke zugeordnet werden. Funktioniert nicht immer.
Wenns funktioniert, könntest du die Platte erstmal weiter verwenden, man hat für wichtige Daten ja eh immer ein Backup, gell :D

Du könntest die Platte auch weiter benutzen, wenns nicht funktioniert hat, allerdings wird dieser Block halt immer weiter Probleme machen - wenn die Platte ohne Probleme drauf schreiben kann, aber nicht wieder von diesem Block lesen...
Ein ZFS Pool wäre hier dann gleich wieder "degraded", da ZFS so ein Verhalten einer Platte eigentlich sofort auffallen sollte.
 
So Fehler können auch durch Probleme mit der Stromversorgung kommen, etwa Spannungsspitzen, die beim Netzteil durchschlagen. Oder es könnte ein wackeliger SATA Stecker sein etc..

So SMART Zeug kann ich immer nicht so gut interpretieren. Aber ich habe auch schon WD Red NAS gewechselt. Ist halt so. Wenn möglich will man die Platten auch nicht alle aus einem Batch haben, damit ein Produktionsfehler nicht das ganze RAID zerstört weil alle Platten gleichzeitig kaputt gehen.
Das kann ich nur unterschreiben.
Wenn das NT mit der Zeit degeneriert und mehrere Volt Ripple-Wechselspannung auf ~50-150kHz den Spannungen überlagert, irgendwann kann das nicht mehr von der Platten-Analogelektronik kompensiert werden.

Und "Serienausfälle" sind auch der Grund, warum ich gerne meine ZFS-Pools gemischt "anordne", z.B. 1x Toshiba, 1x WD, 1x Seagate. Es ist einfach zu unschön, wenn während Backup / Resilvern die nächste Platte verreckt. Ganz besonders, wenn es sich um Consumerplatten handelt, die versuchen, Fehler zu "korrigieren", rumrödeln und nach einer Ewigkeit nen kaputten Sektor melden... da kann ein Backup/Resilver laaaange dauern. Deshalb auch immer Enterprise-Grade Platten nehmen.
 
Mal eine blöde Frage: Lässt du die Platten regelmäßig in Standby gehen?
nein, im Grunde genommen nie.
Nur zu Wartungszwecken wird der PC alle Jahre wieder abgeschaltet, oder wenn es halt eine Störung gibt und HW getauscht werden muss, oder wenn die USV nicht lange genug gehalten hat, um einen Stromausfall zu überstehen.
Nach Stromausfällen kommt es gelegentlich auch zu Hängern in meinem Netz, weil nicht alles über USV läuft und manchmal irgendwas nicht so richtig neu gestartet wurde. Dann kann es schon mal sein, dass ich auch meinen PC und den Server neu starte.
Das war in letzter Zeit dann außergewöhnlich häufig der Fall, weil ich es einfach nicht so wirklich glauben wollte, dass auch eine zweite Platte sich schon verabschiedet. Beim letzten Mal als das geschehen war, starb das MotherBoard und ich hatte noch ein gleiches, das schnell getauscht war. Diesmal bekam ich ein neueres geschenkt, was etwas mehr Umbau-Arbeit erforderte und dabei wechselte ich auch gleich das Netzteil.
Obwohl die SATA-Kabel eine gute Sorte war, wechselte ich auch die, steckte die Spannungsversorgungen neu, wechselte auch die Anschlüsse zu unterschiedlichen Platten und so weiter, kurzum, mehrere Monate Bastel und Beobachtung mit relativ häufigen Shutdowns, aber in Folge der bereits vorhandenen Störung.

Oben erwähnte ich, dass die ca 70 Read-Errors in ca 20 Tagen aufgelaufen waren.
Zuvor hatte ich ja die erste Platte ersetzt und nach dem resilver einen zpool clear gemacht, um besser zu sehen. Auch ein Neustart war erfolgt, weil ich den Server wieder zurück an seinen Platz gebaut hatte. Und zwar, nachdem ich über ca 14 Tage keinen einzigen Fehler hatte.
Nochmal: nachdem die erste Platte Mucken machte und ich die ersetzt hatte, zeigte auch eine zweite Platte Fehler.
Nachdem ich MB und NT etc getaucht hatte, zeigte sich zunächst kein Fehler und dann erst im Verlauf der nächsten drei Wochen wieder diese 70 read-errors.

Nun werkelt der Pool mit der zweiten neuen Platte gerade mal einen Tag nach dem resilver.
Das werde ich natürlich noch weiter im Auge behalten, wenigstens nochmal drei Wochen, bevor ich den Server wieder zurück in seinen Verschlag schiebe.
Die Temperaturen sind übrigens "im Verschlag" nicht höher, er steht mir da nur nicht so in den Füßen und ist etwas weniger zu hören.

Dank euch nochmal für die Ratschläge und eure Erfahrungen.
Natürlich sind keine wichtigen Daten auf dem File-Server, zu denen es nicht wenigstens ein weiteres Backup gibt.
Es liegen aber dort ziemlich viele unwichtige Daten, wie etwa meine Sammlung an Filmen. Die sind wirklich unwichtig, denn es gibt ja täglich neue Filme und wann hat man mal Zeit und Lust, einen alten anzusehen? Das ist mehr so, wenn mal das Internet für Tage ausfällt, der E-Reader spinnt und ein neuer Lock-Down ungeahnten Ausmaßes einen ins Haus fesselt, ja dann könnte ich in Ruhe mal meine alten Western sehen.
Und genau dafür würde ich nun die beiden defekten 4T Platten nutzen wollen, um eben davon vielleicht auch mal Backups zu machen, in den Schrank zu legen, zu vergessen und wahrscheinlich nie mehr zu benutzen.
Externen Platten traue ich eh nur bedingt als Backup-Medium. Ich denke, in diesem Sinne die defekten Platten wohl weiter zu verwenden, ist aber noch nicht ausgemacht.
 
ist es oft sogar sinnvoller Kopfparken komplett abzustellen.
oh, da muss ich dann mal nachfragen, denn ich dachte genau umgekehrt: wenn ich nichts extra einstelle, wird nicht geparkt und es gibt auch kein Standby.
Also, ich habe (soweit ich mich erinnere) keine entsprechenden Einstellungen vorgenommen.

Was sollte ich vielleicht besser tun?
Ich will keinen Standby und die Platten einfach immer durchlaufen lassen.
 
wenn ich nichts extra einstelle, wird nicht geparkt und es gibt auch kein Standby
Das kommt immer auf die Firmware der Platte an bzw. was der Hersteller default gesetzt hat und was der sich so denkt, muss nicht immer sinnvoll sein. Bei Platten aus der NAS-League, die die Reds sind, kann man da richtigerweise davon ausgehen, dass Kopfparken/kompletter spindown deaktiviert ist oder sehr dezent eingesetzt wird. Wenn man die Besonderheiten wie Heliumfüllung, Hybridplatten (Mechanik+dicker SSD-Cache) und das anfängliche SMR-Gemogel (https://www.heise.de/news/WD-Red-HD...-7-Millionen-US-Dollar-Ausgleich-6109943.html) nicht beachtet, dann ist diese Einstufung (WD Pinkrainbow, Red, Gold, Black, Raidbla, Surveillancebla) nur Kundenverwirrung.
Die "Unterschiede" sind da runtergebrochen auf die defaults der Einstellung von AAM (advanced acoustic management, findet man in freier Wildbahn nicht mehr) und APM (advanced power management).

Das als Hintergrund, nun ans Eingemachte:
Mit camcontrol identify ada0 kannst du nachschauen, was die jeweilige Platte eingestellt hat.
Code:
advanced power management      no    no
automatic acoustic management  no    no
wäre der Idealfall gemäß deinem Wunsch, damit ist alles abgeschaltet. (Die erste Spalte zeigt, ob die Platte die Funktion unterstützt, die zweite ob es aktiviert ist).
Andernfalls gibt es die Werte von 1 - 254 (max. performance).
Wechseln kannst du mit camcontrol apm ada0 -l 254.
254 ist imho ein für jede Platte sicherer Wert, aber es gibt noch Besonderheiten. 255 triggert bei manchen Platten die komplette Deaktivierung, was wie oben genannter Idealfall wäre, wenn man keine Sparmodi haben mag. Einfach ausprobieren und wenn 255 nicht geht, einfach 254 nehmen. Die manpage sagt, dass die Schwelle zu standby bei 127/128 liegt, das bedeutet aber nicht automatisch, dass es bei jedem Modell oder Hersteller einheitlich ist und ob der Hersteller unter standby spindown oder nur Kopfparken versteht. Da war ich mir mal mit @Zirias uneins, bzw. hatten wir keine definitive Antwort. ;)
Im Zweifel das Handbuch zu diesem Plattenmodell konsultieren, da ist das im Detail vermerkt.
Aus eigener Experimentierfreude -> Große Vorsicht bei Werten unter 20, da kommen dann auch Schlummermodi, die nicht mit jedem Board klarkommen und dann hängt die Platte im Tiefschlaf, das System knallt weg und muss resettet werden.
Weitere Besonderheit: Manche Firmware speichert das Setting nicht (vllt. für einen Warmstart) und kommt bei einem Neustart mit den defaults daher. Das muss man unbedingt mit einem Kaltstart (also mit Netzkabel ziehen, damit alle elkos sich leeren) überprüfen.
Sollte das so sein, kann man sich mit dem Knüppel (/etc/rc.local) behelfen:
/sbin/camcontrol apm ada0 -l 254

Was du jetzt nach den Infos haben willst...musst du entscheiden. Weil das Mechanik ist, geht die irgendwann nach x-Zyklen kaputt. Meine Enterprise-Platten hier haben als grobe Richtlinie die Angabe von 50.000x Motorstart und 600.000x Kopfparken, geh bei Consumerplatten mal von der Hälfte oder weniger aus, auch das sollte im Handbuch stehen.
Am wenigsten Probleme macht -l 254, das nutzt am wenigsten von der Mechanik ab, hält das Öl im Lager und die Gesamttemperatur relativ konstant, braucht aber im Dauerlauf am meisten Strom. Hier sind wir aber stark in der Esoterik und das heißt nicht automatisch, dass eine so betriebene Platte dann länger lebt. Auch heißt es nicht automatisch, dass ein defekter Sektor von beanspruchter Mechanik kommen muss.
Ganz grob: Wenn auf den Platten ein System läuft, Webserver, DBs oder VMs nimm 254, wenn du nur Dateien drauflegst, kannst du über 127 oder weniger nachdenken und die Stromersparnis zu Lasten eventueller Plattenhaltbarkeit mitnehmen.
 
Zuletzt bearbeitet:
Youtube's algo hat mir vorhin folgende Videos ausgespielt. Ich poste sie mal, weil es im Detail die Unterschiede beleuchtet. Am Ende des Tages hilft aber alles nichts, wenn die Platte 'plötzlich und unerwartet'. ;)

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
Noch mal zum Mitschreiben: RAID ist kein Backup.

Darüberhinaus ist FreeBSD 7.4 seit März 2013 nicht mehr unterstützt d.h. kein Bug Fixes, keine Security Updates usw. Deine Faulheit wird dich deutlich mehr kosten als du jemals damit gespart hast.
 
Noch mal zum Mitschreiben: RAID ist kein Backup.

Darüberhinaus ist FreeBSD 7.4 seit März 2013 nicht mehr unterstützt d.h. kein Bug Fixes, keine Security Updates usw. Deine Faulheit wird dich deutlich mehr kosten als du jemals damit gespart hast.
dem will ich gar nicht widersprechen, es war eben meine Entscheidung, es so zu belassen.
Nur mal zum Vergleich: mein Satelliten-Receiver läuft mit einem Linux 2.6.9 aus 2006 und faktisch könnte ich den entsorgen, weil ich keine aktuellen Updates dafür mehr kriege.
Das soll nicht ablenken. Ich will auch nicht weiter theoretisieren, was noch alles für Endgeräte in meinem Netz herumlaufen, die ein veraltetes System benutzen und auch nicht danach fragen, wie das in Haushalten aussieht, die immer nur fertige Endgeräte kaufen können und sich niemals Gedanken um Updates machen.
Was ich anführen möchte, sind zahlreiche PCs in meinem professionellen Umfeld, die noch immer mit Win NT laufen. Das OS spielt hier keine Rolle, es ist Träger einer abgeschotteten Funktionalität und die Anwender kümmert nicht der IT-Hintergrund, sondern die generelle Verfügbarkeit.
Damals habe ich das für meinen File-Server auch so entschieden. Wirklich von Anfang an ganz bewusst entschieden, dass ich genau das einbauen will, was mir nötig ist und wenn ich denke, dass alles so läuft, dann ab in die Ecke, vergessen und nicht mehr anrühren.
IT ist kein Hobby von mir und auch nicht mein Beruf. Ich bin froh, wenn ich einen PC mit OpenSource-System für meine Zwecke benutzen kann. Dauerhafte Verantwortung für Systeme übernehmen, wie das ein professioneller Admin machen muss (und dafür ja auch bezahlt wird), will ich nicht und mochte ich damals schon nicht.

Auch glaube ich nicht, dass ich diese Haltung noch mal bereuen werde.
Es gibt inzwischen kaum noch Anwender, die den File-Server benutzen. Außer dem oben erwähnten Sat-Receiver greife ich selbst hauptsächlich darauf zu und lege meine täglichen zweit-Backups dort hin. In wenigen Jahren wird das Ding vollkommen überflüssig werden und den Weg zum Wertstoff-Hof antreten. Sollte er vorher unerwartet sterben, dann eben schon früher.
Bis dahin macht er eben genau, was er soll und steht einfach nur in seinem Verschlag und rennt vor sich hin.
 
Nur mal zum Vergleich: mein Satelliten-Receiver läuft mit einem Linux 2.6.9 aus 2006 und faktisch könnte ich den entsorgen, weil ich keine aktuellen Updates dafür mehr kriege.
Naja. Kommt ja auch immer ein bisschen drauf an. Im LAN ist man ja generell weniger gefährdet (das gilt für den Fileserver natürlich auch) zudem sind solche Embedded-Linux-Geschichten meist auch recht reduziert und da läuft eh nur drauf was nötig ist (auf der anderen Seite ist bei denen die Entwicklung meist eher "schlampig").
Von der Security-Sicht kann man da also durchaus differenziert drauf gucken.

Was ich eher anmerken würde, das neuere FreeBSD-Versionen ja auch mehr Features haben und insbesondere bei für Fileservern relevanten ZFS hat sich ja durchaus seitdem ne Menge getan.

Was ich anführen möchte, sind zahlreiche PCs in meinem professionellen Umfeld, die noch immer mit Win NT laufen.
Durchaus. Das ist aber alles andere als professionell (auch wenn es in Einzelfällen durchaus Berechtigung dafür geben kann).
Ich weiß nicht was das bringen soll, wenn man auf solche obskuren Beispiele verweist.

IT ist kein Hobby von mir und auch nicht mein Beruf. Ich bin froh, wenn ich einen PC mit OpenSource-System für meine Zwecke benutzen kann. Dauerhafte Verantwortung für Systeme übernehmen, wie das ein professioneller Admin machen muss (und dafür ja auch bezahlt wird), will ich nicht und mochte ich damals schon nicht.
Gerade FreeBSD ist doch sehr freundlich was Upgrades angeht.
Letztlich muss jeder selbst wissen was er tut und ich kann Deine Gründe auch ein stückweit nachvollziehen. Dennoch ist der Hauptgrund "kein Bock". Und den kann man auch einfach so stehen lassen und sich die Kritik dazu anhören. Irgendwelche komischen Begründungen heranzuziehen, macht es nur schlimmer. :-)
 
Gerade FreeBSD ist doch sehr freundlich was Upgrades angeht.
ich glaube, dass gerade schon in der nächsten Version damals ein neues SAMBA kam und nicht mehr dieses geile Web-Interface zur Administration im Angebot hatte. Also nur mal so als ein Beispiel, weswegen man schon mal nachdenken kann.
Nicht, dass ich dieses Thema hier weiter führen möchte. Damals hatte ich mich so entschieden und dann ist ja der Zug irgendwann auch abgefahren. Es hat sich sehr viel seither geändert, aber wenn man jede Änderung den Gästen im Haus immer wieder erklären muss...
und gar nicht zu reden von der Zeit, die man selbst braucht, um diese Lösungen immer wieder neu zu erarbeiten.
Für mich war das ein ziemlicher Aufwand, weil ich sehr viel dazu lesen musste und mir nicht alles einfach aus der Hand geflossen ist. Dann freut man sich einfach, wenn man alles fertig hat und will nichts mehr damit zu tun haben.

Dieser File-Server hatte einen Thecus abgelöst, der auch ziemlich die gleichen Dinge auf einem embedded busybox/Linux gemacht hatte, nur wesentlich schlechter zu administrieren war. Der hatte auch nur in der Ecke gestanden und keine Updates bekommen. Vielleicht haben mich solche obskuren Beispiele einfach inspiriert, es ebenso zu wagen.
 
ich glaube, dass gerade schon in der nächsten Version damals ein neues SAMBA kam und nicht mehr dieses geile Web-Interface zur Administration im Angebot hatte.
Wobei ich das nie so pralle fand. Die Administration mit webmin fand ich da angenehmer.


und gar nicht zu reden von der Zeit, die man selbst braucht, um diese Lösungen immer wieder neu zu erarbeiten.
Dafür gibts doch hier dieses tolle Forum, wo man sich Tipps und Tricks abholen kann. :-)

Wie gesagt. Ich verstehe, wie sowas passiert und finde es in einem rein privaten Umfeld im LAN auch nicht wirklich dramatisch (allerdings auch nicht völlig unkritisch; gab ja schon mal ausgenutzte Lücken in alten Samba-Versionen und wenn es mal einen Windows-PC erwischt dann erwischts den Fileserver gleich mit).
 
Alles nachvollziehbar, will auch gar nicht widersprechen. Vor allem nicht bei der Faulheit, die kenne ich selber.
Gerade wegen der Faulheit ist mir daran gelegen, dass man möglichst sicher fährt und man Daten wenig Gelegenheit gibt sich zu zerbröseln. Da ich faul bin, will ich nicht nochmal die Dateien zusammenfriemeln oder erneut Lösungen erarbeiten. Nach dem Fileserver ist vor dem (neuen) Fileserver, quasi. :)

Für Faulklicki mit GUI gibt es https://xigmanas.com (mein fav) und https://www.truenas.com/
Das als Tip für deinen neuen Server irgendwann mal, erfrischend einfach.
 
Das ist die letztere Platte, bei der ich noch nicht so ganz bereit zum Tausch war:
Code:
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
Und das ist die erste, bei der selbst ich keine Bedenken hatte, zu tauschen:
Code:
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       4
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0

Ich meine, so schlecht sind die nun doch noch nicht?
Vielleicht an einem Adapter als externe Platten, wo sie nur alle paar Monate mal benutzt werden?
Ich hatte seit dem jetzt gerade eine externe USB-Platte (WD MyBook, es ist eine -EARS verbaut) welche Probleme machte (einige Daten nicht mehr lesbar, äußerte sich als I/O-Error in Linux)

Hab dann mein oben beschriebenes Verfahren angewandt, das zeigte mir jetzt 65514 "Current_Pending_Sector" an - auch nach neu formatieren und beschreiben immer noch - die Platte ist aber nutzbar, alle neu aufgespielten Daten sind rücklesbar. Man konnte zwischendrin auch hören, wie die Platte "rödelte" d.h ich gehe davon aus, dass Daten auf Reserve-Sektoren umgeschichtet wurden.
 
nach
Code:
7:20pm  up 11 days, 21:34
bisher mit der neuen Platte (naja, einige andere Dinge sind allerdings ja vorher auch schon getauscht worden) noch keine Fehler. Fehlen aber noch einige Tage, bis zur drei Wochen.Grenze, nach der die alte Platte wieder Fehler zeigte.

Die ausgebauten Platten hatte ich in einem Knoppix neu eingerichtet, aber weiter noch nicht benutzt.
Bei beiden Platten dauerte ext2 sehr lange und produzierte Fehler, so dass ich mal ext4 genommen habe und (bisher) ohne jedes Tuning. Das wurde flott und ohne Probleme aufgespielt.
Wüsste ich nichts von der Vergangenheit, würde ich hier keine Bedenken haben, diese Platten zu benutzen.

Was mich dann generell natürlich zu der Frage bringt, wie sehr man neuen Platten überhaupt vertrauen darf.
Damit meine ich nicht, dass jede Platte wie jedes Bauteil und manche Menschen einfach jung sterben kann.

Den Vergleich mit Menschen bringe ich an der Stelle sehr oft und nun stört er mich selbst. Er scheint mir nicht angebracht zu sein. Zwar erklärt er sehr gut, dass eine statistische Lebenserwartung gar nichts über eine individuelle Lebenserwartung aussagt und das ist ja genau, womit man immer wieder mal unangenehm überrascht wird. Aber ich denke, trotz dieser Analogie werde ich diesen Vergleich nicht mehr benutzen, weil er zu leichtfertig mit dem Tod von Menschen hantiert.

Hier lasse ich es noch stehen, weil in diesem Forum vergleichsweise viele denkende Menschen agieren, die mich verstehen werden.

one step back.
Was ich fragen möchte ist: ob ihr neue Platten auch genauer untersucht, bevor ihr die einsetzt?
Macht ihr Schreib- Lese-Tests und/oder Performance-Tests und/oder smartctl-Untersuchungen mit jeder Platte, bevor ihr die benutzt? Selbst, wenn sie frisch ausgepackt wird?
Sinnvoll scheint mir das ja schon.
Hier will ich als Privatanwender von den Profis für die Zukunft lernen, denn ich selbst habe bisher nie irgendwas mit neuen Platten getestet und sie einfach nur eingebaut und benutzt.
Wie seht ihr das?
 
one step back.
Was ich fragen möchte ist: ob ihr neue Platten auch genauer untersucht, bevor ihr die einsetzt?
Macht ihr Schreib- Lese-Tests und/oder Performance-Tests und/oder smartctl-Untersuchungen mit jeder Platte, bevor ihr die benutzt? Selbst, wenn sie frisch ausgepackt wird?
Sinnvoll scheint mir das ja schon.
Hier will ich als Privatanwender von den Profis für die Zukunft lernen, denn ich selbst habe bisher nie irgendwas mit neuen Platten getestet und sie einfach nur eingebaut und benutzt.
Wie seht ihr das?


In der Arbeit mach ich das nicht, da wir da sowieso nur teure enterprise Platten verwenden und auch immer min. Raid6 / Z2 verwendet wird.

Privat wo ich auch gerne zu günstigen Modellen greife, lese ich natürlich SMART aus und mach einen Schreibtest von /dev/urandom. Bei gefühlt an die 100 Platten gabs einmal eine, die neu schon Müll war - und mir vom Händler aber auch anstandslos getauscht wurde.
 
Was ich fragen möchte ist: ob ihr neue Platten auch genauer untersucht, bevor ihr die einsetzt?
Ich kaufe bevorzugt gebrauchte/refurbished Enterprise-Platten (SAS), da man für kleines Geld guten Kram bekommt, wenn der Shop oder Händler nicht gerade zwielichtig daherkommt. Zum einen kann man davon ausgehen, dass die Platten artgerecht behandelt wurden und gut gekühlt in einem Rack vor sich hinsurrten und zum anderen die Sache mit der Badewannenkurve. Entspräche dem plötzlichens Kindstod, wenn man darüber ist, erstmal alles gut. Alles kein Garant, nur eben meine Vorgehensweise. Ich flashe dann immer die letzte Firmware auf die Platten, lasse eine low-level-Formatierung laufen und gucke mir die SMART-Daten an. Das alles auf einer Testmaschine, sicher ist sicher. Wenn da nix fischig ist (war es noch nie), dann wird die Platte eingesetzt.
Um deine Frage vom anderen Gesichtspunkt zu beantworten: wenn die fabrikneue Platte murksig ist, meckert ZFS dir das sowieso bereits beim resilvern wieder an. ;)

SAS-Platten bedeuten ebenfalls nicht automatisch mehr Laufzeit als SATA-Platten, frühe Tode gibts immer bei Mechanik. Ich nehme SAS aus anderen Gründen.

Eine hier schon erwähnte gute Praxis ist auch der Einsatz von Mischbetrieb in vdevs. Also z.B. in einem raidz2 mit 6 Platten, je zwei WD, Toshiba oder HGST oder auch von nur einem Hersteller dann zwei oder drei unterschiedliche Modelltypen. Da sollte man sich dann aber etwas reinlesen, denn du willst ja möglichst gleiche Kapazität, Geschwindigkeit, Umdrehungen und Cache.
 
Zurück
Oben