System lahmt

[revealed]

Hallo.

Nachdem ich mich hier am laufenden gerade weiterbilde, nachdem ich dem Thema ja scheints nicht entweichen kann. Und ich offensichtlich irgendwas nicht gelesen habe. Wenn du von 100 Prozent möglichen defekten gerade mal einen Prozent beanspruchst, brauchst du SSD weder Löschen deswegen noch einschicken. Meine ich.

Gruß,

R

 

[Anonymous]

Das gilt leider auch für den Moderator gehrke.

gehrke hat völlig recht. Die smartctl-Ausgabe ist eine Momentaufnahme vom 1.8., wichtig ist, ob sich das Attribut 187 verändert hat. Von einem Foto ist nichts zu sehen und von brauchbaren Aussagen zu iotop nichts zu lesen. Wenn bei einer vergleichsweise jungen SSD bereits 8 Sektoren unbrauchbar sind (und als Ersatz Reserve-Sektoren verwendet werden mußten), ist das ebenso wie z. B. das Attribut 169 ein weiteres Anzeichen auf einen Hardware-Schaden.

Das verstehe ich nicht: Wozu brauchst Du ein Foto, wenn die SMART-Werte bereits als Antwort ins Forum gestellt wurden?
Logisch ist eine SMART-Abfrage immer nur ein Schnappschuss. Das ist doch sonnenklar, oder?
Ein Foto von iotop oder eine einfache (n=1) Konsolenausgabe ist relativ oberflächlich, wie revealed heute schon richtig angemerkt hat.
@revealed: Ich habe nicht geschrieben, dass die SSD kaputt ist. Das war jemand anderes.

P. S. Auszug aus der aktuellen smartctl-Datenbank: // SanDisk SDSSDXPS480G/X21200RL

Woher hast Du diese Datenbank genau und wie alt bzw. wie neu ist sie?

8 defekte Sektoren können in der SSD schon immer vorhanden gewesen sein, also ab Werk. Dafür gibt's schließlich mehr als genug Reservezellen.
Die Verwaltung darüber obliegt dem Controller, und für den gibt es schon die übernächste Firmware.
(…) Spätestens, wenn die SSD eingeschickt wird, bekommt sie auch die neue Firmware.

—

Eine Vermutung kann ich noch in den Raum stellen:
Vielleicht hat die SanDisk SDSSDXPS480G mit der Firmwareversion X21000RL ein Problem mit delayed trim.
Das würde auch erklären, warum der Fehler nicht unter Win8.1 auftritt. Dort gibt es sowas ja noch gar nicht.

 

[revealed]

Wäre eventuell sogar interessant, ob diesbezüglich mit "discard" gemounted wird und ob die SSD dies unterstützt?

Ich kann dazu nur sagen bei mir beispielsweise mit meinen SSDs ist discard ein riesen fehler mit dieser Kernel Version. Und bei meiner Samsung führt das zu Datenverlust, weil sie kein trim mit NCQ kann owbohl die aktuellste firmware dies behauptet. Fakt is meine kanns nicht, aber behauptet es.

Aber meine SSD ist noch nicht mal in der smart datenbank. Aber is auch n anderes thema was mein Zeug ist.

Gruß,

R

 

[Anonymous]

Ob discard als mount-Option benutzt wird oder statt dessen fstrim in Etappen, das wird sehr kontrovers diskutiert.
Das Problem mit delayed trim liegt an der Befehlswarteschlange des AHCI der SSD.

(discard wird erst seit dem ext4-Dateisystem unterstützt, fstrim geht auch mit ext3, aber das ist ein anderes Thema.)

 

[avd700]

Hallo!
Mal ganz andere Idee.
Könnte es sein das z.b.ein
Trojaner auf dem Rechner sitzt und
deswegen alles blockiert am Anfang??
Oder irgendein Prozess??
Zur Sicherheit hab ich gestern mal den Home
Ordner gesichert.

 

[avd700]

 

[avd700]

 

[josef-wien]

Dein erstes Bild zeigt, daß das grafische Programm Informationen verschweigt, die smartctl sehr wohl liefert. Dein zweites Bild ist für mich ein weiteres Indiz für ein Hardware-Problem. Im übrigen nehme ich an, daß Dir iotop nach dem Systemstart keine auffälligen Zugriffe meldet.

Aber meine SSD ist noch nicht mal in der smart datenbank.

Führe als root

/usr/sbin/update-smart-drivedb

