Fehler im Dateisystem (zfs): wie evtl. beheben?

waldbaer59

Well-Known Member
Hallo zusammen,

die in einem anderen Thread erwähnten 'spontanen Reboots' scheinen nicht völlig ohne Folgen geblieben zu sein. Zwar habe ich einen zfs-Pool, der ja gegen unmittelbare Ausfälle hinreichend stabil sein soll, aber vielleicht hat die SSD nicht ganz mithalten können (wg. Pufferung?).
Wie dem auch sei: bei einem 'find' Kommando ist mir aufgefallen, dass es wohl mittlerweile Probleme gibt:

Code:
find: /root/.local/share/Trash/files/devel/p5-Test-File-ShareDir: Unknown error: 122
find: /root/.local/share/Trash/files/devel/p5-Test-Fake-HTTPD: Unknown error: 122
find: /root/.local/share/Trash/files/devel/p5-Test-Fatal: Unknown error: 122
find: /root/.local/share/Trash/files/devel/p5-Test-File: Unknown error: 122
find: /root/.local/share/Trash/files/devel/p5-Test-FailWarnings: Unknown error: 122
find: /root/.local/share/Trash/files/devel/p5-Test-File-Contents: Unknown error: 122

Diese Dateien waren zunächst in den Verzeichnissen der Ports zu finden. Ich habe dort alles gelöscht und mir die kompletten Port-Daten neu gezogen. Ein normales 'rm' hat aber nicht funktioniert, weswegen ich alles in den Mülleimer von 'root' befördert habe (wo sich der Fehler natürlich weiterhin meldet). Später habe ich dann versucht mit 'zpool scrub ...' den Fehler wegzubekommen, doch er besteht weiterhin. Da frage ich mich jetzt, ob (überhaupt und wenn wie) ich den Schlamassel behoben bekomme.
Da ich gelegentlich noch mal neu installiere (und deshalb dieses System noch eine Weile zum 'vertesten' bestehen lasse) ist es jetzt keine Katastrophe. Aber ich will natürlich wissen was da so los ist.

[Übrigens ist es auch nach dem Abstöpseln des Wlan Sticks zu spontanen Reboots gekommen (zwei Mal). Das lässt sich auch nicht auf die Laufzeit oder die CPU-Belastung zurückführen. Ich habe da so eine wilde Idee, aber das muss ich noch testen. Die nächste Installation wird aber ohnehin auf einem ThinkPad (400er) passieren.]

VLG
Stephan
 
Zwar habe ich einen zfs-Pool, der ja gegen unmittelbare Ausfälle hinreichend stabil sein soll, aber vielleicht hat die SSD nicht ganz mithalten können (wg. Pufferung?).
Jau, viele Billig-SSDs (das muss nicht negativ sein) haben keinen Stützkondensator und im Falle eines plötzlich Stromausfalls oder teilweise sogar Reboots verlieren sie die zuletzt geschriebenen Daten. Das findet ZFS gar nicht lustig. Kannst du uns mal die Ausgabe von zpool status zeigen, damit wir sehen können, was kaputt ist?
 
Ihr Wunsch sei mir Befehl ;) :

Code:
pool: root
state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 0 days 00:01:53 with 47 errors on Wed Mar  4 08:22:09 2020
config:

    NAME        STATE     READ WRITE CKSUM
    root        ONLINE       0     0     1
      ada1p2    ONLINE       0     0     5

