SSD Innenleben: Disk- vs. Datenmanagment

[Korfox]

Huh, da muss ich ja noch was lernen. Ich kenne immer nur make all

 

[rennradler]

cmake ist ein Makefile-Generator. Makefiles sind schwierig zu schreiben (zumindest für größere Projekte), cmake vereinfacht den Prozeß. Aber letztendlich wir das Projekt mit make gebaut.

 

[Korfox]

Es war ein Scherz. Ich bin Softwareentwickler.
Die meisten Projekte bieten halt den Luxus, aber das ist völlig unerheblich. Wegen mir kannst du auch einfach deinen Quellcode auf pastebin werfen und ich bekomme das immernoch hin.

 

[Ambrosius]

@rennradler Großes Dankeschön, sieht sehr nice aus. Danke für die Mühe.

@all-die-eine-980Pro-haben: Erst gestern wurde von Samsung ein neues FW Update ausgerollt, das den Read Only Bug betrifft. Computerbase hat dazu ein Artikel rrausgebracht. Weiter unten werden auch die Probleme mit der 990Pro erwähnt.

 

[ebastler]

Ich habe meine 980 Pro Oktober 22 gekauft, nie aktualisiert und die hatte das neuste Update (mit 5 vorn) schon drauf...

Entweder das Update ist seit Monaten schon da und nur die Pressemitteilung ging jetzt raus, oder Windows aktualisiert im Hintergrund ohne Hinweis dir SSD Firmware...

 

[rennradler]

Kleine Update:
Es kann ein negatives Alter ausgegeben werden. Das ist kein Bug, sondern liegt an Dateien, die aus irgend welchen Gründen ein Zeitstempel in der Zukunft haben. Ich habe auf diese Weise ein paar uralte kml-Dateien von Bergtourplanungen gefunden, bei denen das der Falls ist.

 

[Schwartz]

Die Firmware ist seit knapp einem Jahr draußen; die war bei dir also schon drauf.
Windows kann da nichts aktualisieren, das geht soweit ich weiß nur mit dem Magician.

 

[Korfox]

Initiale Version ist fertig. Könnt Ihr Euch auf GitHub anschauen.

GitHub - bernhardg67/SSD-Read-Speed-Degen-Test: Simple test program for Linux to detect SSD Read Speed Degeneration Problems

Simple test program for Linux to detect SSD Read Speed Degeneration Problems - GitHub - bernhardg67/SSD-Read-Speed-Degen-Test: Simple test program for Linux to detect SSD Read Speed Degeneration P...

github.com

Ich habe kein Binary eingestellt, da ich auf Arch bin und daher immer die neuesten Libraries habe. Zudem könnt ihr euch den Source Code ansehen und euch überzeugen, daß das Programm sauber ist. Für Bug-Freiheit kann ich nicht garantieren, nur für Gutwilligkeit.

Sollte sich auf jedem anständigen Linux-System kompilieren lassen. Braucht hat gcc/g++ (mit C++17 features), cmake und GNU find.

So, jetzt nochmal ernsthaftes Feedback...
Auch bei mir ist da noch nicht viel zu holen

# device_id	inode_number	Age_in_Seconds	Size_in_Bytes	Time	MB_per_Second
66308	8003044	243888313	16426032	6.9791e-03	2.2446e+03

Sieht aber prinzipiell gut aus.
Cool wäre es natürlich, wenn man ein human readable Format hätte bzw. einen Schalter dafür.
Und auch cool wäre, wenn die Ausgabe fließend wäre und nicht nach der Wartezeit alles auf einmal käme.

 

[ebastler]

Die Firmware ist seit knapp einem Jahr draußen; die war bei dir also schon drauf.
Windows kann da nichts aktualisieren, das geht soweit ich weiß nur mit dem Magician.

Dachte ich mir fast schon... Dann kam nur die Nachricht, dass die FW gegen die Bugs helfe, erst gestern, nicht aber die FW selbst. Danke für die Info! Wo hast du das gefunden? Konnte nirgends ein Changelog oder Release dates finden bei Samsung...

 

[Schwartz]

Im Computerbase-Forum stand das im Thread zum Artikel. Samsung hält sich gerne bedeckt und macht auch keine Releases in dem Sinne. Diese Seite hier ist noch nützlich wenn man den Magician nicht drauf hat.

 

[Ambrosius]

So, jetzt nochmal ernsthaftes Feedback...
Auch bei mir ist da noch nicht viel zu holen

# device_id	inode_number	Age_in_Seconds	Size_in_Bytes	Time	MB_per_Second
66308	8003044	243888313	16426032	6.9791e-03	2.2446e+03

Sieht aber prinzipiell gut aus.
Cool wäre es natürlich, wenn man ein human readable Format hätte bzw. einen Schalter dafür.
Und auch cool wäre, wenn die Ausgabe fließend wäre und nicht nach der Wartezeit alles auf einmal käme.

wo sind denn die Flags auf die man achten sollte? Also welcher Wert zeigt verdächtiges Leseverhalten auf?

 

[Korfox]

Na im Endeffekt ist es hauptsächlich der Zusammenhang zwischen Age in Seconds und MB per Second. Wobei kleine Dateien naturgemäß langsamer gelesen werden als als große, weil sich die Zugriffszeit hier überproportional und je nach Größe die Dateien nicht über die Speicherkanäle verteilt werden können. Ich habe den Test auf Dateien >10MB gefiltert.
Im Optimal Fall sollten Dateien die heute erzeugt wurden genauso schnell gelesen werden, wie Dateien, die seit einem Jahr auf dem Datenträger liegen.

 

[rennradler]

Cool wäre es natürlich, wenn man ein human readable Format hätte bzw. einen Schalter dafür.
Und auch cool wäre, wenn die Ausgabe fließend wäre und nicht nach der Wartezeit alles auf einmal käme.

