USB Stick Geschwindigkeit
Linux/OpenSource, ubuntuusers.de Oktober 22nd, 2009Ein 16 GB Kingston USB Stick hatte es mir angetan: Für 25 Euro eine Sache, die man sich mal leisten kann.
Aus alter Erfahrung wollte ich natürlich sichergehen, dass der USB Stick auch die 16GB wirklich leistet – und zwar sicher. (Es gab Fälle in denen das USB Laufwerk eine größere Kapazität vorgegaukelt hat, als nachher drauf war. Und mein letztes 8 GB Thumbdrive ist nach zweimaligem völligen Beschreiben komplett kaputt gegangen.)
Ich habe also mit Linux Bordmitteln das Laufwerk füllen wollen, um dann zu testen, ob die Daten auch so wieder ausgelesen werden können.
Ich startete mit einem Gigabyte und erhöhte dann sukzessive die Datenmenge. Als alles tat, partitionierte ich den Stick neu und wollte damit „normal“ arbeiten. Ich war überrascht, denn die Geschwindigkeit war gefühlt extrem zäh. Irgendetwas konnte einfach nicht stimmen. Vielleicht eine falsche Blockgröße gewählt?
Der USB Stick brauchte wesentlich länger, mit Daten befüllt zu werden, als ich es von den „dd“ Experimenten erwartet hätte.
Nachdem auch ein Neustart des Rechners keine Änderung brachte, war ich verwirrt. (Und ich sollte mir für die Zukunft endlich merken, dass es bei mir noch nie geholfen hat, Linux Rechner neu zu starten, wenn sie nicht das taten, was ich erwartete.)
Das USB Laufwerk schien korrekt eingebunden:
sd 7:0:0:0: [sdb] 31309760 512-byte hardware sectors: (16.0 GB/14.9 GiB)
sd 7:0:0:0: [sdb] Write Protect is off
sd 7:0:0:0: [sdb] Mode Sense: 16 23 09 51
sd 7:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
Dann kam mir eine Idee: Könnte es sein, dass ein partitionierter USB Stick deutlich langsamer ist, als ein Filesystem direkt auf dem Device?
Ein Test bringt Klarheit:
tkruse@helix:~/$ sudo dd if=sample.data of=/dev/sdb1 bs=1000 count=2000000
2000000+0 records in
2000000+0 records out
2000000000 bytes (2.0 GB) copied, 2059.02 s, 971 kB/s
tkruse@helix:~/$ sudo dd if=sample.data of=/dev/sdb bs=1000 count=2000000
2000000+0 records in
2000000+0 records out
2000000000 bytes (2.0 GB) copied, 877.241 s, 2.3 MB/s
Meine Theorie: Der Kingston USB Stick ist auf die Zugriffsmuster des FAT Dateisystems ohne separate Partition optimiert. Vermutlich führt die Paritionstabelle dazu, dass Schreibzugriffe durch den Versatz Blockgrenzen überlappen, und so Blöcke doppelt (bzw. dreifach) beschrieben werden müssen. Das erklärt auch die fast um Faktor drei schlechtere Performance des USB Stick mit Partitionstabelle.
Wieder etwas gelernt – und schnell das Dateisystem ohne Partitionen erzeugt.
Oktober 22nd, 2009 at 23:06
Moin,
finde ich interessant was du herausgefunden hast und ich würde das auch mal bei mir Testen.
Ich habe mal 2 Fragen dazu:
Wie erzeuge ich ein Dateisystem ohne Partitionierung ??
Und funktioniert das ganze dann auch auf / an anderen Rechnern / Systemen ??
Oktober 22nd, 2009 at 23:47
Woran es (teilweise?) auch liegen könnte:
Flash-Speicher wird generell langsamer wenn er bereits beschrieben wurde…
Um einen bereits einmal beschriebenen Sektor neu zu beschreiben, muss dieser erst in einem getrennten Durchgang gelöscht werden und kann danach erst wieder beschrieben werden.
Daher gibt es ja jetzt die Anstrengungen SATA-Flash-Disks mitzuteilen welche Sektoren wieder als „gelöscht“ markiert wurden, so dass der Controler diese bei gelegenheit freigeben könnte und das nächste Schreiben wieder mit der ursprünglichen Geschwindigkeit stattfinden kann.
Oktober 23rd, 2009 at 07:07
WOw, ich hab erst kürzlich ähnliche Erfahrungen gemacht, und das ganze auf den „billigen“ USB-Stick zurückgeführt… jetzt werd ich mal versuchen, ob es mit FAT schneller funktioniert…
Besten Dank fürs „herausfinden“.. 🙂
Oktober 23rd, 2009 at 07:10
Das Dateisystem habe ich mit „mkfs.vfat“ erzeugt, und dann direkt /dev/sdX genommen. Jedoch muss zusätzlich „-I“ angegeben werden, denn das Programm erwartet eigentlich ein partitioniertes Device. (Also den kompletten USB Stick mit vfat einrichten: „mkfs.vfat -I /dev/sdb“ wobei bei mir der USB stick eben als /dev/sdb eingebunden wurde.
Auf anderen Systemen habe ich das Verhalten bisher nicht versucht zu reproduzieren – ich bin sehr an Feedback bzw. Euren Beobachtungen interessiert.
Oktober 23rd, 2009 at 07:44
Wird das Ding dann auch noch von Windows-Systeme erkannt? Bei meinem USB-Stick würde ich ich das ja noch trauen, aber mein MP3 Player hat leider dasselbe Problem, der wird dann sicherlich nicht mehr laufen 🙁
Oktober 23rd, 2009 at 07:54
Ja, wird er – der USB Stick wird nämlich auch genau so vom Händler ausgeliefert. (Macht ja auch Sinn, den direkt „richtig“ auszuliefern, statt mit angezogener Handbremse.)
Oktober 23rd, 2009 at 10:23
Mit der Blockgrenze kann es nichts zu tun haben. 512 Bytes physikalische Blöcke sind Standard, und auch die Partitionstabellen arbeiten auf Vielfachen von 512 Bytes.
Ich denke eher, dass der Controller auf direktes FAT optimiert ist, sprich diese Zugriffe erkennt und intern optimiert, während er das mit Partitionstabelle nicht kann. In Folge wird er vermutlich im ersten Fall bei großen Dateien mehrere 512-Byte-Blöcke gleichzeitig schreiben, im zweiten nicht.
Bei SSDs wird diese Art der Optimierung selbstverständlich nicht verwendet (kann gar nicht), hier funktionieren die Controller auch grundsätzlich anders. (Es werden zu beschreibende Zellen immer mit Reservezellen getauscht.) Optimierungen zwischen OS und SSD, die in Entwicklung sind, zielen darauf ab, „Doppelgleisigkeiten“ zu vermeiden und so die Schreibzugriffe weiter zu beschleunigen bzw. dass ein Verschieben von Dateien zwischen zwei Partitionen möglich wird (ohne Kopieren – Löschen). Dazu muss nämlich eigentlich nur der Controller in seiner internen Tabelle die Speicherzellenzuordnungen vertauschen. Geht dann ratzfatz!
Oktober 23rd, 2009 at 10:40
Ähm, ich glaube, ich weiß auch schon, woran’s liegt:
sudo dd if=sample.data of=/dev/sdb1 bs=1000 count=2000000
Probier’s mal mit bs=1024, denn das ist ein Vielfaches von 512! Dann müsste es auch mit Partitionstabelle um einiges schneller gehen, weil die Blocksize nicht mehr ungleich der physikalischen ist. Die Filesysteme, egal welches, arbeiten auch immer mit Vielfachen der physikalischen Blockgröße, aber dd macht natürlich beinhart, was du ihm anschaffst.
Oktober 23rd, 2009 at 10:49
Ich habe mit verschiedenen blockgrößen experimentiert, die Ergebnisse jedoch nicht archiviert. (Angefangen bei 500, 1000, 1024, 2048, 4096, 8192 – ab ~4k war keine signifikante Steigerung mehr messbar. Jedoch blieb der Effekt dass es mit Paritionierung wesentlich langsamer war. Es kann sich dabei natürlich um einen Sondereffekt mit dem Kensington Stick handeln, das schließe ich nicht aus.)
Ok, jetzt nochmal ein anderer USB Speicher an einem anderen System (Ubuntu AMD 64), es handelt sich hier um ein (Werbegeschenk) 1 GB Stick:
scsi 10:0:0:0: Direct-Access Flash Disk 5.00 PQ: 0 ANSI: 2
sd 10:0:0:0: [sdc] 2068992 512-byte hardware sectors: (1.05 GB/1010 MiB)
sd 10:0:0:0: [sdc] Write Protect is off
sd 10:0:0:0: [sdc] Mode Sense: 0b 00 00 08
sd 10:0:0:0: [sdc] Assuming drive cache: write through
sd 10:0:0:0: [sdc] 2068992 512-byte hardware sectors: (1.05 GB/1010 MiB)
sd 10:0:0:0: [sdc] Write Protect is off
sd 10:0:0:0: [sdc] Mode Sense: 0b 00 00 08
sd 10:0:0:0: [sdc] Assuming drive cache: write through
sdc: sdc1
sd 10:0:0:0: [sdc] Attached SCSI removable disk
Nun zum Experiment:
tkruse@charix:~$ sudo dd if=/dev/zero of=/dev/sdc1 bs=1024 count=1M
dd: writing `/dev/sdc1': No space left on device
1028129+0 records in
1028128+0 records out
1052803584 bytes (1.1 GB) copied, 366.431 s, 2.9 MB/s
tkruse@charix:~$ sudo dd if=/dev/zero of=/dev/sdc bs=1024 count=1M
dd: writing `/dev/sdc': No space left on device
1034497+0 records in
1034496+0 records out
1059323904 bytes (1.1 GB) copied, 496.268 s, 2.1 MB/s
tkruse@charix:~$ sudo dd if=/dev/zero of=/dev/sdc1 bs=1024 count=1M
dd: writing `/dev/sdc1': No space left on device
1028129+0 records in
1028128+0 records out
1052803584 bytes (1.1 GB) copied, 358.082 s, 2.9 MB/s
Hier ist also genau das umgekehrte Verhalten zu beobachten! Partitioniert ist rund 50% schneller als direkt auf dem Device zu arbeiten. (Der Dritte Lauf demonstriert lediglich dass die Geschwindigkeit reproduzierbar abweicht, und dabei wirklich der ganze Stick benutzt wird.)
November 7th, 2009 at 14:46
Ist nicht 2,3 MB/s trozdem noch arschlangsam ? Ich würde einen solchen Stick als „defekt“ ausmustern.
Alles unter 30 MB/s sollte für einen modernen Stick -von dem ich bei 16 GB ausgehe- TABU sein !