Des Platzes auf NTFS-Datenträger nach einer Reihe von gleich großen Dateien erstellen / löschen

Question

Ich habe läuft in ein wirklich seltsam Problem, während an einem großen Projekt arbeiten. Ich schreibe eine Reihe von same-size Dateien auf einer Partition (versucht, beide RAM-Disks und virtuelle Laufwerke über diskmgmt.msc erstellt). Wenn es nicht genügend freier Speicherplatz vorhanden ist, eine andere Datei zu passen (wie durch GetDiskFreeSpaceExW berichtete), lösche ich eine (nur eine) von der erzeugten diejenigen vorher und das neue schreiben. Dann lösche ich eine andere alte Datei und einen neuen schreiben, ad infinitum (ja, können Sie von der Partition denken als ein Ringpuffer von gleich großen Dateien). Nach einer Reihe von Schreib-Löschungen (von einigen hundert bis einigen tausend), betreibe ich in einen no free space Fehler während eine neue Datei zu schreiben (vor dem, GetDiskFreeSpaceExW berichtet genügend Platz). Ich fragte ein paar Kollegen von mir zu versuchen, das Problem auf ihrer Hardware zu reproduzieren, aber das Problem hat nicht wieder auftauchen.

Um die Dinge ein wenig zu klären, hier ist der genaue Algorithmus:

1. Wählen Sie die Dateigröße (zum Beispiel S-Bytes)
2. Überprüfen Sie freien Speicherplatz mit GetDiskFreeSpaceExW
3. Wenn free_space> S: Schreib neue Datei der Größe S und geht zu 2
4. Else: Löschen einer Datei und gehe zu 2

Es ist wichtig zu beachten Sie, dass ich Daten in Dateien in Blöcken der Größe 4096 Byte schreiben (Problem wieder auftauchen kann oder nicht in Abhängigkeit von der Blockgröße). Dateigröße ist 5 MB. NTFS-Partition Größe ist 21 MiB. Clustergröße ist 512 B (wiederum diese Parameter ändern, wirkt sich die Ergebnisse). Mit diesen Parametern tritt der Fehler bei der Erstellung der 684'th Datei. Es ist nicht davon abhängig, ob ich einen RAM-Disk oder eine virtuelle Festplatte verwenden (daher ist es kein Problem einer bestimmten Implementierung ist).

Ich analysierte den resultierenden Disk-Image-Dumps nach dem Scheitern und festgestellt, dass die gesuchten Dateien stark fragmentiert wurden. CHKDSK meldet keine Probleme weder vor noch nach dem Experiment. Es wurden keine Fehler in den Systemprotokollen gefunden.

Möglicherweise relevante Parameter von meinem Netbook (Dell Inspiron 1110):

• Pentium SU4100, relativ langsamer Dual-Core-x64 CULV CPU (1,3 GHz)
• Windows 7 Ultimate x64 Edition
• 2 GB RAM

hat jemand eine Idee über, was los ist und wie es zu debuggen? Wo kann ich zusätzliche Informationen aus? Ich bin schon von Ideen aus, und ich brauche dieses Problem zu lösen, so schnell wie möglich ...

UPD: das Problem tritt auf, wenn ich Dateidaten Ich schreibe (d write() ausfällt), nicht , wenn ich erstellen Sie die Datei. So sieht es nicht wie ich MFT Einträge bin fehlt.

UPD2: ein paar der Fragen zu beantworten, die gestellt wurden

• Die Partition ist ein frisch formatierte man daher keine spezifischen Attribute auf Dateien, ohne Verzeichnisstruktur, nichts
• Berechtigungen sind Standard
• Keine .lnk der keine Hardlinks - _only_ die Dateien, die ich schreiben
• Alle Dateien in das Stammverzeichnis geschrieben werden, werden keine weiteren Verzeichnisse erstellt
• Die Dateinamen sind einfach die Ordnungszahlen von Dateien (d 1, 2, 3, ...)
• Keine alternativen Datenströme, Dateien verwenden erstellt `fopen ()`, geschrieben mit `fwrite ()` und geschlossen mit `fclose ()`
• $ Txf wird erstellt, in der Tat
• Keine fehlerhafte Cluster, ist dies eine virtuelle (oder ein RAM) Festplatte

Answer 1

Gute NTFS Frage und nicht alle Informationen hier. Was ist die directoriy Struktur ?. Gibt es LINK-Dateien auf das? Verwenden Sie die Komprimierung auf dem Laufwerk? Volumeschattenkopien?

Sie laufen nicht von MFT Raum aus, da es eine konstante Anzahl der Dateien / Verzeichnisse ist. Das bedeutet, dass die MFT ist statisch. Auch wird der MFT Reserveraum in Nieder Speicherplatz Szenarien ued werden. Ich habe jeden Cluster auf einem NTFS-Volume verwendet werden.

Es gibt mehrere Erklärungen, was geschieht:

