Um Speicherplatz zu sparen, dachte ich, es wäre vielleicht eine gute Idee, den installierten VMware vSphere-Client zu komprimieren, da ich ihn fast nie verwende.
Ich war überrascht, dass es genau den gegenteiligen Effekt auf den freien Speicherplatz hatte. Ich habe es weiter verfolgt und festgestellt, dass es mit der Komprimierung des HelpOrdners zusammenhängt. Der Verlust an Speicherplatz wirkt sich nicht auf die Ordnergröße aus.
Ich habe den Komprimierungs-/Dekomprimierungszyklus dreimal wiederholt, um sicherzustellen, dass nicht versehentlich ein anderes Programm den Speicherplatz belegt. Es fällt auf, dass der Ordner eine große Anzahl kleiner Dateien enthält (≈ 30 KB).
Warum ist das so und kann ich irgendwie andere Ordner finden, die ich solltedekomprimierenum Speicherplatz zu sparen?
Ohne Komprimierung:
Mit Komprimierung:
Antwort1
Ein wenig Hintergrundwissen zu den Screenshots zur Ordnergröße, die Sie bereitgestellt haben:
Unkomprimiert
Wie bei vielen kleinen Dateien zu erwarten, entsteht ein großer Overhead. Ihre Festplatte ist mit einer bestimmten Blockgröße partitioniert – standardmäßig 4 KB für NTFS.
Jede Datei muss ein Vielfaches von 4 KB belegen, d. h. egal, ob Sie eine 1 KB oder eine 3,5 KB große Datei haben, beide benötigen 4 KB Speicherplatz. Wenn Sie eine 13 KB große Datei haben, benötigt sie 16 KB auf Ihrem Laufwerk. Der Unterschied zwischen „Größe“ und „Größe auf der Festplatte“ ist der Overhead, der durch ungenutzten Speicherplatz in Blöcken entsteht, die so genannteCluster-Tipps.
Komprimiert
Nach der Komprimierung ist die „Größe“ immer noch dieselbe, da sich die Nettodatenmenge überhaupt nicht geändert hat. Durch die Komprimierung konnte die Gesamtgröße jedoch um etwa 130 MB reduziert werden. Eigentlich sogar noch mehr, da hier auch der Overhead anfällt.Durch die Komprimierung wurde in diesem Ordner also tatsächlich etwas Platz gespart, was sich auch in der Ordnergröße widerspiegelt.
Nun zum Verhalten, das Sie mit dem reduzierten freien Speicherplatz auf Laufwerk C sehen: Dies kann mehrere Gründe haben. Man muss verstehen, dass der freie Speicherplatz immer kleiner ist als
<Disk size> - <total size of all files>
Dies liegt daran, dass viele Metadaten vorhanden sind, die ebenfalls Speicherplatz beanspruchen (VSS-Snapshots, Systemwiederherstellungspunkte, MFT usw.).
Beim Komprimieren einzelner Dateien behält NTFS die Originaldatei vorübergehend bei, bis die Komprimierung abgeschlossen ist. Dies soll sicherstellen, dass Sie im Falle eines Computerabsturzes immer noch eine gültige Version der Datei haben. Dies sollte jedoch nur vorübergehend sein. Trotzdem deutet alles auf NTFS-Metadaten hin, die dies verursachen.
Um die Ergebnisse genauer zu überprüfen, können Sie Folgendes tun:
- Beginnen Sie mit einem unkomprimierten Ordner
- Deaktivieren Sie den Systemschutz für jedes Volume (Computereigenschaften/Systemschutz).
- Löschen Sie die Wiederherstellungspunkte für jedes Volume im selben Dialog
- Verwenden Sie "Datenträgerbereinigung" in den Eigenschaften Ihres Datenträgers C:, um temporäre Dateien zu entfernen
- Beachten Sie den freien Speicherplatz
- Komprimieren Sie den Ordner
- Starte deinen Computer neu
- Verwenden Sie die Datenträgerbereinigung erneut
- Überprüfen Sie den freien Speicherplatz auf Ihrer Festplatte
Theoretisch sollten Sie eine Zunahme des freien Speicherplatzes feststellen können
Antwort2
Nachdem ich kürzlich ein ähnliches Problem untersucht habe, kann ich auch sagen, dass eine komprimierte Datei mindestens 4 Kilobyte Speicherplatz pro Datei und 64 Kilobyte temporären Speicherplatz benötigt, was der Größe einer „Komprimierungseinheit“ für NTFS mit 4 KB Clustergröße entspricht.Der Artikel auf blogs.msdn.comerwähnt auch, dass beim Komprimieren der Datei der Speicherplatz für eine volle CU zugewiesen und zu einem unbestimmten Zeitpunkt freigegeben wird. Dies sollte der Grund dafür sein, warum Sie 5 GB verlieren, wenn auch nur vorübergehend (ein Neustart sollte diesen Verlust definitiv beheben, andere Mittel sollten das auch tun, aber keine Defragmentierung – habe es versucht und es ist fehlgeschlagen). Anscheinend scheint der zugewiesene Speicherplatz viel größer zu sein (64 KB * (31048 + 582) = 2072903680 oder 1,93 GB), aber das ist erklärbar, da NTFS Transaktionen hat, die Zeit und Prozessoreinheiten benötigen, um in Rohdaten umgewandelt zu werden, und wenn dieser Prozess abgeschlossen ist, erhalten Sie alle 5 GB plus 150 MB Speicherplatz, die durch die Komprimierung freigegeben wurden, zurück.
Zusammenfassend lässt sich sagen, dass Sie nur vorübergehend Speicherplatz verlieren, wenn Sie eine große Menge an Dateien komprimieren. Wenn diese Dateien jedoch häufig geändert werden, wird Ihr Speicherplatz für die Speicherung unkomprimierter Daten für diese Dateien reserviert, falls der geänderte Inhalt nicht komprimiert werden kann, um in den Speicherplatz zu passen, den der Cluster vor dem Schreibvorgang belegt hat.
Antwort3
Ich hatte die gleichen Phänomene:
Servermigration: Ich habe die Datenordner eines Laufwerks des alten Windows Server 2012R2 (mit 2 komprimierten Ordnern) auf ein neueres Windows Server 2016 Datacenter-Laufwerk gleicher Größe kopiert, wo ich vor dem Kopiervorgang die Ordnerstruktur erstellt und die Komprimierungsflags für diese beiden Ordner gesetzt habe. Während des Kopierens ging mir der Speicherplatz aus, und überall, wo ich nachgesehen habe, werden nur 3 GB von 20 GB verwendet, aber das Laufwerk selbst zeigt mir an, dass 19,x GB verwendet werden. Ein Kollege sagte mir, ich solle das Komprimierungsflag entfernen, und wie durch ein Wunder tauchten die verlorenen 17 GB wieder auf.
Dann habe ich Ihren Artikel gelesen und beschlossen, das Flag erneut anzuwenden und einen Neustart zu versuchen, aber komischerweise hat sich der belegte Speicherplatz dieses Mal nicht erhöht.
Ich vermute, dass es in Windows Server 2016 (vielleicht schon immer) ein Problem geben könnte, dass intern generierte temporäre Dateien nicht richtig bereinigt werden, wenn Dateien in einen komprimierten Ordner kopiert werden (im Gegensatz zu wenn das Komprimierungsflag auf bereits vorhandene Dateien angewendet wird).
Antwort4
Ergänzung: Zusätzlich zu den obigen Erläuterungen kann ein Anwendungsordner Dateien enthalten, die sich einfach nicht gut komprimieren lassen - bereits stark datenreduzierte Medienformate (JPEG-Bilder, Videodateien, MP3-Audio ...), bereits komprimierte Dateien (viele Datenformate sind heutzutage als ZIP-Archive aufgebaut!), Dateien mit tatsächlich zufälligen Daten oder etwas, das zufälligen Daten ähnelt, verschlüsselte Dateien - dies kann dazu führen, dass für die Verbuchung des Komprimierten mehr Daten verwendet werden, als durch die Komprimierung eingespart wurden ...