aus, dann erhältst Du eine aktuelle Datei /usr/share/smartmontools/drivedb.h. Im 4.1er-Kernel ist für "Samsung SSD 8*" queued TRIM deaktiviert, ob das auf den von openSUSE verwendeten Kernel rückportiert wurde, kann ich nicht sagen. Falls Du eine andere Samsung-SSD hast, wäre ein bug report sinnvoll.

 

[revealed]

/sry OffT: Danke für den Tipp mit der Datenbank. Meine SAMSUNG ist da jetzt unterstützt, meine ADATA SX900 ist noch unbekannt. Das mit dem backport würde mir tierisch taugen, aber ich helfe mir mit einer cron.daily das geht auch. Gefährlich ist es halt für diejenigen die nicht wissen dass die SAMSUNG 840 mit der neuesten firmware bei discard mit NCQ Amok läuft. /OffT

Zu den screenshots:
Das der Benchmark fehlschlägt "köööönnnnteeee ein bug in dem tool sein. Siehe hier:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1081019
Post #5

Ich weiss aktuell nicht, ob das auch bei SUSE der Fall sein könnte.

Zu: Deinen letzteren Fragen mit Trojaner usw:
Wie sieht es denn aus mit dem monitoring beispielsweise via iotop?

Dazu würde mich jetzt noch wirklich interessieren:

cat /etc/fstab

Und das ganze andere das noch nicht beantwortet wurde. (monitoring oder screening). Ob die Firmware aktualisiert wurde usw. sorry aber da sind noch einige offene Fragen.

LG,

R

 

[Anonymous]

Zu den screenshots:
Das der Benchmark fehlschlägt "köööönnnnteeee ein bug in dem tool sein. Siehe hier:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1081019
Post #5

Ich weiss aktuell nicht, ob das auch bei SUSE der Fall sein könnte.

Den Fehler (g-io-error-quark, 0) kann ich bestätigen. Das könnte durchaus auch mit der PC/Notebook-Hardware zusammenhängen.
In diesem Fall mit Intel ICH7-M, allerdings nur unter einer älteren Version 3.6.1 von gnome-disk-utility getestet. Da steht das Update noch aus.

@ avd700
Du verwendest fürs „/home“ (Partition 7) das XFS-Dateisystem. Also für „/“ (Partition 5 oder 6) dann BTRFS, stimmt's?
Das wird im Bildschirmschnappschuss durch das darüberliegende Fenster leider verdeckt.

Die Festplatte (ST332082 0AS), die noch in Deinem Rechner steckt, ist bereits ganz schön alt.
Nur Interesse halber: Welche Hardware verwendest Du?

sudo dmidecode -t 2,4,10

Zumindest der Anfangswert der SSD-Lesemessung überzeugt nicht gerade, und später nur knappe 216 MB/s (=206 MiB/s).
War vor dem Start der Messung wirklich Ruhe im System & auf der SSD?

 

[avd700]

Passwort: 
linux-f3f2:~ # sudo dmidecode -t 2,4,10
# dmidecode 2.12
SMBIOS 2.5 present.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK Computer INC.
        Product Name: Berkeley
        Version: 1.xx
        Serial Number: MS1C7AR60503707
        Asset Tag:                                 
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis:                                 
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

Handle 0x0004, DMI type 4, 40 bytes
Processor Information
        Socket Designation: CPU 1
        Type: Central Processor
        Family: Other
        Manufacturer: Intel            
        ID: FB 06 00 00 FF FB EB BF
        Signature: Type 0, Family 6, Model 15, Stepping 11
        Flags:
                FPU (Floating-point unit on-chip)
                VME (Virtual mode extension)
                DE (Debugging extension)
                PSE (Page size extension)
                TSC (Time stamp counter)
                MSR (Model specific registers)
                PAE (Physical address extension)
                MCE (Machine check exception)
                CX8 (CMPXCHG8 instruction supported)
                APIC (On-chip APIC hardware supported)
                SEP (Fast system call)
                MTRR (Memory type range registers)                                                                                                          
                PGE (Page global enable)                                                                                                                    
                MCA (Machine check architecture)                                                                                                            
                CMOV (Conditional move instruction supported)                                                                                               
                PAT (Page attribute table)                                                                                                                  
                PSE-36 (36-bit page size extension)                                                                                                         
                CLFSH (CLFLUSH instruction supported)                                                                                                       
                DS (Debug store)                                                                                                                            
                ACPI (ACPI supported)                                                                                                                       
                MMX (MMX technology supported)                                                                                                              
                FXSR (FXSAVE and FXSTOR instructions supported)                                                                                             
                SSE (Streaming SIMD extensions)                                                                                                             
                SSE2 (Streaming SIMD extensions 2)                                                                                                          
                SS (Self-snoop)                                                                                                                             
                HTT (Multi-threading)                                                                                                                       
                TM (Thermal monitor supported)
                PBE (Pending break enabled)
        Version: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz     
        Voltage: 1.3 V
        External Clock: 267 MHz
        Max Speed: 2400 MHz
        Current Speed: 2400 MHz
        Status: Populated, Enabled
        Upgrade: Other
        L1 Cache Handle: 0x0005
        L2 Cache Handle: 0x0006
        L3 Cache Handle: Not Provided
        Serial Number:                                 
        Asset Tag:                                 
        Part Number:                                 
        Characteristics: None