Die Ausgabe erfolgt sortiert nach Dateialter, daher kann ich die Liste nicht stückweise ausgeben - ich könnte parallel unsortiert nach stdout schreiben. Lesen soltte grundsätzlich erst nach dem Aufbau der Liste erfolgen, sonst würde das Ergebnis m.E. verfälscht, wenn find parallel die SSD durchwühlt.
Was wünscht du dir für human readable? Ich habe die Ausgabe so gemacht, daß sie in einem Plotprogramm einfach weiterverabeitet werden kann.

 

[Korfox]

Ich habe mir den Quellcode (noch) nicht angesehen. Ich hätte erwartet, dass du zum Zeitpunkt des Lesens das Dateialter schon kennst.
Im Optimal Fall ist hr natürlich konfigurierbar.
Bytes halte ich z.b. für obsolet, weil die Dateien zu klein sind, wenn sie keine mehrere MB groß sind.
MB halte ich für sinnvoll und das Alter nicht in Sekunden sondern Tagen. Der Effekt tritt ja erst nach Monaten auf.

Vielleicht packen mich aber auch Zeit und Muße und ich mach bei Gelegenheit nen PR.

 

[rennradler]

Ich lese erst die komplette Liste von find und arbeite sie dann ab. Ich hatte nicht gedacht, daß ein sofortige Ausgabe was bringt. Im Prinzip könnte ich auch gleich einen stat-Aufruf machen und dann die List vor Lesebeginn sortiert haben und so abarbeiten.

 

[Korfox]

Naja. Als Entwickler ist mir sowas auch egal, aber User rufen dann immer gleich an und behaupten, daß Tool habe sich aufgehängt, wenn mal 5 Sekunden nichts passiert

 

[mcb]

Initiale Version ist fertig. Könnt Ihr Euch auf GitHub anschauen.

GitHub - bernhardg67/SSD-Read-Speed-Degen-Test: Simple test program for Linux to detect SSD Read Speed Degeneration Problems

Simple test program for Linux to detect SSD Read Speed Degeneration Problems - GitHub - bernhardg67/SSD-Read-Speed-Degen-Test: Simple test program for Linux to detect SSD Read Speed Degeneration P...

github.com

Ich habe kein Binary eingestellt, da ich auf Arch bin und daher immer die neuesten Libraries habe. Zudem könnt ihr euch den Source Code ansehen und euch überzeugen, daß das Programm sauber ist. Für Bug-Freiheit kann ich nicht garantieren, nur für Gutwilligkeit.

Sollte sich auf jedem anständigen Linux-System kompilieren lassen. Braucht hat gcc/g++ (mit C++17 features), cmake und GNU find.

Uhi Danke!!!

 

[rennradler]

Oh! Es gibt neue Erkenntnisse an der SSD Read Rate Degeneration Front!

Problem ist folgendes: der Zeitpunkt der letzten Dateiänderung (mtime, das was man mit ls -l sieht) kann vor der Dateierzeugung liegen. Das betrifft typisch das Zeug unter /usr & Co. Da ist eigentlich der Installationszeitpunkt maßgeblich.

Ich habe mir das Problem mit mtime (Zeitpunkt der letzten Inhaltsänderung) und btime (Zeitpunkt der Dateierzeugung) nochmal genauer angeschaut. Da Unix traditionell btime nicht kennt (anders als Windows) liefert der POSIX stat()-Aufruf diese Information nicht, obwohl Linux btime seit vielen Jahren unterstützt (siehe stat-Kommando). Dazu mußte ich in den Systems Calls graben und die Sourcen von GNU stat sezieren, weil die Doku-Lage für Nicht-Kernel-Insider schwierig zu durchdringen ist.

Lange Rede kurzer Sinn: ich habe das Problem gelöst und nehme jetzt den Zeitpunkt der Dateierzeugung, falls dieser jünger ist als Zeitpunkt der letzten Inhaltsänderung. Und so sieht es bei mir jetzt aus:

 # device_id      inode_number    Age_in_days      Size_in_MB    Time            MB_per_Second
  00:1a             464663            40.1             1.9      1.69e-03            1140.6
  00:1a             433866            40.1             1.0      1.00e-03            1001.9
  00:1a             430480            40.1             2.8      2.54e-03            1097.7
  00:1a             429333            40.1             1.2      1.65e-03             712.4
  00:1a             424794            40.1             1.8      2.30e-03             788.3
  00:1a             424229            40.1             1.4      1.92e-03             742.9
  00:1a             423889            40.1             1.2      1.05e-03            1104.0
  00:1a             418256            40.1             2.8      2.21e-03            1280.8
  00:1a             416320            40.1             1.0      9.17e-04            1099.1
  00:1a             338322            40.6             5.0      3.60e-03            1376.2
  00:1a             302316            40.6             1.0      7.58e-04            1353.9

Das gefällt mir nicht. Neueres Zeugs in meinem /home sehe ich typischerweise die doppelte Lesegeschwindigkeit.

Da keine Datei auf dem Rechner älter als 41 Tage ist (da habe ich die SSD eingebaut), muß ich noch abwarten, wie sich das weiterentwickelt.

Ich mach mal einen Update vom GitHub Repository.

 

[Korfox]

Danke für die Umsetzung meines Feedbacks

 

[mcb]

Top. Unter Debian 11 habe ich es auch gebaut bekommen. Das fertige Programm kann ruhig nach /usr/local/sbin oder?

Werde am Wochenende mal messen. Ich habe beide Thinkpads gerade neu gemacht ...

Aber mal schauen was die externen SSDs so hergeben. Wie verhält sich das Problem mit LUKS ohne Trim?