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:
Beitrag #5225006 wurde von einem Moderator gelöscht.
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.
>>>Bin ich bescheuert oder Windows (USB device driver)?
In der Regel sitzt das Problem vor dem Monitor.
Was willst Du uns eigentlich sagen?
Beitrag #5225397 wurde von einem Moderator gelöscht.
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.
Beitrag #5225429 wurde von einem Moderator gelöscht.
Eventuell werden Zugriffe auf "removable devices" nicht ge-cached?!?
:
Bearbeitet durch User
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.
Ach du liebe Zeit. Auch noch eine gratis Deutsh Beleerung. Danke schöön!
Angehängte Dateien:
-
screenshot.png
14 KB
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.
Angehängte Dateien:
-
cache.png
7,5 KB
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:
1 | Capabilities : 0x94 (Removable, UniqueID, SurpriseRemovalOK) |
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
BinVerwirrt schrieb: > Gibt es eigentlich eine offizielle Vendor-ID für "Bastler". Wenn du Open Soße machst, dann darfst du dir bei http://wiki.openmoko.org/wiki/USB_Product_IDs oder http://pid.codes/ eine holen. Ansonsten verrat uns mal, welchen µC du verwendest.
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;)
BinVerwirrt schrieb: > LPC1778 https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/usb-vid-pid-program:USB-VID-PID-PROGRAM
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.