SSD defekt?

    Hi


    Ich habe in einem meiner Server eine SSD verbaut. Nun bin ich gerade dabei ein script zu schreiben das einfach einen snapshot eines LV erstellt und anschließend per dd in ein File kopiert. Bei allen Volumes funktioniert das auch problemlos aber bei einem bricht das Kommando nach immer genau 4,0gb mit einem Ein/Ausgabefehler ab:

    Code
    root@hammond:/backup/snapshots/vg_system/ipfire-boot# dd if=/dev/vg_system/hammond-disk.snap of=/dev/null
dd: Lesen von „/dev/vg_system/hammond-disk.snap“: Eingabe-/Ausgabefehler
7744016+0 Datensätze ein
7744016+0 Datensätze aus
3964936192 Bytes (4,0 GB) kopiert, 36,5583 s, 108 MB/s


    ich habe es dann noch testhabler mit noerror probiert:


    Es dürften sich wohl einige defekte Blöcke eingeschlichen haben - ist das möglich? Bzw sollten SSDs nicht entsprechend Reserveblöcke mitführen?
    Irgendwelche Ideen was es sonst sein könnte?


    mfg
    Alex

    Nicht rumraten, "smartctl" nutzen. Für solche Fragen wurde S.M.A.R.T. erfunden.


    BTW: Es ist nicht zufällig FAT32 (oder was anderes älteres) im Spiel? Weil Abbrüche nach genau 4GB ist schon auffällig.
    Edit: OK, vergiss es, schreiben nach /dev/null sollte dann ja klappen ;) Aber für defekte Blöcke ist das zu auffällig, klingt eher danach ob eine beteiligte Software zu alt ist.


    cu

    Hi


    FAT32 oder vergleichbar ist definitiv nicht im spiel - die Kiste läuft auf Debian 6 mit Kernel 2.6.32-5-xen-amd64. Dass es da noch irgendwelche Software gibt die Probleme macht glaube ich nicht. Ausserdem habe ich auch ein anderes 20GB Volume auf der gleichen Disk in der gleichen VG Problemlos wegschreiben können.
    Was ich für möglich halte ist dass das Volume ursprünglich 4GB groß war und ich nachträglich vergrößert habe. Könnte es daran liegen?


    mfg
    Alex

    Hi


    also einen Softwarefehler schließe ich fast aus - ich habe jetzt mal versucht die ganze Disk zu lesen:


    scheint so als hätte die SSD einen Schaden - aber warum springt keiner der Reservesektoren ein?


    mfg
    Alex

    hier noch die Ausgabe von smartctl - bestätigt meine Vermutung aber lässt die Frage nach den Reservesektoren offen:


    Evtl. greift das nur beim schreiben? "short" liest ja nur, der "long" wäre wohl der richtige für nen Kompletttest.


    cu

    Wie gross ist dein snapshot Volume ? 4GB ?
    Ich bin mir nicht sicher, ob man von einem snapshot Volume ein DD machen kann, da es nur die orginalversion der geaenderten Bloecke des Orginal's enthaelt.
    Wenn man ueber das Fielsystem zugreift, ist das transparent, d.h. geaenderte Bloecke werden vom Snapshot gelesen, unveraenderte vom Orginal Volume. Regeln tut das der LVM
    Mit direkt Zugriff (dd) auf das Blockdevice umgehst Du mAn den LVM


    btw Warum dd und nicht einfach ein Copy der Files ?


    Edit
    # mount /dev/vg_system/hammond-disk.snap /mnt
    # tar czf /some/dir/mybackup.tar.gz /mnt/*

    Server PC leap42.3 ::: vdr-2.3.8 ::: DD Cine C2 + 1 Erweiterung headless

    zbox leap42.3 ::: vdr-2.3.8 + SatIP Plugin

    OctopusNet DVBC mit 4 Tunern

    Clients 2 x Raspberry 2 + libreElec 8.2.1 verbunden mit zbox

    Hi


    Den long Test habe ich schon angestossen aber der dauert halt noch etwas.


    den Snapshot habe ich jetzt mal 10GB groß gemacht um das auszuschließen. Dass dd Probleme mit Snapshots hat glaube ich auch nicht da der Fehler bei anderen Snapshots auch nicht Auftritt. Ausserdem habe ich bei meinem letzten Versuch direkt vom Device gelesen und es kam zum gleichen Fehler - ich habe mir zwar nicht ausgerechnet ob es die gleiche Stelle ist aber da es exakt gleich viele Fehler gibt und es gefühlsmäßig auch hinkommt gehe ich davon mal aus.


    dd verwende ich deshalb weil ich ich damit bootfähige Images meiner virtuellen Maschinen erhalte und verschlüsselte Volumes sichern kann ohne mich beim Backup mit der Verschlüsselung herumschlagen zu müssen.


    mfg
    Alex

    Zitat von Mac Gyver

    scheint so als hätte die SSD einen Schaden - aber warum springt keiner der Reservesektoren ein?


    tut er doch, zumindest einer


    Aber das ist an sich ein schlechtes Zeichen. Durch gutes „Wear-Levelling“ sind alle Sektoren gleichmäßig abgenutzt, wenn der erste ausgewechselt werden muss, könnte sich das Ende abzeichnen. Ich würde den smart Wert mal im Auge behalten.


    Gruß Fr@nk

    Hoi


    coole SSD :D

    Code
    9 Power_On_Hours          0x0000   ---   ---   ---    Old_age   Offline      -       232481892


    die lief schon 26540 JAHRE :D


    Was mir da aber mehr sorgen macht

    Code
    1 Raw_Read_Error_Rate     0x0000   ---   ---   ---    Old_age   Offline      -       262148


    Gibts ein Test-Tool vom Hersteller? Wenn ja -> mal laufen lassen.
    ich würde einfach mal versuchen die SSD per copy zu sichern, z.B. wie es asshep vorgeschlagen hat. Evtl. hast du Glück und der "Problembereich" is nicht in den Files.


    Keine_Ahnung


    ich hab noch keine Platte gesehen, die einen Long-Test durchgestanden hat, wenn schon der Short-Test versagt hat. Mit SSD hab ich aber zugegeben bisher keine Erfahrung, das €/GB Verhältnis ist mir einfach noch zu hoch.

    Dirk

    [Blockierte Grafik: http://www.ping-timeout.de/sig-468x90/21.jpg]

    Zitat von Dirk

    Mit SSD hab ich aber zugegeben bisher keine Erfahrung, das €/GB Verhältnis ist mir einfach noch zu hoch.


    Dirk, probiere die einmal aus. Du willst dann keine andere Systemplatte mehr haben wollen. Versprochen.


    Albert

    öhm ...


    Wolltest du dich nicht bessern und weniger Threads mit OT-Beiträgen "bereichern"? (NEIN, ich will darauf keine Antwort!!!)


    Hier gehts immer noch um eine evtl. defekte SSD und nicht um Läuterung von SSD-Abtrünnigen!

    Dirk

    [Blockierte Grafik: http://www.ping-timeout.de/sig-468x90/21.jpg]

    Zitat von Dirk

    Was mir da aber mehr sorgen macht

    Code
    1 Raw_Read_Error_Rate     0x0000   ---   ---   ---    Old_age   Offline      -       262148


    Kann ein Problem darstellen, muss aber nicht.
    Viele Hersteller haben dort astronomisch hohe Werte , ohne problematisch zu sein (bsw. Seagate). Dieser RAW Wert bedeutet nicht zwangsläufig, das es so viele Lese Fehler gegeben hat. Vielmehr gibt der Hersteller dort einen Wert aus, den nur er interpretieren kann.


    Gruß Fr@nk

    Zitat von Dirk

    ich hab noch keine Platte gesehen, die einen Long-Test durchgestanden hat, wenn schon der Short-Test versagt hat.


    Die Idee war das beim Long Test die Reservesektoren angetriggert werden weil hier auch geschrieben wird.
    Wobei ich hier generell wohl auch ein Verständnisproblem habe, denn ich gehe eigentlich davon aus das ne HDD die Reservesektoren so ganz automatisch ins Spiel bringt wenn Lese- oder Schreibfehler auftreten. Weil sonst macht so was ja keinen Sinn.



    BTW: Ansonsten halte ich es ganz simpel, bei Verdacht auf HDD Problemen den long Test (den short probiere ich gar nicht erst), zeigt dieser Fehler dann HDD tauschen.


    cu

    Zitat von Dirk

    Hier gehts immer noch um eine evtl. defekte SSD und nicht um Läuterung von SSD-Abtrünnigen!


    Dirk, Du hast Recht.


    Ich würde die Platte mit CrystalDiskInfo anschauen. W ist da Linux voraus. Wenn ich mich recht irre, OCZ bietet nicht unbedingt was gebrauchbares, zumindest nicht unter Linux. Wenn ja, lasse ich mich eines Besseren belehren.


    Was lola schreibt, das hat die c't in öfteren bestätigt. Schon die Werte der Hersteller bezüglich Lebensdauer gehen astronomisch auseinander.


    Albert

    "Tools" gibt es für SSDs nicht, zumindest mal keine, die etwas taugen.


    Das ist aber auch nicht weiter schlimm, da SSDs solche Tools so oder so nicht benötigen.


    smartctl bring da auch nichts, was ja obige Ausgabe bestätigt.


    Zitat
    Code
    Warning: device does not support Error Logging

    Moin moin,


    Zitat

    Was ich für möglich halte ist dass das Volume ursprünglich 4GB groß war und ich nachträglich vergrößert habe. Könnte es daran liegen?


    Hm, ich hatte einen ähnlichen Fall mal bei einer "normalen" Festplatte - also so einer mit drehenden Scheiben ;)
    Die hatte ich ne ganze Weile mit einer Partitionierung im Einsatz und nach der Umpartitionierung gab es immer wieder Fehler, meist im Bereich der alten Partitionierung.
    Ich habe dann mal Lowlevel formatiert und die Fehler waren Geschichte.


    Logisch kann ich es mir zwar nicht exakt herleiten, aber es sollen ja schon Pferde gekotzt haben :O


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    Zitat von geronimo

    aber es sollen ja schon Pferde gekotzt haben :O


    Gruß Gero


    ...stimmt, vor der apotheke sogar mit aspirin im maul... ;)


    mal was ganz anderes...wie VOLL ist die platte denn? also zu wieviel prozent ist die ungefähr belegt?
    die ssd's versuchen ja die daten gleichmäßig auf die einzelnen blöcke zu verteilen um die schreibzugriffe pro block zu minimieren. wenn natürlich nun schon alle blöcke teileise belegt sind und er versucht auf einem blobk zu schreiben welcher defekt ist?! kenne mich nicht ganz so mit der logik einer ssd aus, für mich wäre aber auch naheliegend dass einzelne blöcke defekt sind (zumal smart das auch bestätigt)...ich würd das versuchen was gero gesagt hat, versuch den inhalt der ssd auf ne andere platte zu klonen, einmal komplett low-level-format und dann wieder drauf...
    ich habe in meinem laptop die gleiche ssd, mir ist der vorgänger auch hops gegangen (allerdings war da auf mal die ssd nicht mehr vom bios erkannt worden). ocz ist zwar recht günstig und schnell aber nicht gerade einer der besten ssd-hersteller. aber da hat jeder seine vorlieben.

    Client 1 Hardware : MSI Z87-G43, I5-4570, 4 GB Ram (oversized aber war über :) ),Zotac NVidia GT630 (25 Watt),Thermaltake DH202 mit iMon-LCD ( 0038 ) und vdr-plugin-imon
    Software : yaVDR 0.6,sofhhddevice @ 1920x1080@50Hz
    Server Hardware : MSI Z87-G43, I7-4790, 16 GB RAM, 5x3 TB WD Red, Digibit-R1 (2 Devices)
    Software : Ubuntu 16.04 LTS mit yavdr-Paketen,virtualbox,diverse VM's


    Yoda: Dunkel die andere Seite ist...sehr dunkel!
    Obi-Wan: Mecker nicht, sondern iss endlich dein Toast ...

    Wurde die SSD einfach so partitioniert ohne dass die Tools wussten dass es sich um eine SSD handelt? Oder begannen die Partitionsgrenzen immer wie es sein soll an einer Blockgrenze?

    So nun ist auch der long test fertig:


    Ich werde die Disk wohl tauschen müssen - Wenn bei einem read vom Device direkt (dd if=/dev/sdh) fehler auftreten dann kann das wohl kaum mit der Formatierung oder dem LVM zusammen hängen. Das Wegkopieren des Volumes mit Rsync hat funktioniert - es dürften also keine Dateien beschädigt sein (zumindest keine die ich noch habe)


    Merkwürdig finde ich auch noch das bei dem Test eine Lifetime von 220h also etwas unter 10Tagen angegeben wird - die Platte ist seit gut einem halben Jahr in einem 24/7 Server im Einsatz......


    Sollte noch irgendjemandem einfallen warum die Reservesektoren sich ihrer Aufgabe entziehen währe ich sehr dankbar darüber.....


    mfg
    Alex

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden