Festplattenzugriffe

[himitsu]

Es war eine von den ersten 10 :roll:

Welche Seite es war weiß ich nicht mehr genau, vorallem da ich dort über andere Suchbegriffe hingekommen bin ('s wär jetzt ä bissl viel mir nochmal alle anzusehen, nur um die Eine wiederzufinden)

War mehr als Beispiel ... ich denke mal ganz einfach, daß es darunter massenhaft Seiten gibt, wo die beiden Funktionen auch zusammen verwendet werden :angel2:

(wenn ich Glück hab, liegt noch eine Kopie der Seite daheim im Papierkorb)

[himitsu]

Ähhh ja ... gefunden hatt'sch nichts mehr.
Und Google spuckt irgendwie ständig was anderes aus, nur nicht die Seite mit dem Code. :gruebel:

Zitat:

Zitat von #41

ReadDirectoryChangesW fails with ERROR_INVALID_PARAMETER when the buffer length is greater
than 64 KB and the application is monitoring a directory over the network. This is due to a packet size
limitation with the underlying file sharing protocols.

Was das angeht, dann wird ja in jedem Code (welchen ich so sah) die 64 KB verwendet, auch wenn sie bei weitem nicht ausgenutzt werden.
Nach meinen Beobachtungen sind wohl 2*SizeOf(FILE_NOTIFY_INFORMATION) [1064 Bytes], also schöne 2 KB völlig ausreichend.

[size=1]PS: 64 KB = Windows-Speicherseite[/size]


FILE_NOTIFY_CHANGE_LAST_ACCESS:
Hierzu nur 'ne Empfhelung, da dieses oftmal in den Codes da oben auftaucht.
Wählt die zu überwachenden Ereignisse mit bedacht,
denn wenn man Dateiänderungen überwachen möchte, dann ist der Lesezugriff irgendeines Programmes uninteressant. :zwinker:


@Luckie, zwecks "Zugriff verweigert" #23:
ich löse das inzwischen so, daß der Überwachungsthread seine Ereignisse nur in ein Array einträgt (incl. Zeit) und erst dann zeitversetzt in einem anderem Thread ausgewertet wird.


Für Langzeitüberwachungen (ohne sofortige Auswertung) sollte es sich über Change Journals besser lösen lassen, vorallem da hierbei kein Überwachungsprogramm die ganze Zeit mitlaufen muß.
> Change Journals, READ_USN_JOURNAL_DATA



Was diese süße "12-Byte"-Temp-Variable (FNI) angeht, welche hier oftmals verwendet wird ...
wie wäre es, wenn man einfach nur nach PFileNotifiInformation castet? :zwinker:
z.B.: PFileNotifiInformation(P)^.Action

[OldGrumpy]

Zitat:

Zitat von himitsu

Ähhh ja ... gefunden hatt'sch nichts mehr.
Und Google spuckt irgendwie ständig was anderes aus, nur nicht die Seite mit dem Code. :gruebel:

[size=1]PS: 64 KB = Windows-Speicherseite[/size]

Nope, ne Speicherseite ist praktisch immer vier KiB gross, was Du meinst ist die minimale Datenmenge die ein Lese-/Schreibzugriff transportiert. Egal ob Du nur ein Byte anforderst oder 64 KiB, Windows schaufelt immer 64 KiB rum. Das merkt man ganz enorm wenn man viele kleine Files (bis inkl. vier KiB) in ein Verzeichnis kopiert, diese Files werden bei NTFS direkt in der MFT abgelegt. Für jeden Zugriff werden dann mehrfach 16x soviel Daten bewegt wie notwendig, und das erhöht den Overhead im Vergleich zu großen Files noch zusätzlich zum restlichen Verwaltungsoverhead drastisch, da nach jedem Schreibzugriff 64 KiB statt vier geflushed werden müssen, da es sich um überlappende Zugriffe handelt. (Den Journal-Overhead brauche ich nicht erst zu erwähnen ;))

[himitsu]

Na ja, Windows verwaltet ja "praktischer" Weise (aus seiner Sicht) den Speicher in 64-KB-Blöcken.

Und da die netten Lese-/Schreibzugriff immer Blockweise durchgeführt werden, ist es nunmal besser sich gleich an diesen Blockgrößen auszurichten.
Und da es ja mehrere Speicher/Zwischenspeicher gibt, welche zusammen arbeiten (hintereinander liegen),
ist es wohl besser sich an den größten Speicherblock zu halten.


Und hab bei mir derzeit 'ne durchschnittliche Blockgröße von maximal 512 KB (min. 128 KB) ausfindig bemacht.

Daten auslesen/ändern auf NTFS und FAT32.


Ist halt ein Wert, welcher wo es durchschnittlich am Schnellsten ging.


PS: das NTFS nicht gerade schnell ist, war mir leider schon bewußt -.-''


[add]
Im Grunde wollte ich ja nur sagen, daß es einfach (im Durchschnitt) besser ist, wenn man sich möglichst am größten Speicherbereich, welcher von an verschiedensten Stellen herumgeschoben wird orientiert, wenn man seinen eigenen Zwischenspeicher dimensioniert.

Sektorgröße, Clustergröße, Festplattencache, WindowsFileCache...

Wobei es da schon genug leicht auszulesende Größen gibt und nicht unbedingt alles ermittelt werden muß.


(Wie NTFS intern funktioniert hab ich noch nicht durch ... hänge derzeit noch an FAT ._.)