errors: Permanent errors have been detected in the following files:

        <metadata>:<0x4b>
        <metadata>:<0x52>
        <metadata>:<0x53>
        <metadata>:<0x5a>
        <metadata>:<0x64>
        <metadata>:<0x66>
        <metadata>:<0x78>
        <metadata>:<0x80>
        <metadata>:<0xbd>
        root:<0x0>
        //usr/src/tests/sys/cddl/zfs/tests/iscsi
        //usr/src/tests/sys/cddl/zfs/tests/zones
        //usr/src/tests/sys/cddl/zfs/tests/scrub_mirror
        //usr/ports/irc/evangeline
        //var/cache/pkg/minitube-2.9_5-4aa8f51247.txz
        //usr/src/tests/sys/cddl/zfs/tests/threadsappend
        //usr/home/XXXXXX/.cache/falkon/default/Cache/f_00008e
        //usr/ports/irc/ezbounce
        //usr/src/tests/sys/cddl/zfs/tests/mv_files
        //usr/src/tests/sys/cddl/zfs/tests/mmap
        //usr/local/share/icons/Adwaita/512x512/emblems
        //usr/local/share/icons/Adwaita/512x512/mimetypes
        //usr/ports/audio/py-speechrecognition
        //usr/src/stand/mips/beri
        //var/cache/pkg/json-glib-1.4.4-509b4d8acb.txz
        //usr/share/pc-sysinstall/backend
        //usr/local/lib/python3.7/lib-dynload/_codecs_kr.so
        //usr/share/pc-sysinstall/doc
        //usr/ports/irc/tircproxy
        //usr/ports/math/octave-forge-level-set
        //usr/home/XXXXXX/.config/GIMP/2.10/themerc
        //usr/home/XXXXXX/.tvbrowser/tvdata/tvbrowserdataservice.TvBrowserDataService/icons_main/index.txt
        //usr/home/XXXXXX/.cache/fontconfig
        //usr/ports/math/openmesh
        //usr/home/XXXXXX/.tvbrowser/tvdata/tvbrowserdataservice.TvBrowserDataService/icons_norge
        //usr/local/share/locale/be/LC_MESSAGES/gtkspell.mo
        //usr/ports/math/octave-forge-netcdf
        root:<0xd04a4>
        //var/cache/pkg/fpc-rtl-objpas-3.0.4_4-544d9e26eb.txz
        //usr/local/include/webrtc_audio_processing/webrtc
        //usr/ports/finance/kmymoney
        //usr/ports/irc/dancer
        //usr/ports/finance/ktoblzcheck
        //usr/src/stand/powerpc/ofw

Sieht nicht gut aus ...

*hmpf*
 
Lass mal ein `zpool scrub root` durchlaufen. Das weist ZFS an mit dem Selbsttest des Pool zu beginnen. Dabei werden alle Daten eingelesen falls Kopien beschädigt sind versucht ZFS sich automatisch aus der vorhanden Redundanz zu reparieren. Bei einem Pool aus bloß einer SSD ist natürlich nicht viel Redundanz vorhanden. Du kannst die allerdings im Anschluss sicher sein den ganzen Umfang des Schadens zu kennen. Das meiste deines Schadens lässt sich aus öffentlichen Quellen reparieren z.B. /usr/src, /usr/obj sowie /usr/ports löschen und neu auschecken.

Die Paar Dateien in $HOME musst du aus deinen hoffentlich vorhandenen Backups recovern. Falls nicht wäre spätestens jetzt Zeit automatisierte Backups einzurichten z.B. mit restic. Sollte es keine Backups geben ist das nicht weiter schlimm. So wichtig können die Daten in dem Fall ja nicht gewesen sein :belehren:.

Nachdem du dein System wieder zusammengeflickt hast stellt sich die Frage wie du von hier aus weiter machst. Deine SSD ist ja offensichtlich unzuverlässig. Akzeptierst du das Problem? Tauschst du sie aus?
 
Ich werde noch ein paar Dinge ausprobieren und dann ein FreeBSD nochmal aufsetzen. Die SSD werde ich zu diesem Zweck nicht mehr verwenden
Vor einigen Tagen hatte ich eine Sicherung der Partition über dd + Komprimierung gemacht und könnte daher sogar diesen Stand zurückholen. Aber das scheint nicht unbedingt erforderlich, da ich ja eh neu installieren wollte.

Danke für die Info; für mich ist damit klar dass auf dem neuen System eine Sicherung mit das Erste sein wird was aktiviert wird.

VLG
Stephan
 
eine Sicherung mit das Erste sein wird was aktiviert wird
Das und zumindest mal Gedanken um mindestens einen mirror-pool.

Mit dem Wissen jetzt könnte man auch den Wlan-Stick wieder ausprobieren, aber 1.) wird die (wahrscheinlich) kaputte SSD schuld am langsamen Surfen gewesen sein und 2.) ist der Stick am Thinkpad ja obsolet. ;)
 
-Nuke-: Doch es kann noch mal lesen was hilft, wenn es nur Übertragungsfehler waren (die werden von der Hardware/Firmware nicht immer korrekt als solche erkannt). Außerdem speichert ZFS by default zwei Kopien von normalen Metadaten und drei Kopien von Pool weiten Metadaten zusätzlich zu der Redundanz der VDEVs (in diesem Fall nicht vorhanden).
 
