Erstellungszeit für Datei FAT/NTFS

[oki]

Hallo Leute,

hier mein zweites Problem. Ich habe aktuell meine erste Frage Dateigröße setzen gelöst. Jetzt mein zweites Problem.

Creiere ich ein File auf einer FAT-Partition, so dauert das exorbitant länger als unter NTFS. Imho mit einem Faktor von etwa 400. Hierbei geht es gar nicht um ein kopieren von Daten in ein File, sondern explizit um das Erstellen derselben. Es wird ein CreateFile ausgeführt, danach die Länge mit SetFilePointer gesetzt und ein CloseHandle auf das FileHandle ausgeführt. Bei einer FAT-PArtition dauert dann das CloseHandle je nach Dateigröße sehr lange (1GB ca 30 min.). Bei NTFS ist kein signifikanter Zeitunterschied zu erkennen. Das Erstellen eines Files dauert ca. 3 Sekunden, egal ob diese Datei 1 kB oder 1GB groß ist. Kann mir jemand erklären, warum das so ist und ob es eine Möglichkeit gibt das unter FAT zu beschleunigen? Das kopieren von Dateine auf einen FAT-Datenträger dauert übriegens genauso exorbitant lange. Das zu beschleunigen währe natürlich auch hilfreich.

Schon mal Dank und Gruß

oki

[Neutral General]

Hi,

Ich denke da wirst du nichts tun können. Das Erstellen der Datei wird vom Dateisystem-Treiber von Windows erledigt. Wenn der zu langsam ist, bzw FAT aufgrund seiner Struktur kein schnelleres Erstellen/Kopieren zulässt, dann hast du denke ich mal Pech gehabt

Edit: Wobei es auch darauf ankommt wie voll und fragmentiert die Partition ist auf der du die Datei anlegen willst. Das spielt gerade bei großen Dateien (1GB z.B.) eine große Rolle und wird je nachdem ne Menge Zeit rauben!

Gruß
Neutral General

[oki]

Hallo Neutral General,

ja, dass mit der Fragmentierung ist natürlich ein Faktor der berücksichtigt werden muss. Mir geht es natürlich um das grundsätzliche Thema. Leider ist es so, dass der Vorgang grundsätzlich auch bei geringer Fragmentierung zu lange dauert. In wie weit könnte zum beispiel die Einstellung Sektorgröße bei der Formatierung Einfluß auf die Geschwindigkeit haben?

Gruß oki

[p80286]

Hallo Oki,

Du meinst wahrscheilich die Clustergröße, da die Sektorgröße von der Hardware vorgegeben wird. Theoretisch wird die Datenverwaltung unter FAT um so schneller je größer die Cluster werden, da immer nur ein Cluster verwaltet wird.
Allerdings wird auch der "Verschnitt" größer, wenn die Clustergröße ansteigt.


Warum interessiert Dich das? Willst Du hardwarenah programmieren?
Im allgemeinen versucht ein Anwendungsprogrammierer nur die programminternen Schreib und Lesevorgängezu optimieren. Ob das genutzte Speichermedium nun ein USB-Stick, eine RAM-Disk, eine Fest oder Wechsel-Platte oder was auch immer ist sollte und dürfte ihn nicht interessieren.

Gruß
K-H

[Neutral General]

Zitat von p80286:

Allerdings wird auch der "Verschnitt" größer, wenn die Clustergröße ansteigt.

@oki: "Verschnitt" bedeutet in diesem Fall: Wenn du eine Clustergröße von 2048 Bytes hast, dann belegt eine Datei die 1 Byte groß ist auf dem Dateisystem trotzdem effektiv 2 KiB, eine 2050 Byte Große Datei belegt 4 KiB.

[himitsu]

Wenn du die Datei erstellst und via SetEndOfFile vergrößerst, dann wird sie erstmal mit 0 gefüllt.
Es kommt also in diesem Fall eigentlich besser du füllst die Datei direkt und weist ihr nicht vorher die Größe zu.

