Hallo zusammen
Habe hier einen uC mit USB Mass Storage. Alles funzt soweit schön.
Langsam, aber schön. Ist auch OK, muss nicht rasant sein, da nur
für gelegentliche Firmwareupdate gedacht.
Ich dachte mir, schau doch mal genauer zu, was der Windows USB Stack so
treibt und protokolliere die Zugriffe.
(Meine Großmutter pflegte so etwas brotlose Künste zu nennen,
ich nenne es gesunde Neugier)
Vorab: das Disklayout ist handgeschnitzt, bedingt durch das Dataflash,
das dahinter das als "Laufwerk" fungiert. Dieses hat 8 MByte und 4 kByte
Sektorgröße, (genauer: ist in Einheiten von 4k löschbar)
so dass sich 2048 Sektoren zu je 4 k ergeben. Clustergröße entsprechend
ebenfalls 4kB. So weit so gut, alles tut ja primel.
Daher gibt es folgende Sektoren
0 Bootsektor
1 FAT (das Ganze wird natürlich automatisch zu FAT12)
(habe auch nur eine FAT Kopie hier am Stissel)
2 Root Directory mit 128 Entries
3 Beginn Daten
so, und wenn ich nun das Laufwerk anstecke, werden folgende Read Sector
Kommandos automatisch von Windows abgesetzt (kein Fenster auf das LW
offen)
angegeben sind hier jeweils lba und Anzahl der Sektoren
Windows XP
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 2 Cnt 1
win 7 ultimate 64 bit
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 2 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
und nach ein paar Sekunden nochmals dieses hier:
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 2 Cnt 1
Adr 3 Cnt 1
Adr 4 Cnt 1
Adr 5 Cnt 1
Adr 6 Cnt 1
Adr 7 Cnt 1
Adr 8 Cnt 1
Adr 9 Cnt 1
Adr 10 Cnt 1
Adr 11 Cnt 1
Adr 12 Cnt 1
Adr 13 Cnt 1
Adr 14 Cnt 1
Adr 15 Cnt 1
Adr 16 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Windows 10 stöbert genau wie WIN7 auch gleich in Daten herum (ab Sektor
3)
Aber dass auch in den Daten-Dateien mehrfach gelesen wird ? (zB 9)
gehts noch ? Ist Windows plemplem?
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 2 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 8 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 2 Cnt 1
Adr 2 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 9 Cnt 1
Adr 2 Cnt 1
Adr 1 Cnt 1
Adr 9 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 9 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 9 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 9 Cnt 1
Adr 10 Cnt 1
Adr 1 Cnt 1
Adr 9 Cnt 1
Adr 11 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Adr 0 Cnt 1
Adr 1 Cnt 1
Aber was ich nun ganz und gar nicht verstehe:
wieso bitteschön werden andauernd Sektor 0 und 1 gelesen, wieder und
wieder ? Das ist doch komplett sinnfrei.
Beim Schreiben geht es dann gleich so weiter.....
ich schreibe eine Datei, die in einen Cluster passt und trotzdem nudelt
Windows mehrfach auf dem FAT Cluster herum ?!?!? echt sinnfrei.
Hat irgendjemand eine Idee was das soll oder weiterführende Links zum
Thema?
grüßings
PS: mir fällt grade auf, dass ich hier Sektor und Cluster teilweise
sysnoym verwende. Bitte das nachzusehen. Sie sind hier halt gleich.
Und irgendwie sind die CR/LF aus den Logs teilweise kaputt. SORRY:
grade eine Datei auf meinem externen LW geöffnet
(1 kByte, passt in einen Cluster)
Windows hat den Cluster ernsthaft 6 mal gelesen!
ob da irgendwas bei der Rückmeldung an den USB Stack kaputt ist und MS
meine Antwort zu lange dauert? Das SPI Dataflash ist nun leider nicht so
rasant zu lesen
vielleicht war da XP noch gutmütiger und die neueren OS sind pingeliger?
das sind so runde 100 ms, bis ich den ganzen Cluster fertig habe.
Vermutlich werden verschiedene Dienste auf das Laufwerk zugreifen -
Papierkorb, dieses Fenster für automatische Wiedergabe usw. Der Treiber
wird das in einzelne Zugriffe umsetzen, statt das zu cachen. Windows ist
halt kein monolithischer ausgefeilter Block der keinen Schritt zu viel
macht, sondern ein komplexes System mit Reibungsverlusten... Es dauert
ja auch ziemlich lange eine große Ordner Struktur zu löschen, obwohl es
ja reichen sollte die FAT 1x zu überschreiben (paar MB) und ein paar
Verzeichnis Einträge zu löschen. Das ist einfach nicht perfekt
implementiert. Glaube auch kaum dass z.B. Linux da besser ist.
Windows fragte wimre auch zig mal die gleichen USB Deskriptoren ab,
vermutlich jedes Mal wenn irgendein System Dienst die wissen will. War
wohl ausreichend schnell und einfacher umzusetzen als die zu cachen.
Carl D. schrieb:> Eventuell werden Zugriffe auf "removable devices" nicht ge-cached?!?
Per Default werden sie. Deswegen muß man seinen Stick auch immer erst
abmelden, bevor man ihn abzieht. Natürlich kann man das auch abschalten.
genau. das geht. In den Einstellungen des Laufwerks (in der
Datenträgerverwaltung -> Richtlinien) hat man die Wahl zwischen
- schnelles Entfernen (Default)
- Bessere Leistung
aber dass Windows sich nicht mal für 0.5 Sek Sektor 0 merken mag? sehr
schräg ..
ich hab das mal eben probiert und die Richtlinie auf "Leistung"
gestellt.
So wird das sogar NOCH mehr amnesialer Traffic.
(hier Windows 7 Pro 64 bit)
RD Adr 0 Cnt 1 Tim 13
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 1 Cnt 1 Tim 97
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 1 Cnt 1 Tim 97
RD Adr 2 Cnt 1 Tim 97
RD Adr 0 Cnt 1 Tim 0
RD Adr 1 Cnt 1 Tim 97
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
RD Adr 1 Cnt 1 Tim 97
RD Adr 0 Cnt 1 Tim 0
RD Adr 1 Cnt 1 Tim 98
RD Adr 2 Cnt 1 Tim 97
RD Adr 3 Cnt 1 Tim 97
RD Adr 4 Cnt 1 Tim 98
RD Adr 5 Cnt 1 Tim 97
RD Adr 6 Cnt 1 Tim 97
RD Adr 7 Cnt 1 Tim 98
RD Adr 8 Cnt 1 Tim 97
RD Adr 9 Cnt 1 Tim 98
RD Adr 10 Cnt 1 Tim 98
RD Adr 11 Cnt 1 Tim 97
RD Adr 12 Cnt 1 Tim 98
RD Adr 13 Cnt 1 Tim 97
RD Adr 14 Cnt 1 Tim 97
RD Adr 15 Cnt 1 Tim 97
RD Adr 16 Cnt 1 Tim 97
RD Adr 0 Cnt 1 Tim 0
RD Adr 0 Cnt 1 Tim 0
(Tim ist die Lesedauer des Dataflash in ms) Sektor 0 nach dem ersten Mal
aus dem RAM
Thomas E. schrieb:> Per Default werden sie. Deswegen muß man seinen Stick auch immer erst> abmelden, bevor man ihn abzieht.
Es ist andersherum; bei Removeable Devices ist das Caching per Default
deaktiviert und deswegen muss man sie üblicherweise nicht abmelden.
Die Mass Storage Layer die ich kenne brechen das immer auf 512 Byte
Sektoren runter. Eventuell liesst er bei Dir jeweils nur 512 Byte - und
damit jeden 4KB Block 8 mal.
Der Lese-Cache im OS ist normalerweise an - sonst wären auch z.B. SD
Karten teilweise schnarchlahm. Schreibcache ist bei Removable Devices
normalerweise aus damit es weniger Probleme beim plötzlichen Abziehen
des Mediums gibt.
das ist so herum richtig.
"schnelles Entfernen" ist der Default.
Ob ich daraus allerdings schliessen würde, dass das "Auswerfen" immer
komplett entbehrlich ist.. halte ich eher für mutig.
Zumindest einen ordentlichen Moment warten sollte man schon.
BinVerwirrt schrieb:> Ob ich daraus allerdings schliessen würde, dass das "Auswerfen" immer> komplett entbehrlich ist
Sieh mal in einem Wörterbuch nach, was "üblicherweise" bedeutet, und
worin es sich von "immer" unterscheidet.
Rufus Τ. F. schrieb:> Es ist andersherum; bei Removeable Devices ist das Caching per Default> deaktiviert und deswegen muss man sie üblicherweise nicht abmelden.
Na, dann ist es eben nicht Default, sondern Standard.
Thomas E. schrieb:> Na, dann ist es eben nicht Default, sondern Standard.
Das ist auch nicht das Standardverhalten.
Was für ein Dateisystem verwendest Du da? Bei NTFS habe ich "Dein"
Verhalten auch schon gesehen, bei FAT aber definitiv nicht. Was für ein
USB-Gerät ist das? Wie sieht dessen Devicedescriptor aus?
(Mein Screenshot zeigt Windows 10 und einen USB-SD-Kartenleser mit einer
2-GB-SD-Karte, die standardkonform mit FAT16 formatiert ist).
"cache.txt" enthält die Informationen, die USBTreeView über das
USB-Gerät ausgibt.
Interessant dürfte hier diese Zeile sein:
Hei.
Wie ganz oben schon gesagt: Es ist ein FAT12 Laufwerk mit
handgestricktem Layout. Bedingt durch die 4 k größen Löschkacheln des
Dataflash habe ich Sektor- und Clustergröße auf 4 k eingestellt. (Alles
halt im Bootsektor passend eingestellt/vorgegeben)
Gesamtgröße ist 2048 Cluster zu je 4096 Byte
Sektor 0 enthält den Bootsektor, sec 1 die FAT (nur 1 Kopie) und sec 2
das Rootdir. Danach kommen direkt die Daten
Vielleicht passt es Windoof auch nicht, dass es nur eine FAT hat und
deshalb wird sie andauernd "zur Sicherheit" nochmal gelesen. Oder die
Lesezugriffe zur zweiten FAT werden zur ersten umgelenkt, statt ganz
abgestellt. Wobei ich dachte, eine FAT sei eigentlich regelkonform.
Ui, danke für den Tip. Bisher war mir nur USBDeView bekannt.
Dieser Tree Viewer sieht überaus schmuck aus!
Bei mir:
Capabilities : 0xD4 (Removable, UniqueID, RawDeviceOK,
SurpriseRemovalOK)
Gibt es eigentlich eine offizielle Vendor-ID für "Bastler". Ich hab hier
einfach 0x1234 genommen und da liegt prompt ein Firmenname dahinter ;))
BinVerwirrt schrieb:> Gibt es eigentlich eine offizielle Vendor-ID für "Bastler".
Nein. Manche Hersteller von USB-fähigen µCs oder USB-Softwarestacks
erlauben die verwendung ihrer Vendor-ID, aber wenn Du es "korrekt"
machen wolltest, müsstest Du Dir selbst eine besorgen.
Ein Beispiel ist das hier, das in v-usb enthalten ist:
https://github.com/obdev/v-usb/blob/master/usbdrv/USB-IDs-for-free.txt
LPC1778
nope. ist closed source.
da es bei kunden keine offiziell beworbene schnittstelle am produkt ist,
will der sich - nachvollziehbar - das Geld vom USB-IF sparen. Ist im
Grunde nur intern für fwupdates.
(intern im wahrsten Sin des Wortes: nur zugänglich innerhalb des
Gehäuses;)