Noch einen kurzen Zwischenstand: ich habe die SSD auf den zweiten Thin Client transplantiert. Wie bereits von einem kenntnisreichen Forenkollegen vermutet kommt es auch hier zu demselben Effekt. Morgen wird die SSD durch einen anderen Datenträger ersetzt. Wenn es dann immer noch zu den Problemen kommen sollte wäre für mich die Eignung des HP Thin Client T610 für FreeBSD in Frage zu stellen... Ich hoffe mal dass Beste!
Bevor das nicht vernünftig läuft kann ich doch nicht mit meinen weiteren Fragen hier auflaufen... ;)

VLG
Stephan
 
Kann natürlich auch sein, dass die SSD nur verbuggte Firmware hat und sich so alles zerschossen hat. Alles eine Frage der Experimentierfreude und ob es einem die Zeit eines ~50€-Artikels wert ist. :p

smartctl -a /dev/ada0 | grep -e Model -e Firmware
 
Ich habe bitter lernen müssen, dass man mit billigen SSDs vorsichtig sein muss. Nicht nur bei ZFS, sondern ganz generell abseits von Windows. Bei weitem nicht alle billigen SSDs sind schlecht und es sind auch nicht im Umkehrschluss alle teuren SSDs gut. Aber ist es unbestreitbar gerade im untersten Preissegment ein großes Problem, dass die Hersteller mit extrem geringen Margen arbeiten und daher versuchen auch den allerletzten Cent rauszuoptimieren. So die gängigen 3 Probleme, die ersten beiden hatten wir schon, sind:
  • Verbuggte Firmware, die Daten schreddert. Zum Beispiel, wenn das Alignement nicht stimmt oder durch andere Blocksizes einfach anders als unter Windows mit NTFS ist. Oder bei TRIM etwas mehr löscht, als sie soll. Richtig eklig ist auch, wenn das Wearleveling versagt und falsche Daten zurückgegeben werden oder interne Datenstrukturen zerstört werden. Zum Glück ist wirklich übel verbuggte Firmware in den letzten Jahren selten geworden. Wohl einfach, weil die Hersteller der schlimmsten Gurkencontroller ihren Kram doch irgendwann nicht mehr an den Mann bringen konnten und weil mit genügend Zeit auch das inkompetenteste Entwicklerteam die schlimmsten Fehler rausgekratzt bekommt.
  • DRAM-Cache (gut) mit nicht funktionierendem oder gar nicht erst vorhandenen Stützkondensator (schlecht). Diese schöne Kombination führt dazu, dass bei plötzlichem Abschalten der Cache nicht vollständig in den Flash geschrieben wird. Die Liste der Konsequenzen ist lang. Kompletter Datenverlust, weil die internen Datenstrukturen zerstört wurden, kommt kaum mehr vor. Aber subtile Probleme, wie einzelne kaputte Blöcke, sieht man immer noch. NTFS steckt sowas gut weg, ZFS und noch viel schlimmer z.B. XFS reagieren darauf äußerst allergisch.
  • Billiger Flash, der am Anfang wunderbar funktioniert, aber schnell Fehlerraten jenseits von Gut und Böde erreicht. Je nach Qualität der Firmware wird die SSD einfach langsam oder es werden gekippte Bits bis ans Betriebssystem durchgegeben. Äußerst sich bei NTFS nur durch diffuse Fehler, bei ZFS durch massenweise nicht übereinstimmende Checksums.
Ein guter Tipp ist vor dem Kauf zu googlen, ob es bekannte Probleme im Zusammenspiel mit Linux gibt. Was unter Linux tut, funktioniert meistens auch unter FreeBSD und umgekehrt. Und wenn es noch eine konkrete Empfehlung sein soll: Die Crucial MX500 Serie ist meiner Erfahrung nach problemlos und durchaus günstig, viel günstiger kommt man auch bei anderen halbwegs namenhaften Herstellern nicht davon. Man sollte nur die aktuelle Firmware geflasht haben, wobei alle im letzten Jahr von mir gekauften Modelle sie schon drauf hatten.
 
