Hallo Leute!

Weil der Plastikstecker anfing zu brechen, habe ich mir einen neuen USB Stick gekauft. Frisch mit exFAT formatiert und getestet kommt dieses Ergebnis:


CrystalDiskMark 9.0.1 x64 (C) 2007-2025 hiyohiyo
Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ [Read]
SEQ 1MiB (Q= 8, T= 1): 151.225 MB/s [ 144.2 IOPS] < 55185.82 us>
SEQ 1MiB (Q= 1, T= 1): 151.108 MB/s [ 144.1 IOPS] < 6934.90 us>
RND 4KiB (Q= 32, T= 1): 7.515 MB/s [ 1834.7 IOPS] < 17404.89 us>
RND 4KiB (Q= 1, T= 1): 5.573 MB/s [ 1360.6 IOPS] < 734.10 us>

[Write]
SEQ 1MiB (Q= 8, T= 1): 71.609 MB/s [ 68.3 IOPS] <115576.06 us>
SEQ 1MiB (Q= 1, T= 1): 71.679 MB/s [ 68.4 IOPS] < 14601.16 us>
RND 4KiB (Q= 32, T= 1): 0.456 MB/s [ 111.3 IOPS] <251595.29 us>
RND 4KiB (Q= 1, T= 1): 0.480 MB/s [ 117.2 IOPS] < 8430.69 us>

Testfile 8 x 1 GB.

Ich hatte es bisher noch nie, dass ein USB Stick mehr IOPS bei random Zugriffen hatte als bei sequentiellen, kann das ein Messfehler sein?

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Ich weiss wo mein Handtuch ist. (2:240/77)

<Kai Richter@2:240/77> schrieb am 14.11.25:

Ich hatte es bisher noch nie, dass ein USB Stick mehr IOPS bei random Zugriffen hatte als bei sequentiellen, kann das ein Messfehler sein?

Glaube ich nicht. Ich bin bei USB-Sticks mittlerweile so weit, dass ich
die f�r gr��ere Dateien/Datenmengen �berhaupt nicht mehr einsetze, weil
die kleinen Dinger regelm��ig �berhitzen und dann runterschalten. So geschehen hier mit meinem System und Linuxclone:

fex.belwue.de/linuxtools/linuxclone.html

Das erstellt ein bootbares Medium mit einer 1:1-Kopie meines Systems. Mit Stick erstellt/gebootet ist das aber selbst mit nicht ganz billigem Sandisk-Stick nach einiger Zeit untertr�glich langsam, dann geht es
wieder, dann lahmt es wieder, wohl je nach aktueller Temperatur,
letztendlich chaotisch.

Als Zwischenl�sung habe ich mir f�r ein paar hier �brige SSDs USB-Geh�use bestellt, damit geht alles um gesch�tzt den Faktor 20 schneller. Einen
Tipp bekam ich noch von Marc Haber aus der Linux-Newsgroup, der nimmt
jetzt NVMEs in externem Geh�use, die sind zwar auch gr��er als 2,5" USB- Geh�use, aber vom Formfaktor auch mal in der Hosentasche zu transportieren und zeigen auch diese thermischen Effekte nicht. Das probiere ich dann vielleicht mal als n�chstes.

- jw -

--- OpenXP 5.0.64
* Origin: (2:240/2188.13)

Hello Joerg!

15 Nov 25 08:52, Joerg Walther wrote to Kai Richter:

jetzt NVMEs in externem Geh�use, die sind zwar auch gr��er als 2,5"
USB-
Geh�use, aber vom Formfaktor auch mal in der Hosentasche zu transportieren
und zeigen auch diese thermischen Effekte nicht. Das probiere ich
dann
vielleicht mal als n�chstes.