Du könntest jetzt, wenn die Datei garantiert nicht komprimiert wird (dieses legt ja Windows anhand des Ordners fest ... ist dieser komprimiert, dann wird die Datei auch),
dann könntest du die physische Größe der Datei festlegen, dann wird sie nicht mit 0 gefüllt und es geht ratsfatz (mehr siehe msdn, denn da muß man Einiges beachten).

Ansonsten würde ich die eine Sparsefile emfpehlen, da werden dann die Sparcebereiche nicht physisch auf dem Datenträger erstellt, aber sie hat virtuell dennoch die gewünschte Größe.
Die Sparcebereiche werden dann erst beim Speichern angelegt.
(gilt aber nur für NTFS)


Wäre jetzt nur die Frage, warum willst du unbedingt die Größe vorher festlegen?
Also bevor da überhaupt Daten drinnen sind.



NTFS hat 'ne andere Cache-/Speicherverwaltung, so aß es dort oftmals so aussieht, als wäre dieses schneller, aber im Endefekt ist es zu großen Teilen langsamer, als FAT.
Also bis wirklich alle Daten gespeichert/geändert sind.

[p80286]

Zitat von himitsu:

Wäre jetzt nur die Frage, warum willst du unbedingt die Größe vorher festlegen?
Also bevor da überhaupt Daten drinnen sind.

Das ist Die Frage aller Fragen!

Irgendwann in grauen DOS-Zeiten, war das mal die Möglichkeit festzustellen wieviel Platz wirklich auf einem Datenträger zur Verfügung stand. Ebenso hat man versucht auf /370-Datenträgern sich Platz zu reservieren. Aber die gleiche Strategie bei einem "modernen" FAT-Laufwerk??

Gruß
K-H

[oki]

Moin himitzu, p80286,

soory, leider darf ich die Frage "Warum willst du unbedingt die Größe vorher festlegen?" nicht ohne Rückfrage beantworten. Tut mir wirklich leid, normal mag ich es nicht wenn man hier Infos zurück hält. Leider ist es in diesem Fall aber nun mal so; kann ich nichts dran ändern. Zum Glück ist es aber nicht weiter relevant warum das so sein soll. Entscheidend ist, dass ich eine Datei mit einer vordefinierten Größe anlegen muss, in die erst successive Daten bei der späteren Nutzung geschrieben werden sollen. Natürlich ist somit auch der benötigte Speicher sozusagen reserviert. Diese Datei wird vorrangig auf einem USB-Stick angelegt. Üblicher weise sind USB-Sticks FAT formatiert. Natürlich kann man diese auf NTFS umformatieren, tut der normale DAU aber eher selten. Negativ für FAT ist natürlich, dass Dateien größer 4GB nicht erstellt werden können und konkret das Geschwindigkeitsproblem.

@ p80286: Ja, soory ich meine natürlich die Clustergröße.

@himitzu: Kannst du mir hierzu:

Zitat:

Du könntest jetzt, wenn die Datei garantiert nicht komprimiert wird (dieses legt ja Windows anhand des Ordners fest ... ist dieser komprimiert, dann wird die Datei auch),
dann könntest du die physische Größe der Datei festlegen, dann wird sie nicht mit 0 gefüllt und es geht ratsfatz (mehr siehe msdn, denn da muß man Einiges beachten).

einige Hinweise oder Stickworte geben? Da würd ich gern mal rein schauen.
Auch wenn dir die Frage blöd erscheint, was sind Sparcefiles?

Dank Euch und Gruß oki

[himitsu]

SetEndOfFile

SetEndOfFile

To set the logical end of a file, use the SetFileValidData function.

ABER

SetFileValidData

Warning Use of this function without proper security considerations may compromise data privacy and security.

[oki]

Joop, danke für den Hinweis. Ich werd mir das mal reinziehen.

Gruß oki