Die Crucial MX500 Serie ist meiner Erfahrung nach problemlos und durchaus günstig,
Und läuft bei mir wirklich gut mit FreeBSD. Ich hatte meine erste als "sehr teure" SSD eines anderen Herstellers geschenkt bekommen und wunderte mich nicht schlecht, als smartctl mir eine Crucial anzeigte.
Hier die "sehr teuere" (auch nicht mit Micron als Hersteller beworben, sondern irgendwas wirklich Namhaftes):
Code:
Model Family     Crucial/Micron BX/MX1/2/3/500, M5/600, 1100 SSDs
Device Model     Micron_1100_MTFDDAK512TBN
Hier meine "billigen":
Code:
Model Family    Crucial/Micron BX/MX1/2/3/500, M5/600, 1100 SSDs
Device Model    CT250MX500SSD1
 
Eine Menge guter Informationen. Eigentlich wollte ich eine 320GB 2,5" Notebook Festplatte in die Kiste befördern. Vielleicht tue ich es mir aber vorher noch an, die Firmware der SSD upzudaten (was für ein Wort...) und schaue ob es dann geht. Ich bin ja noch in der Spielphase; die Gelegenheit ist günstig!

CU
Stephan
 
Noch eine Information zu den Spontan-Reboots. Ich habe in diesem Zusammenhang im Netz Beiträge gefunden, die davon berichten, dass es bei diesem Gerät durchaus solche Effekte geben kann. Und weil mein Test mit einer PCI-Express Grafikkarte statt der internen erneut Reboots geliefert hat habe ich den radeonkms in Verdacht. Daher überlege ich, es mal mit dem xf86-video-ati zu probieren. So ganz ohne Grafik-Beschleunigung wollte ich nicht arbeiten.

Falls gewünscht kann ich für Fragen dazu auch einen neuen Thread aufmachen.

Jedenfalls seht ihr, dass ich nicht aufgebe ;) .

VLG
Stephan
 
Kommt darauf an. Willst du jetzt ultrabillige SSDs mit hochwertigen NAS Platten vergleichen, oder hochwertige SSDs mit billigen Desktop-Platten oder beides aus der hochwertigen Reihe? Jedes hat so eine Probleme, je nachdem wo du es einsetzt.
 
Kein System bietet "Optimale Sicherheit" für Daten. Geräte können einen Wasserschaden erhalten, Überspannung, Verbrennen, geklaut werden, durch einen Fehler des Admins gelöscht werden e.t.c..

Deshalb ist am allerwichtigsten immer ein gutes und so aktuelles Backup zu haben wie nöitig, am besten Off-Site z.B. mit zwei wechselnden externen Festplatten oder so sofern es irgendwie um wichtige Daten geht.

Im SSD-Bereich habe ich nun schon öfters gehört und gelesen das es sich lohnen kann etwas mehr Geld ausgegeben, ich denke Yamagi hat da den Punkt getroffen.

Im klassischen Spindelbereich ist man sich "allgemein" sehr uneins ob die Unterschiede zwischen den günstigsten Einstiegsdesktopfestplatten & "einfachen" NAS platten und den teureren Enterprise & SAS-Geräten e.t.c. was die Zuverlässigkeit angeht wirklich große Unterschiede machen.
 
Wir sind in der Firma schon seit Jahren weitgehend auf SSDs gewechselt. Mechanische Platten haben wir nur noch im zentralen Backup-System und im großen Minio-Cluster. Dort dann aber auch gleich große 12 TB Modelle mit Heliumfüllung und SAS-Schnittstelle an entsprechenden Controllern.

Meiner Erfahrung daraus sind:
  • Selbst SSDs im mittleren Datacenter Preissegment wie Intel DC Serie oder Samsung SM Serie sind drastisch zuverlässiger, als es 10k RPM und vor allem 15k RPM SAS Festplatten jemals waren. Die schnelldrehenden Festplatten begannen durchgehend nach nur 3 Jahren wie die Fliegen zu sterben, die SSDs schnurren sauber durch, solange man innerhalb der garantierten Terabytes Written bleibt. Von bestimmt weit über 2500 Datacenter SSDs in den letzten Jahren ist exakt eine einzige SSD innerhalb ihrer Terabytes Written gestorben. Und da gab es von Intel noch einen anstandslosen Austausch.
  • Bessere SSDs sind gerade im letzten Drittel ihres Lebens zuverlässiger als Festplatten, da sie meistens anständig sterben. Sie sind einfach nicht ansprechbar oder schalten sich in read-only Mode zurück. Das ist ein klar definiertes Fehlerbild. Anders, als Festplatten, die sich oft anfangen diffus fehlerhaft zu verhalten und wo man dann über die SMART-Alchemie rätseln darf. Was zu präventivem Austausch verleitet.
