• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Auf neuer SSD nach FreeBSD12 Installation Fehler im Dateisystem

serie300

Well-Known Member
Themenstarter #1
Hallo

nach der Installation von FreeBSD12 auf einer neuen zweiten SSD im Notebook (Transcend M2 SSD mit SATA Schnittstelle, Formfaktor 2242) hatte ich Fehler im Dateisystem. fsck hat dann ein paar Dateien in /usr/bin/ als defekt markiert und beim Druck auf Beheben die Dateien wegrepariert. Neben /usr/bin waren auch Firmware Dateien für GraKas betroffen. Ansonsten ist das System gelaufen. CrystalDiskInfo zeigt im SMART der SSD keine Fehler (bin die Einträge durchgegangen). Ich bin jetzt unsicher wie ich weiter machen soll. Sollten sich derartige Fehler an nicht wiederherstellbaren Datendateien wiederholen wäre das ja ungünstig. /usr/bin/* könnt ich ja vom Installationsmedium drüberkopieren. dmesg zeigt beim Systemstart außer Fehlern beim hdacc (Holadriö Karte) und fehldendem '/usr/bin/tr' keine Fehler. Bei 'ls -l' in /usr/bin hatte die Konsole geom Fehler geworfen
Kann es sich hier um ein unglückliches Zusammenspiel von Treiber, Chipsatz und SSD beim Schreiben der Dateien handeln?

Serie300
 

pit234a

Well-Known Member
#2
FreeBSDs Dateisysteme sind stabil und sicher.
Wenn es Fehler gibt, liegen die an der HW.
Neben der SSD kann das auch Kontakt und Spannungsversorgung sein, was in Frage kommt.
Ich würde hier nichts "drüber" kopieren, sondern lieber neu installieren. Womöglich mal auf ein anderes Medium, etwa einen USB-Stick. Und dann die SSD mal gründlich prüfen, also belasten und zusehen.
 

serie300

Well-Known Member
Themenstarter #3
Ich habe jetzt mal im Internet rumgestochert und unter
https://forums.freebsd.org/threads/quirks-0x1-4k-for-logical-512-physical-512-why.55210/
gefunden, daß quirks für diverse SSDs existieren. Meine Transcend ist nicht drunter. Kann es sein, daß ich einen quirk reinbauen muß? Die SSD meldet sich als
diskinfo -v ada0
ada0
512 # sectorsize
120034123776 # mediasize in bytes (112G)
234441648 # mediasize in sectors
0 # stripesize
0 # stripeoffset
232581 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
TS120GMTS420S # Disk descr.
E729150087 # Disk ident.
Yes # TRIM/UNMAP support
0 # Rotation rate in RPM
Not_Zoned # Zone Mode

Ich nehme mal an, daß sie als SSD 4k sectorsize hat
 

pit234a

Well-Known Member
#4

serie300

Well-Known Member
Themenstarter #5
Hallo pit

soweit ich es verstehe geht es nicht um zfs, sondern darum, dass der kernel von einer falschen Sektorgröße ausgeht, da die SSD diese falsch meldet. Darum auch die quirks in der cam layer, die auf bestimmte Plattentypen prüfen.

serie300
 

pit234a

Well-Known Member
#6
Code:
pit@Celsius ~:- > diskinfo -v ada0
ada0
    512             # sectorsize
    250059350016    # mediasize in bytes (233G)
    488397168       # mediasize in sectors
    4096            # stripesize
    0               # stripeoffset
    484521          # Cylinders according to firmware.
    16              # Heads according to firmware.
    63              # Sectors according to firmware.
    CT250MX500SSD1    # Disk descr.
    1803E10AECBB    # Disk ident.
    Yes             # TRIM/UNMAP support
    0               # Rotation rate in RPM
    Not_Zoned       # Zone Mode

pit@Celsius ~:- > diskinfo -v ada3
ada3
    512             # sectorsize
    512110190592    # mediasize in bytes (477G)
    1000215216      # mediasize in sectors
    0               # stripesize
    0               # stripeoffset
    992277          # Cylinders according to firmware.
    16              # Heads according to firmware.
    63              # Sectors according to firmware.
    Micron 1100 MTFDDAK512TBN    # Disk descr.
    18121CB546DF    # Disk ident.
    Yes             # TRIM/UNMAP support
    0               # Rotation rate in RPM
    Not_Zoned       # Zone Mode
Aber:
Code:
pit@Celsius ~:- > zdb PitsPool | grep ashift
                ashift: 12
                ashift: 12
^C
pit@Celsius ~:- > zdb pits-aussenlager | grep ashift
                ashift: 12
                ashift: 12
^C
Für mich bedeutet dies, dass FreeBSD gut mit diesen Informationen umgehen kann, auch ohne quirks.
Ein schlechtes Allignement und unsaubere Blockgrößen sind sicher ein Punkt, der ein System verlangsamen kann. Darauf musste man deshalb früher besonderes Augenmerk haben. Soweit ich es bei meinen Installationen seit 11.x beobachten konnte, war da alles automatisch von FreeBSD richtig gemacht worden. Deshalb mache ich mir darum inzwischen gar keine Sorgen mehr.
Ein wenig anders sieht es aus, wenn ich Partitionen und Dateisysteme von Hand anlege. Dann betrachte ich vorher die Geometrie und überlege, was ich wie und wohin setzen will. Auch dabei konnte ich aber feststellen, dass moderne Tools wie gparted (eine GUI in GNU/Linux) automatisch richtige Werte verwenden. Auch bei gpart (FreeBSD) fand ich das so, habe aber durchaus die Möglichkeit, nochmal nachzubessern, wenn ich das will. Beispiele, wie man da einfach was ausrichten kann, finden sich im Netz.

In deinem Fall hast du installiert und sofort danach ein defektes Dateisystem gehabt, wenn ich das richtig verstehe.
Dabei ist es ziemlich egal, ob du UFS oder ZFS genommen hast und ob du das richtig ausgerichtet hattest: nach meiner Erfahrung dürfte nichts ein Dateisystem zerstören oder verändern, das bei einem einfachen Neustart passiert.
Meine Überlegung ist, dass dann, wenn das Installationsmedium in Ordnung war (überprüft, Quersumme und Größe), wenn es keine Probleme dabei gab, dass das Medium mal unzugänglich war (Stick abgezogen, Netzwerk gestört), dass dann nur ein HW-Fehler in Frage kommt.
Ich mag mich irren, installiere auch nicht täglich FreeBSD auf unterschiedlichster HW. Das ist mein Erfahrungsstand.

Wenn es eine Unverträglichkeit der HW zu FreeBSD ist, dann ist das für mich eher gleichbedeutend zu defekter HW und ich würde nur sehr sehr ungern an Dingen schrauben, die ich nicht verstehe.
 

serie300

Well-Known Member
Themenstarter #8
Das transcend und ein weiteres Tool meldet die SSD als 100% i.O. Habe auch aus Win10 die Platte vollschreiben und verifizieren lassen. Nach Neuinstallation gibt es jetzt andere dubiose Fehler. ich denke ein quirk bzgl. Trim ist für FreeBSD erforderlich.
 

mr44er

Well-Known Member
#10
Mich machen die 112GB stutzig. Riecht arg nach gesperrtem Bereich.
Was sagt ein 'smartctl -a'?

Hast du die SSD unbenutzt neu vom Händler gekauft oder sind das Rückläufer?
Hat dein Laptop im BIOS sowas wie eine quick recovery Funktion als F-Hotkey/physikalische Taste oder ähnliches klingendes marketing mumbojumbo?

Btw. ist es wurscht, welche sectorsize die SSD vorgibt vorlügt. :) 4k forciert mit ZFS regelt, also ashift: 12.