Handle 0x0028, DMI type 10, 6 bytes
On Board Device Information
        Type: Video
        Status: Enabled
        Description:                                  

Handle 0x0029, DMI type 10, 6 bytes
On Board Device Information
        Type: Sound
        Status: Enabled
        Description:  Intel(R) HD Audio

Handle 0x002A, DMI type 10, 6 bytes
On Board Device Information
        Type: Ethernet
        Status: Enabled
        Description:                                  

linux-f3f2:~ #

Ja das stimmt die Kiste ist schon einige Jahre alt.

linux-f3f2:~ # cat /etc/fstab
UUID=9b0c8f81-e027-4f93-8169-13d54b5f5d86 swap swap defaults 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f / btrfs defaults 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /opt btrfs subvol=opt 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /srv btrfs subvol=srv 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /tmp btrfs subvol=tmp 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /usr/local btrfs subvol=usr/local 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/crash btrfs subvol=var/crash 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/lib/mailman btrfs subvol=var/lib/mailman 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/lib/named btrfs subvol=var/lib/named 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/log btrfs subvol=var/log 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/opt btrfs subvol=var/opt 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/spool btrfs subvol=var/spool 0 0
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /var/tmp btrfs subvol=var/tmp 0 0
UUID=fa3ccf62-4c2d-4b25-88e7-3d30c9f7d73d /home xfs defaults 1 2
UUID=9fd1074e-756a-43ad-882a-373b0c1eba7f /.snapshots btrfs subvol=.snapshots 0 0
linux-f3f2:~ #

 

[revealed]

Die Ausgabe der fstab schaut für mich ok aus. Ich wollte sehen, ob da irgendwas wie automatisches trim eingetragen ist, dass die Platte in speziellen Szenarien verlangsamen oder zu Fehlern verleiten kann.

Bei manchen Geräten ist das leider so. Aber da du denke ich ab und an via script oder händisch fstrim ausführst sollte das schon ausgeschlossen sein.

Gruß,

R

 

[Anonymous]

@ avd700
Das habe ich vermutet: Dein Mainboard unterstützt nur Serial ATA Revision 2.x, also Brutto 3 Gbit/s.
Im Klartext heißt das: Es nutzt leider nur die Hälfte des Potentials Deiner SSD.
→ theoretisches Datentransfermaximum 286 MiB/s und geschätzt max. 50000 Input/Output Operationen pro sek. (IOPS).

Im IOPS-Vergleich zu einer mehreren huntertmal langsameren Festplatte ist das dennoch deutlicher Gewinn in Verbindung mit einer Intel Core2Quad Q6600.
Und 10 Jahre Herstellergarantie sind auch ein Wort.

Ich persönlich rate dringend zum SSD-Firmwareupdate (siehe bitte auch die Firmware Release notes).

Ansonsten würde mich eines noch interessieren: TRIM
Mache mal bitte einmalig in einem root-Terminal (=Superuser-Modus), nachdem sich das System beruhigt hat:

fstrim -a -v

Und poste die Ausgabe davon.

 

[avd700]