Festplatten bleiben uns sicher noch lange Zeit als große Datengrabs erhalten, vor allem wenn es nun mit HAMR und MAMR tatsächlich noch einen größeren Kapazitätssprung für PMR-Festplatten geben sollte. Aber für alles andere sind sie einfach überholte Technik. Auch in Desktops. Die 2 TB Crucial MX500 in meiner aktuellen Desktop-Kiste hat sich zumindest sehr gelohnt. Alleine schon, weil sie lautlos ist.
 
Kann man also sagen, dass nach wie vor die gute alte mechanische Festplatte mit ZFS optimale Sicherheit für Daten liefert?

Wie genau meinst du das?

Festplatten können jederzeit sterben - billige wie teure, Consumer-Devices genauso wie welche für professionelle Server.
Abseits von Festplatten sind Daten allerlei weiteren Unwägbarkeiten ausgesetzt - von fehlerhafter Hardware (z.B. Controller, Kabel, Chipsätzen, fehlerhafter Firmware in den Controllern bzw Festplatten - man denke an die Probleme mit den ersten Sandforce SSD Controllern - Netzteilen etc) bis hin zu - kein Witz - kosmischen Vorfällen wie Sonneneruptionen/Teilchenwinden, welche Daten auf Platten verfälschen/unbrauchbar machen können.

Ob deine Daten optimal geschützt sind, hängt u.a. sehr davon ab, welchen Aufwand du betreibst um deine Daten sicher und konsistent zu halten.

Filesysteme wie z.B. ext und xfs sind an sich sehr gut und gut ausgereift, allerdings sind sie z.B. nicht gegen "bit-rot" geschützt, d.h. deine Daten können auf den Festplatten "verrotten" (einzelne Bits flippen von 0 auf 1 oder 1 auf 0 - und keiner merkts erstmal), andere Filesysteme wie zfs oder btrfs sind dagegen z.B. mit einem ausgefeilten Checksumming eher gefeit - aber das heißt nicht, dass du mit diesen Filesystemen nicht auch Daten verlieren kannst.

Sichere Datenhaltung über lange Zeiträume ist ein Konzept, und kein einzelnes Filesystem oder ne Super-Festplatte alleine für sich gesehen.
 
Festplatten können jederzeit sterben - billige wie teure, Consumer-Devices genauso wie welche für professionelle Server.
Mein Beispiel sind immer die Männer. Die haben derzeit in Deutschland eine Lebenserwartung von etwa 72 Jahren (Wert aus dem Gedächtnis und schon einige Jahre alt, es soll hier nur ein Beispiel zum Vergleich der Begriffe angeführt werden).
Jeder kennt Männer, die schon sehr viel jünger gestorben sind und einige sogar als Babys (Gottlob ziemlich selten).

Das gilt auch nicht nur für Festplatten/SSD sondern generell für HW. Die wird auch immer zuverlässiger und langlebiger, aber trotzdem kann auch mal ein ganz frisches Mainboard sterben.

Die statistischen Werte sind eben nur gesammelte Daten über ausreichend viele Ereignisse (und oft genug hochgerechnet und wirklich getestet). Individuelle Erfahrungen können dramatisch abweichen und wer wichtige Daten hat, darf hier immer nur an worst-case denken und entsprechend handeln.

Noch einen kleinen (nostalgischen) Grund für SSD:
Irgendwann hatte ich mal meinen genialen Einfall berichtet, Festplatten sehr billig relativ gut mechanisch gedämpft in meinen Server zu verbauen, indem ich die an einem Fahrrad-Schlauch befestigte. (Eigenlob stinkt, aber wenn man schon selten solche Geistesblitze hat, wird die doch auch auskosten dürfen?).
Nachdem ich das vorgestellt hatte und die Grundidee beschrieb, dass Festplatten sich nämlich über Vibrationen durchaus beeinflussen und auch das zu Fehlern führen kann, wurde ich auf entsprechende Versuche hingewiesen, wo man die Festplatten in laufendem Betrieb angeschrien hatte und daraufhin dann vermehrt Fehler festgestellt wurden!