Grunds�tzlich ist auch meine Erfahrung, da� externe SSDs (egal, ob nun fertig gekaufte oder selbst zusammengebaute) mittlerweile im Vergleich zu USB-Sticks eine preislich attraktive, schnellere und robustere L�sung sind. Die Temperaturproblematik h�ngt aber auch da ma�geblich von der Last ab. Wenn Du sowas an einen USBC-Port (o.�.) mit entsprechender Bandbreite (10GB+) h�ngst und l�ngere Zeit Daten �bertr�gst, dann wird das irgendwann auch ordentlich warm. ;)


Regards,
Gerrit

... 9:16AM up 344 days, 16:23, 9 users, load averages: 0.79, 0.99, 0.93

--- msged/fbsd 6.3 2021-12-02
* Origin: A true lie to believe (2:240/12)

Hey Joerg!

Am 15 Nov 25, Joerg Walther schrieb an Kai Richter:

billigem Sandisk-Stick nach einiger Zeit untertr�glich langsam, dann
geht es wieder, dann lahmt es wieder, wohl je nach aktueller
Temperatur, letztendlich chaotisch.

Ich habe diesen Effekt bisher immer f�r ein Cache Verhalten der systemd betriebenen Linux Distros gehalten. Ich weiss nicht ob der Stick der gerade dieses Verhalten zeigt der geteste war, es ist ein Kingston mit Metallgeh�use (aka d�nnes Metallblech) mit einer schwarzen Plastik�se. Ich setze gerade ventoy auf diesen und habe gerade 6GB an boot images kopiert. Die sind zu ca. 80% z�gig durchgelaufen und hingen dann eine gef�hlte Ewigkeit bei 80% fest.

Das Metallgeh�use sollte die W�rme eigentlich sehr gut leiten, aber es war durch Finger auflegen gef�hlt nicht warm und damit gar kein Vergleich zu den sonstigen heissen Sticks.

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Chamber's empty, time to reload. (2:240/77)

<Kai Richter@2:240/77> schrieb am 24.12.25:

billigem Sandisk-Stick nach einiger Zeit untertr�glich langsam, dann
geht es wieder, dann lahmt es wieder, wohl je nach aktueller
Temperatur, letztendlich chaotisch.

Ich habe diesen Effekt bisher immer f�r ein Cache Verhalten der systemd betriebenen Linux Distros gehalten. Ich weiss nicht ob der Stick der gerade dieses Verhalten zeigt der geteste war, es ist ein Kingston mit Metallgeh�use.

Interessant, das k�nnte nat�rlich hier auch das Problem sein (Ubuntu
22.04), aber wie lie�e sich das feststellen? Abgesehen h�rt sich das doch nach einem so schwerwiegenden Bug an, dass man meinen k�nnte, dass der
l�ngst gefixt w�re? Auf jeden Fall waren meine Sticks nicht nur langsam, sondern auch hei�.

- jw -

--- OpenXP 5.0.64
* Origin: (2:240/2188.13)

Servus Joerg!

Am 25 Dec 25, Joerg Walther schrieb an Kai Richter:

Ich habe diesen Effekt bisher immer f�r ein Cache Verhalten der

Interessant, das k�nnte nat�rlich hier auch das Problem sein (Ubuntu 22.04), aber wie lie�e sich das feststellen?

Mit dem Cache rumspielen? Ohne Gew�hr, hdparm -W 0 /dev/stick.

Ich habe auch noch Hinweise gefunden, dass die mount optionen sync vs flush einen Unterschied machen.

Abgesehen h�rt sich das doch nach einem so schwerwiegenden Bug an,
dass man meinen k�nnte, dass der l�ngst gefixt w�re?

Ich bin nicht sicher, ob es ein Bug ist. Bzw. was genau ist der Bug? Dass schneller Daten als "gespeichert" gemeldet werden, obwohl sie noch im Cache h�ngen und auf den Storage geschrieben werden m�ssen?

Im Alltag l�uft das idR im Hintergrund, w�hrend der Nutzer weiter rumklickt.

Auf jeden Fall waren meine Sticks nicht nur langsam, sondern auch
hei�.

Das trifft auch f�r viele meiner Sticks zu.

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Auf jeden Fall aber sehr genau schauen, was Sache ist (2:240/77)