Passwort: 
linux-f3f2:~ # fstrim -a -v
/home: 86.5 GiB (92908687360 bytes) trimmed
/boot/grub2/i386-pc: 11 GiB (11849342976 bytes) trimmed
/opt: 9.6 GiB (10328088576 bytes) trimmed
/boot/grub2/x86_64-efi: 9.6 GiB (10327695360 bytes) trimmed
/srv: 9.6 GiB (10327711744 bytes) trimmed
/tmp: 9.6 GiB (10327859200 bytes) trimmed
/usr/local: 9.6 GiB (10327859200 bytes) trimmed
/var/crash: 9.6 GiB (10327859200 bytes) trimmed
/var/lib/mailman: 9.6 GiB (10327859200 bytes) trimmed
/var/lib/named: 9.6 GiB (10327859200 bytes) trimmed
/var/log: 9.6 GiB (10327859200 bytes) trimmed
/var/lib/pgsql: 9.6 GiB (10327859200 bytes) trimmed
/var/opt: 9.6 GiB (10327859200 bytes) trimmed
/var/spool: 9.6 GiB (10328023040 bytes) trimmed
/var/tmp: 9.6 GiB (10328023040 bytes) trimmed
/.snapshots: 9.6 GiB (10328023040 bytes) trimmed
/: 9.6 GiB (10328023040 bytes) trimmed
linux-f3f2:~ #

 

[revealed]

dmesg | egrep "ata|error|fail|should|could|need|NCQ|exception|timeout|invalid|frozen"

Gruß,

R

 

[Anonymous]

@ avd700
Oh, oh!
Also ich kann Dir mit Sicherheit sagen, dass Queued Trim nicht die Fehlerursache für den Spuk ist.
TRIM wurde, seit Du Linux installiert hast, nämlich noch gar nicht ausgeführt!
Dabei sollte dieser Vorgang, so je nach PC-Nutzung 1× wöchenlich oder auch 1× monatlich erfolgen.

Das hast Du jetzt erstmals getan und dem Controller dadurch quasi mitgeteilt, welche Datenblöcke auf der SSD freigeworden sind.
Bis die Müllabfuhr (eng. garbage collection) oder genauer gesagt, die Freispeichersammlung, vollständig abgeschlossen ist, können unter Umständen mehrere Stunden vergehen. Der Controller der SSD nutzt dafür die Pausenzeiten, wenn sonst keine Arbeit ansteht.

Beobachte ab jetzt mal Dein openSUSE weiter, ob der Fehler „System lahmt“ momentan behoben ist.
Und verschiebe das SSD-Firmwareupdate bitte vorerst, denn auf die zwei, drei Wochen kommt es nun auch nicht mehr an.
Nutze einfach den Rechner wie eh und je.


Dann legst Du bitte bei nächster Gelegenheit als root ein Script an (das eilt nicht):

#!/bin/sh
TRIMLOG=/var/log/SSD_trim_wöchentlich.log
echo "*** $(date -R) ***" >> $TRIMLOG
fstrim -a -v / >> $TRIMLOG

speicherst es z.B. unter dem Namen » SSD_trim_wöchentlich « und kopierst es ins Verzeichnis » /etc/cron.weekly/ «
Dann wird noch das Dateiattribut auf „ausführbar“ gesetzt (z.B. im Terminal):

chmod 755 /etc/cron.weekly/SSD_trim_wöchentlich

—
Du kannst dann jederzeit in der Datei /var/log/SSD_trim_wöchentlich.log den TRIM-Status kontrollieren.

 

[avd700]

@ rolandb
Also Danke für Deine Tips und den Einsatz!!
Ich denke trim ist wohl sowas wie defragmentierung im win??!!
Nun das Problem besteht allerdings weiterhin.
wenn an der Platte was gravierendes kaputt wäre , dann
würd ich doch nicht ganz normal so wie jetzt gerade damit
arbeiten können??
Wie gesagt sobald die grüne Led nicht mehr im
dauerleuchten ist, funktioniert alles ganz normal.

 

[Anonymous]

@ rolandb
Also Danke für Deine Tips und den Einsatz!!

Gern geschehen! Ich arbeite fast ausschließlich unter Linux. Und auf meinem aktuellen Arbeitsgerät ist auch nichts anderes installiert. Das merkt man wahrscheinlich.
Irgendwann will ich mal Win2000 oder XP in einer Virtuellen Maschine installieren.
Ich habe da noch Programme z.B. für die Sony MiniDisc, die unter Wine nicht laufen wollen.

Ich denke trim ist wohl sowas wie defragmentierung im win??!!

Die Dateidefragmentierung in einer Festplattenpartition wird vom Betriebssystem gesteuert.
Eine moderne SSD lässt nicht „von außen“ defragmentieren. Das übernimmt ausschließlich der Controller der SSD.