1) Die $ Log-Datei gewachsen sein könnte. Dies ist ein Roll-Back-Protokoll.

2) Die @SII-Datei für die Sicherheitsdaten für Datei gewachsen sein könnte, wenn es nicht einheitliche Berechtigungen auf dem Laufwerk sind

3) Wenn einige der Dateien auf der Volme bereits LNK / Verknüpfungsdateien mit Verweise auf sich, das System legt eine GUID für jedes Ziel in einen Index. (Sie LNK-Dateien erhalten, wenn Sie auf eine Datei im Explorer klicken 2x - in den letzten Dokumente)

4) die Verzeichnisstruktur ist nicht statisch (oder die Dateinamen sind in der Länge nicht einheitlich) der $ index Puffer von Verzeichnissen können in der Größe wachsen.

5) Wenn Sie ein Systemvolumen directroy auf diesem Laufwerk haben, können Sie Volumeschattenkopien und Othe OS-spezifische Daten haben.

6) Alternate Data Streams sind nicht in der Größe der Datei angezeigt. Sind da irgendwelche?

7) TxF -. Unter Vista und höher könnte es eine Transaktionsschicht sein, die variable Raum einnimmt

8) Bad Cluster? Cluster kann schlecht gehen (aber chkdsk könnte dies beachten ..)

9) Die Dateien fragmentiert und die Liste der Fragmente alson mit den anderen Meta-Daten ist zu groß, um in einen MFT-Datensatz zu passen (unwahrscheinlich Nince Ihrer Dateien sind klein und Sie haben nicht massiv lange Dateien)

10) Die Verwendung von Hardlinks auch mehr Daten auf dem Laufwerk setzt.

Ich habe alle diese als Referenz für andere Menschen aufgelistet!

Abschließender Hinweis - manchmal können Sie erstellen und eine kleine Datei schreiben, auch wenn es 0 Bytes frei, da NTFS-resident-Dateien nur einen MFT-Datensatz aufnehmen (sie Resue eine freien gelöscht)

Answer 2

Die FS hat einen eigenen Aufwand, die Sie berücksichtigen nicht. Das Overhead ist nicht konstant, so durch das Löschen / Schreiben von Dateien, die Sie Fragmentierungs verursachen können. Mit anderen Worten: „5 MB freien Speicherplatz“ bedeuten nicht, Sie 5MB auf die Festplatte schreiben können.

Answer 3

Ihre Implementierung Unter der Annahme korrekt ist und Ihre Kollegen in der Lage, das Problem zu reproduzieren, könnte es sein, dass Ihr MFT läuft Raum aus.

  

In der Standardeinstellung Windows XP Reserven 12,5 Prozent jeden NTFS-Volume (ein Bereich namens die MFT-Zone) für   exklusive Nutzung des MFT. Also, wenn Sie   Plan zum Speichern Tonnen von kleinen Dateien   (Unter 8K, sagen) auf dem Volumen, Ihre   MFT kann dem Raum laufen, bevor Ihr   freien Speicherplatz Volumen der Fall ist, und die   Ergebnis wird sein, MFT-Fragmentierung.

Technet

  

Als erstes wird der MFT auch nicht schrumpfen, wenn Sie Dateien und Verzeichnisse löschen   aus dem Volumen; stattdessen die MFT   Markierungen die FRS reflektieren die   Streichung. Zweitens NTFS speichert sehr   kleine Dateien innerhalb der MFT FRS, dass   beziehen sich auf die Dateien. Obwohl dieses   Setup bietet einen Leistungsvorteil   für diese Dateien, kann es die MFT verursacht   übermäßig zu wachsen, wenn das Volumen   viele solche Dateien enthält.

Answer 4

Es ist zwar nicht schrecklich ist überraschend, dass das Deaktivieren TXF diese haben feste würde (TXF ist nur eine Komponente der Systemdatei auf dem Datenträger mit Leerzeichen), gibt es zwei Dinge zu beachten. Die erste, und mehr von Nebenbei bemerkt, ist wirklich, dass Sie es zu deaktivieren, vorsichtig sein möchten. (Andere Komponenten davon abhängen können,. Windows Update ist eine solche Komponente, obwohl es sollte nur über die Systemlautstärke kümmern)

Die andere Sache zu prüfen ist, dass dies in der Regel ist und praktisch ein fragiles Muster. Das Dateisystem hat einige Annahmen über das, was sie konsumieren können. Indizes, zum Beispiel, wird (in vorgegebenen Schritten, Änderungen vorbehalten) wachsen, und sie können in einer Weise, nicht schrumpfen, dass Sie vorhersehbar finden. Darüber hinaus ist die Sicherheitsbeschreibung Index wahrscheinlich weiter wachsen.

Die andere Anmerkung oben über die Schattenkopien ist etwas immer im Auge zu behalten.

FWIW die $ Log-Datei wird nicht automatisch wachsen.