Linux Systemplatte reparieren unter Raspi?

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!

    RTFM


    Wenn ich mich recht erinnere, hatten doch Festplatten mal mehr Sektoren, als man eigentlich nutzen konnte. Diese waren gedacht dafür, dass etwaige Ausfälle von Sektoren ausgeglichen werden können. Und ich meine, mal gelesen zu haben, dass das auch noch bei SSDs gilt. Kann es nicht sein, dass diese fehlenden 944 Sektoren genau dafür gedacht sind?

    Solche "zusätzlichen" Sektoren liegen im "Servicebereich" der HDD/SSD und tauchen nicht in der Größenangabe des Speichermediums auf. Man kann diese nur mit entprechenden Tools wie smartctl o.ä. sehen. In deinem Fall wurden halt nicht die max. mögliche Anzahl der Sektoren für die Partition genutzt.

    Ein ATA/SATA Device hat einen sichtbaren Bereich, der in Deinem Fall bei Sektor Nummer 234441648 endet, und darüberhinaus weitere 'Sektoren bis zum realen Geräteende, welcher Bereich "Host Protected Area" genannt wird. In diesen nicht sichtbaren Bereich können Verwaltungsdaten, Recovery Programme, Badblock Tables, Trim Sektoren, Passwörter o.Ä. vom Hersteller abgelegt werden.


    In manchen Linux Distributionen ist ein dazugehöriges Systemverwaltungsprogramm "hdparm" vorinstalliert, mit dem ein erfahrener Admin, der auch man-pages lesen und verstehen kann, Anzeigen und Änderungen vornimmt, beispielsweise den sichtbaren Bereich verschiebt/verkleinert.


    Servus !

    RTFM = Read The Factory Manual, oder so

    Ok, verstehe - war nur so eine Idee von mir. Melde mich mal wieder ab, bin ab morgen wieder für ein paar Tage im Spital und danach wohl wieder deutlich bedient. Also nicht wundern, wenn ich mich jetzt wieder für mehr als eine Woche nicht melde.

    Habe gerade den Thread als Erledigt markiert.


    Kurze Info: Es hat sich nach langen Diskussionen herausgestellt, dass die SSD defekt ist. So ist es zwar möglich, auf die SSD Daten zu schreiben (neue Textdatei anlegen und diese mit Daten befüllen beispielsweise - oder Dateien in andere Verzeichnisse verschieben) - und im Dateimanager sah man auch diese Änderungen. Wenn man das Laufwerk aber aus- und danach wieder einhängt, sind all diese Änderungen verloren. Der Hersteller der SSD hat mir das nach einem Mail-Austausch auch bestätigt.


    Ich finde das Verhalten von Linux irgendwie .... äh .... seltsam. Man schreibt Daten auf ein Laufwerk, man sieht diese veränderten oder neuen Daten - und bei nächstbester Gelegenheit stellt sich heraus: Genau nix ist passiert. Das gibt mir irgendwie zu denken ....

    :conf:

    Dieses Verhalten habe ich schon mehrere Male bei SD Karten festgestellt. Du änderst was, siehst die Änderung und nach einem Reboot ist wieder der alte Stand da.


    Das liegt daran dass solche Filesystemdinge im Speicher gecached werden. Das macht Windows wie Linux. Beim Runterfahren werden diese Dinge dann persistiert ... Nur leider geht das nicht weil die SD Karte oder -Platte defekt ist und icht mehr geschrieben werden kann. Somit hast Du nach einem Reboot wieder den alten Stand.


    Ist wirklich ein sehr unangenehmer Effekt und es dauert das rauszufinden.

    :no_sad: Kein Backup - kein Mitleid :no_sad:
     :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)

    Edited once, last by framp ().

    Like 1

    framp


    Danke für die erklärenden Worte. Und da stellen sich mir natürlich gleich wieder eine Menge Fragen, beispielsweise: Warum dauert es so lange, bis die neuen Daten persistiert werden? Oder: Würde Windows mehr Informationen liefern als Linux? Gibt es Möglichkeiten, dieses Persistieren softwareseitig anzustoßen? Was meldet die SSD zurück, wenn die Daten nicht persistiert werden können wegen diesem Defekt? Und warum reagiert Linux nicht darauf?


    Fragen über Fragen ... ;)


    Aber egal, es ist, wie es ist. Der Hersteller hat mir zwar angeboten, ihm die SSD zu schicken und im Zuge der Garantie würde ich dann eine neue bekommen - aber nachdem ja sensible Daten drauf sind, werde ich wohl darauf verzichten. Weil eine 120GB SSD kostet ja nicht die Welt, der Schaden ist also eher gering. Sowohl monetär, als auch sonst. War ja nur ein Test-System.


    Danke jedenfalls für Eure Bemühungen!

    :danke_ATDE:

    Quote from ralfi1988
    ...

    Ich finde das Verhalten von Linux irgendwie .... äh .... seltsam. Man schreibt Daten auf ein Laufwerk, man sieht diese veränderten oder neuen Daten - und bei nächstbester Gelegenheit stellt sich heraus: Genau nix ist passiert. Das gibt mir irgendwie zu denken ....

    :conf:

    Die Anzahl der Schreibzugriffe auf eine SSD / SD-Karte bzw. USB-Stick o. andere Flashspeicher sind begrenzt. Ein weitere Punkt ist Größe der Speicherblöcke. D.h. willst Du eine 1kB große Datei speichern und der Speicherblock auf der SSD ist z.B. 64 kB groß, müsste i.d.R. der gesamte 64 kB Speicherblock neu geschrieben werden, was mit der Zeit die Lebensdauer der SSD verkürzt. Daher werden die Daten "gesammelt" und erst dann geschrieben, wenn z.B. 64 kB Daten zum speichern da sind. Mit dem  sync  Befehl bzw. beim "sauberen" Aushängen eines Datenträgers bzw. beim Runterfahren des Systems, sollten die Daten ( egal mit welcher Speichergröße ) auf das Speichermedium geschrieben werden.

    Quote from Fliegenhals

    Mit dem sync Befehl bzw. beim "sauberen" Aushängen eines Datenträgers bzw. beim Runterfahren des Systems, sollten die Daten ( egal mit welcher Speichergröße ) auf das Speichermedium geschrieben werden.

    Das dumme ist nur dass der Flashspeicher keinen Fehler ans OS meldet wenn nicht mehr geschrieben werden kann :( .


    Der Cache bleibt beim sync erhalten und wird weiterhin genutzt. Damit denkt man man haette die Datei geaendert. Vermutlich wird der Cache bei einem umount geloescht und bei einem mount wieder neu vom Flashspeicher gelesen. Das habe ich aber nie genauer untersucht. Ich habe den Effekt immer nach einem Reboot festgestellt.

    :no_sad: Kein Backup - kein Mitleid :no_sad:
     :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)
    Quote from framp

    Das dumme ist nur dass der Flashspeicher keinen Fehler ans OS meldet wenn nicht mehr geschrieben werden kann

    BTRFS kann damit z.B. umgehen, da nach dem Schreiben überprüft wird, ob das Geschriebene wirklich dem entspricht, was geschrieben werden sollte.

    Falls man keine Datenbank betreibt, wäre BTRFS eine Option, um Bit Rot zu vermeiden.

    Fliegenhals


    Am Alter liegt es definitiv nicht - siehe das Protokoll von smartctl:

    Demzufolge hat die SSD gerade mal 151 Einschaltvorgänge und 116 Aktivstunden hinter sich gebracht. Nö, hier handelt es sich mit höchster Wahrscheinlichkeit um ein defektes Produkt. Dieses Protokoll habe ich auch an den Hersteller geschickt und wie schon geschrieben, geht man dort von einem Hardwarefehler aus.


    DeaD_EyE


    Ein "Überprüfen" würde vermutlich auch nichts nützen. Denn es war möglich, dass ich eine Datei über den Dateimanager neu anlege, diese mit Daten fülle, den Dateimanager schließe, den Dateimanager neu starte und dann diese Datei einlese. Die Daten waren vorhanden.

    Die einzigen Programme, die auf diesen Defekt hinwiesen (im Nachhinein interpretiert), waren die Tools, welche den vermeintlichen Fehler (Stichwort Superblock) beseitigen wollten, hatten zwar die Änderungen vorgenommen - aber am Schluss doch festgestellt, dass der Fehler nach wie vor vorhanden ist. Ähnlich wie GParted, mit dessen Hilfe ich alle Partitionen auf der SSD platt machen wollte; dort hat oberflächlich auch alles funktioniert (gab also keine Fehler beim Durchführen der Änderungen), aber am Ende waren die bisherigen Partitionen noch immer vorhanden. Auch dort muss offensichtlich versucht worden sein, den Cache zu schreiben ... was ja wegen dem Hardware-Defekt nicht geht.


    Naja - Pech gehabt. Übrigens, falls es interessiert: Es handelt sich um eine SSD von Intenso. Habe gestern noch ein wenig gestöbert im Netz und da gibt es doch einige Meldungen, die von der Qualität deren Produkte nicht so recht überzeugt sind. Daraus lerne ich: Nächstes Mal doch ein paar Euro mehr investieren ... ;)

    Quote from ralfi1988

    Ein "Überprüfen" würde vermutlich auch nichts nützen. Denn es war möglich, dass ich eine Datei über den Dateimanager neu anlege, diese mit Daten fülle, den Dateimanager schließe, den Dateimanager neu starte und dann diese Datei einlese. Die Daten waren vorhanden.

    Ja, sie waren wahrscheinlich noch im Cache. Das Dateisystem greift aber eine Ebene tiefer auf das Block-Gerät zu und greift nicht direkt auf den Cache zu, um z.B. einen neuen Block zu schreiben.


    BTRFS hat man genau wegen dieser Probleme (Bit Rot) entwickelt. Das ZFS konnte man aufgrund der Lizenz nicht im Linux-Kernel einsetzen. Die GPLv2 ist inkompatibel mit der CCDL. Aber leider ist BTRFS nicht für alle Anwendungen geeignet. Datenbanken hassen BTRFS.

    Quote from DeaD_EyE

    Aber leider ist BTRFS nicht für alle Anwendungen geeignet. Datenbanken hassen BTRFS.

    ... und BTRFS ist nicht OOTB mit RaspbianOS nutzbar. Ich hatte mal ein System testweise mit BTRFS aufgesetzt weil ich mal testen wollte ob man die BTRFS Snapshots mit raspiBackup nutzen kann. Irgendwie bin ich dann davon wieder abgekommen :denker:

    :no_sad: Kein Backup - kein Mitleid :no_sad:
     :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)

    Edited once, last by framp ().

    Quote from ralfi1988

    Gibt es Möglichkeiten, dieses Persistieren softwareseitig anzustoßen?

    Neben dem schon genannten, gibt es die Möglichkeit das Dateisystem mit der Option sync zum mounten. Dann werden Daten nicht im Cache vorgehalten, sondern direkt auf den Datenträger geschrieben. Das hat allerdings den Nachteil das es langsamer ist und besonders Flash Speicher schneller kaputt geschrieben werden. Ist also nicht unbedingt zu empfehlen.

    Quote

    Was meldet die SSD zurück, wenn die Daten nicht persistiert werden können wegen diesem Defekt? Und warum reagiert Linux nicht darauf?

    Naja, wenn die SSD defekt ist, wird sie möglicherweise keine Probleme oder nichts melden. Das Dateisystem/Linux weiss dann auch nichts und kann nicht reagieren.

    Quote from ralfi1988

    Fliegenhals


    Am Alter liegt es definitiv nicht - siehe das Protokoll von smartctl:

    Code
    Device is:        Not in smartctl database [for details use: -P showall]


    Naja - Pech gehabt. Übrigens, falls es interessiert: Es handelt sich um eine SSD von Intenso. Habe gestern noch ein wenig gestöbert im Netz und da gibt es doch einige Meldungen, die von der Qualität deren Produkte nicht so recht überzeugt sind. Daraus lerne ich: Nächstes Mal doch ein paar Euro mehr investieren ... ;)

    Mein Hinweis war nur zur Erläuterung, des deiner Meinung nach seltsamen Verhaltens unter Linux gedacht. Wenn das mit den 116 Betriebsstunden ( wg. der obigen Fehlermeldung ) so stimmt, wird die Laufzeit mit Sicherheit nicht das Problem gewesen sein. Ich hatte auch schon mehrmals Probleme mit Produkten von dieser Marke, und diese wären nicht mehr meine erste Wahl. Die Reklamation hat aber immer ohne Probleme geklappt. Schlechter ist, wenn solche Probleme kurz nach dem Garantieende auftreten. Des weiteren sollte man im Hinterkopf behalten, dass die statistische Ausfallwahrscheinlichkeit eines Gerätes am Anfang bzw. zum Ende der Laufzeit, relativ hoch ist. ( Badewannenkurve )

    Danke Euch ... dann ist das "seltsame" Verhalten wohl der SSD geschuldet und nicht dem OS. Mein "Erstaunen" kommt daher, dass ich doch schon Erfahrungen habe mit defekten Festplatten und noch keine mit defekten SSD's. Wieder was gelernt ... :)