Nun ist es sogar so, dass sich Dateien auf einer SSD „von außen“ nicht entfernen lassen, da das Betriebssystem gar keine Ahnung davon hat, wo genau sich die Datei versteckt hält. Es kann nur das Dateisystem aktualisieren. Jetzt kommt TRIM ins Spiel: Es teilt dem Controller der SSD mit, welche Datenblöcke auf der SSD freigeworden sind. Der SSD-Controller erledigt dann die Sache mit dem Sammeln nun freigewordener Speicherzellen selbstständig.

Eine komplett fehlende TRIM-Anweisung macht sich bei normaler PC-Nutzung wenn überhaupt erst nach Jahren bemerkbar, solange genug freie Speicherzellen vorhanden sind, denn der Controller der SSD sorgt auch ohne TRIM völlig autark ständig für Ordnung, d.h. optimale Zellenbelegung und gleichmäßige Nutzungsverteilung („native Defragmentierung”).

» /home: 86.5 GiB (92908687360 bytes) trimmed « sind für 7 Monate —also ø 415 MiB/Tag— schon eher intensive Nutzung. Da hast Du bereits einiges an Daten weggeschrieben und wieder gelöscht. Ein monatliches TRIM-Kommando wäre da trotzdem immer noch völlig ausreichend.

Nun das Problem besteht allerdings weiterhin.
wenn an der Platte was gravierendes kaputt wäre , dann
würd ich doch nicht ganz normal so wie jetzt gerade damit
arbeiten können??
Wie gesagt sobald die grüne Led nicht mehr im
dauerleuchten ist, funktioniert alles ganz normal.

Dann mache jetzt das SSD-Firmwareupdate.
Link: http://forum.linux-club.de/viewtopic.php?f=89&t=120453&start=20#p767051
Wenn Du fertig bist, dann gib bitte nochmal die Ausgabe der SMART-Werte. Dann können wir sehen, ob inzwischen mehr defekte Zellen dazugekommen sind.

smartctl -a /dev/sda

 

[avd700]

Hallo
So,ich denke der Rechner läuft wieder vernünftig.
Was mich von Anfang an stutzig gemacht hat,war das
in der Konsole bei zypper up Loading repository data
der Kasten hängen geblieben ist.
Gestern Abend hab ich alle Repos ausser nvidia, Packman und mozilla
gelöscht und die online Aktualisierung von täglich auf monatlich gesetzt.
Seit dem gibt es kein dauerleuchten der besagten Led mehr und der
Rechner läuft gut.
Hab ihn allerdings erst zweimal gebootet.
vielleicht kann ich ein paar Tips bekommen in Bezug auf wichtige repos.

@rolandb
besten Dank für die Erklärung der SSD.

 

[Anonymous]

So,ich denke der Rechner läuft wieder vernünftig.
Was mich von Anfang an stutzig gemacht hat,war das
in der Konsole bei zypper up Loading repository data
der Kasten hängen geblieben ist.
(…)
Hab ihn allerdings erst zweimal gebootet.

Softwareproblem — Das hättest Du anhand der Systemauslastung erkennen können.
Da gibt es eine ganze Reihe von Programmen; auch für die Kontrollleiste (Systemabschnitt).
Hardwareproblem — Da ich Deine SSD-Belegung nicht kenne, wäre noch eine TRIM-Nachwirkung möglich, d.h. jetzt wieder gut.
Hat das Firmwareupdate für die SSD geklappt?

Dein Rechner hat auch etwas wenig und leicht ungünstigen Arbeitsspeicher 1 GiB + 2 GiB Riegel.
Besser wären zwei 2 GiB-RAM-Riegel und vom gleichen Typ (Hersteller). Mehr kann Dein Mainboard glaube ich eh nicht. 4 GiB sind aber gut.

vielleicht kann ich ein paar Tips bekommen in Bezug auf wichtige repos.

Hier: de.opensuse.org/Paket_Repositorys

LibreOffice 4.4, filesystems, KDE:Extra, libdvdcss
habe ich auch.
Alle Packman-Repos stelle ich in der Priorität auf 20,
alle openSUSE-Update-Repos auf Priorität 70.

Je mehr Repositories Du ins System einbindest, desto mehr musst Du aufpassen, welche Pakete und Paketgruppen Du aus welcher Quelle aktualisierst. Die haben nämlich überall unterschiedliche Versionsstände!