Alles unter 30 MB/s sollte für einen modernen Stick -von dem ich bei 16 GB ausgehe- TABU sein !

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.)

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.

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!

Auf anderen Systemen habe ich das Verhalten bisher nicht versucht zu reproduzieren – ich bin sehr an Feedback bzw. Euren Beobachtungen interessiert.

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.