Also Festplatten bei mir auch nur im Datengrab und nur aus Kostengründen.
Ansonsten SSD.
 
wo man die Festplatten in laufendem Betrieb angeschrien hatte und daraufhin dann vermehrt Fehler festgestellt wurden!

Festplatten (die mit dem rotierenden Eisen) reagieren auf Erschütterungen, da gehören auch die Luftschwingungen durch anschreien dazu :D

Ein Kumpel von mir ist Schlagzeuger, dessen Rechner im Übungskeller konnte man durch bestimmte Einsätze der Base-Drum gezielt zum Absturz bringen...

Wir hatten mal ne Baustelle direkt vorm Gebäude von einem meiner früheren Arbeitgeber - die hatten da so ne große, moderne Walze mit Oszillation, um den Boden besser verdichten zu können... das spürte man im Serverraum an wackligen Knien - und an abstürzenden Servern...

In der Niederlassung in Italien hatten wir Erdbeben und Straßenbahnen - war beides mehr oder weniger gut im Serverraum (5. Stock, mitten in Mailand, Effekte siehe oben) zu spüren.


Grundsätzlich kann man von folgendem ausgehen: ALLE habens auf jemandes Daten abgesehen:

In einer Niederlassung in D wurde von Monteuren versehentlich ein Wasserrohr über nem Geräteraum angebohrt - das Rack sah aus, als obs unter der Dusche stehen würde...

Bei den oben beschriebenen "rumpel"-Vorfällen bin ich mir sicher, dass man mit SSDs entspannter dem entgegenblicken könnte, aber generell gilt - wichtige Daten redundant halten!

Hatte letztens am Homeserver (FreeNAS) drei(!) Plattendefekte nahezu gleichzeitig - von der Lieferung von 2 Ersatzplatten war eine DoA!

Der Teufel ist ein Eichhorn...
 
Filesysteme wie z.B. ext und xfs sind an sich sehr gut und gut ausgereift, allerdings sind sie z.B. nicht gegen "bit-rot" geschützt, d.h. deine Daten können auf den Festplatten "verrotten" (einzelne Bits flippen von 0 auf 1 oder 1 auf 0 - und keiner merkts erstmal), andere Filesysteme wie zfs oder btrfs sind dagegen z.B. mit einem ausgefeilten Checksumming eher gefeit - aber das heißt nicht, dass du mit diesen Filesystemen nicht auch Daten verlieren kannst.

Zumindest in meiner Filterblase geht der Trend sowieso weg von POSIX-kompatiblen Dateisystemen hin zu S3-kompatiblem verteiltem Objektspeicher als Zielumgebung der Wahl. MinIO dürfte so ziemlich der bekannteste Open-Source-Vertreter sein (inklusive FreeBSD-Port). Damit sieht man auch unzuverlässiger Hardware gelassen entgegen.

Hier gibt es ein schönes Beispiel-Setup: Distributed Object Storage with MinIO on FreeBSD
 
Zuletzt bearbeitet:
Interessant, minio hatte auch @Yamagi oben angesprochen - kannte ich bislang noch gar nicht.

bin mir sicher, auch bei den Cloudspeichern kippen Bits bzw sind Daten auch ungeplanten Löschversuchen ausgesetzt, nur haben die Dienstleister einige Tricks angestellt, um Sachen wie bit-rot und anderen Unwägbarkeiten vorzubeugen...

Kann mich an nen Fall beim grossen "G" vor Jahren erinnern, wo die wirklich Kunden-Firmen-Daten verloren hatten (Grund weiß ich nicht mehr) - also auch alle weiteren Generationen von Kopien weg waren - aber sie hatten die Daten noch in letzter Instanz auf... gutem, alten Tape! Ggf geht das mit den heutigen Datenmengen gar nicht mehr.

a propos @Yamagi - wenn ihr schon länger auf "nur-SSD" seid, wie sind eure Langzeit-Erfahrungen mit denen? Also, fallen die öfter aus als rotierender Rost, werden zum Ende der Lebensdauer hin langsamer etc..
Kannst was dazu sagen?
 
Zurück
Oben