XP Kompressionsschwäche?

Hallo!

Laufwerke komprimiere ich eigentlich ungern, aber als Backuplager mag es mal so sein.

Da habe ich die komprimierte alte Platte um das auf eine größere ›neue‹ umzuschichten. Die Zielpartition (120GB) sollte komprimiert sein, das Häkchen stand auf Komprimieren. Die Quelle, 80GB und mit weiteren Sicherungen belegt, scheint beim Umräumen allein der betreffenden Daten aufzugehen wie ein Hefeteig oder eher noch Bauschaum…

Warum wird das nicht komprimiert?
Unverständlicherweise sind aber 2 Ordner dem Blau nach sehr wohl komprimiert.

Also Ungeschrumpftes Löschen und mit XCOPY rüberräumen. Wieder wird nicht komprimiert, trotz Häkchen! Nun denn, per Explorer komprimierte Quellen viel langsamer herüberwuchten - und siehe da, von den 120GB sind plötzlich nur <70 belegt.

Was ist da beim Komprimieren schiefgelaufen? Kompressionsverluste im Motor sind zwar viel lästiger, aber was hier passiert ist ist mir ein Rätsel.
Denn mit XCOPY habe ich diese Backups gefüllt, wenn auch von einem naturgemäß komprimierten Novell-Filesystem aus, doch kann das Ursache sein? Ich kann da nur mit den Schultern zucken.

CN8


PS… Wie sinnfälllig wäre es eine SSD [Win 8] zu komprimieren? Entkomprimieren im System-RAM geht angeblich recht schnell. Vermutlich ist da bei der Systemplatte nicht so der Brüller, aber bei einer Daten-SSD? Oder sogar doch auch die System-SSD?
Unter der Prämisse, dass SSDs ja immer noch als klein gelten wunderts mich, nichts über Komprimieren zu lesen - weder im Positiven noch im Negativen.

Das Komprimieren macht generell keinen Sinn. Speicherplatz ist ziemlich günstig, die Kompression von NTFS ist eher "gering", ansonsten benötigt es zu viel Rechenleistung, die Daten müssen immer über den Prozessor, was langsam ist und zum Schluss lassen sich viele moderne Daten (Filme, Musik, ...) eh nicht mehr weiter komprimieren.

nichts über Komprimieren zu lesen - weder im Positiven noch im Negativen.

Zum Vergrößern anklicken....

macht auch kaum noch jemand...

When you copy or move a compressed NTFS file to a different folder, NTFS decompresses the file, copies or moves the file to the new location, and then recompresses the file. This behavior occurs even when the file is copied or moved between folders on the same computer. Compressed files are also expanded before copying over the network, so NTFS compression does not save network bandwidth.

Zum Vergrößern anklicken....

MS KB 251186

Daher kann es auch sein das Robocopy zwar Compressed Files liest aber sie nicht schreibt...

Ich komprimiere…

…weil das ältere Platten (id est: klein) sind und auch nur gewisse Datenvolumina gesammelt werden. Das ist eine kumulierende Sicherung → daher auch simples XCOPY und nicht ROBOCOPY (und wenn ich nicht falsch liege wird ein weiteres komprimiertes Laufwerk leider auch nicht mit RoboCopy bedient, was mir einen Vergleich ermöglichen würde).

Zeit habe ich, das wäre ebenfalls nicht das Problem. Und was ich da komprimiere, das sind i.d.R. wenige Multimediadateien, wenn man von einem Haufen GIFs absieht die schön klein sind. Videos einzudampfen, ist klar, das taugt nicht und ist auch nicht Sinn der Übung (selbst wenn ich von denen einige kleine einwecken muss).

Die MS-Seite erklärt nicht warum ROBOCOPY nicht komprimierend schreibe sollte - oder eher übernimmt doch nur das Dateisystem die geschaufelten Daten und verwaltet sie entsprechend..?!?
Serverbandbreite ist insofern ebenfalls nicht zu bedenken - NetWare komprimiert und damit muss man halt leben. Wäre tatsächlich interessant man zu sehen was das 100er LAN schafft wenn es unkomprimierte Daten wären. Könnte einen Aha-Effekt bringen oder nach hinten losgehen (Nebenher - der wenig beschäftigte alte Server bedient eine 8GB-Spiegelung, der neue hat unfassliche 80GB zur Verfügung - als nichts was wirklich unter ›groß‹ und ›viel‹ gebucht werden müsste.)

Was mich gewundert hat ist, dass tatsächlich nicht über Kommandozeile komprimiert wurde, ich aber schon einige Jahre mittels derselben die alte Platte gefüllt. Das wars was mir mysteriös erscheint.


Selbst wenn «es keiner macht» - warum wäre es verfehlt eine »kleine« SDD durch Kompression aufzuwerten? Bremst das Entpacken zu sehr? Dürfte ja wohl jemand probiert haben? Ein… 1GHZ? Rechenr mit 8GB Platte (bei meine ich 768RAM) und komprimiertem XP war allerdings eine arge Schlaftablette.

CN8

Das entpacken bremst "enorm". Normaler Datentransfer läuft seit etwa 1990 über den Chipsatz und umgeht den Prozessor (DMA). Sind die Daten verschlüsselt, komprimiert etc. muss der Prozessor für jedes Bit/Byte die jeweiligen Operationen durchführen. Das erhöht die Rechenleistung und vermutlich insbesondere die Zugriffszeit. Erwägt man diese Nachteile sind die Vorteile kaum vorhanden. Die Komprimierung ist "winzig". Speicherst du primär Textdateien und ähnliches ist sie durchaus relevant, aber das kommt in der Realität wohl nicht so vor.

Unfug, einfach mal selber ausprobieren. Wie bei fast jedem Kompressionsalgorithmus sind für die Kompresion deutlich mehr Resourcen erforderlich, das dekomprimieren erfolgt recht Resourcenschonend.

Kurztest mit 5GB Ramdisk und h2testw (heise.de)
schreiben (mit Kompression) 51 MB/s
lesen (mit Kompression) 674 MB/s
schreiben (ohne Kompression) 753 MB/s
lesen (ohne Kompression) 671 MB/s


SSD
schreiben (mit Kompression) 42 MB/s
lesen (mit Kompression) 677 MB/s (vermutlich Plattencache)
schreiben (ohne Kompression) 141 MB/s
lesen (ohne Kompression) 148 MB/s

Zum Vergrößern anklicken....

Was auffällig ist, das die Kompression wohl eine Deckelung im Algorithmus hat, vermutlich soll die CPU Last begrenzt werden. Bei aktuellen CPUs IMO ziemlich sinnfrei, da ich bei einem 6Core nur 10% Last bei Minimaltakt habe.
Während des schreibens werden maximal 2 Kerne zwischen 30-50% belastet. Inwieweit das eventuell mit dem speziellen Streamkompressionsmodus zusammenhängt (kein Mutlicoresupport?) entzieht sich meiner Kentniss. Ebenso kann ich nicht sagen warum der Plattencache von Win7 die SSD ohne Kompression ignoriert, muß wohl eine "Optimierung" sein.

Ich sehe meine Aussagen nicht widerlegt, 750 MB/s vs 51MB/s selbst bei direkten RAM-Zugriff ist schon ein enormer Unterschied, die 80 MB/s Differenz beim Lesezugriff sind auch nicht unrelevant. Es verändert außerdem die Zugriffszeiten auf dem Datenträger selber.

OK, Kompression von Sicherungen geht I.O., aber das des Betriebssystems selbst auf SSD ist nicht ernsthaft durchschlagend.

Warum aber in ein auf Kompression gestelltes (..!) LW unkomprimiert kopiert wurde wurmt mich immer noch.

CN8

Die Schreibrate (Kompression) mit der Leserate (Dekompression) zu vergleichen ist schon etwas "seltsam", oder? Auf genau diese Asymmetrie im Resourcenverbrauch hatte ich doch bereits hingewiesen.

andy_0 schrieb:

Das entpacken bremst "enorm".

Zum Vergrößern anklicken....

Es ging mir nur um diese Aussage, die IMO falsch ist. Das die CPU den Flaschenhals darstellt dürfte in den meisten Fällen nicht zutreffend sein.
Wenn es dich beruhigt , ich stimme dir zu das die Kompression des kompletten Systemlaufwerks kaum sinnvoll ist. Hier finden zu oft Schreibzugriffe statt, die das System enorm bremsen würden. Mann kann aber gezielt einzelne Ordner komprimieren, wenn es sinnvoll ist.

@cumulonimbus8
Woher sollte das System den wissen was du mit dem kopieren erreichen wolltest? Es könnte ja auch sein das du eine dekomprimieren wolltest.
AFAIK gibt es für den (x)copy Befehl keinen Schalter um das "Attribut: Komprimiert" mit zu kopieren. Also wird die Vorgabe des Zielordners übernommen.
Zum Beispiel für verschlüsselte Dateien gibt es einen solchen Schalter. Warum, das weiß nur Microsoft.

Nanu?!?
Das Dateisystem weiß (sollte es nach dem Häkchen wissen…), dass es auf Komprimieren\Komprimiert steht.

Wenn man also Daten dahin schreibt ist nach aller Vernunft zu erwarten, dass diese komprimiert werden (unabhängig davon welche Erfolgsrate das am Schluss hat). Entnommene Daten müssten auf dem anderen Datenträger (als unkomprimiert vorausgesetzt) unkomprimiert geschrieben werden. Was soll an diesem Denkschema faul sein?
Warum also kann man LW auf Komprimiert schalten und es findet dennoch keine Kompression statt?

Übrigens, mit Blick auf die SSD-Frage: ich arbeite nicht mit diesen komprimierten Daten. Ich hole höchstens was aus dem Backup zurück - oder ich pflege es (mit XCOPY, was ich heute ohne Probleme auf dem neu komprimierten LW mit alten Sicherungsroutinen getan habe).

Eric March

Ups, ich hätte den Startpost nochmal lesen müssen, mein Fehler.
Dann ist es natürlich seltsam das nicht komprimiert wurde. Eine Erklärung hab ich da auch nicht für, wobei ich zugeben muß das ich keine größeren Datenmengen auf der Kommandozeile kopiere. Dafür nutze ich Dateimanager die wiederum die Windowsfunktionen nutzen.

So sollte es auch sein...

When you move a compressed file or folder to another folder, the file remains compressed after the move, regardless of the compression state of the folder,

Zum Vergrößern anklicken....

When you copy a file to a folder, the file takes on the compression attribute of the target folder. For example, if you copy a compressed file to an uncompressed folder, the file is uncompressed when it is copied to the folder,

Zum Vergrößern anklicken....

Quelle: http://technet.microsoft.com/en-us/library/cc938914.aspx

Ich kann mir nur eines denken warum das mit der Kompromierung nicht klappte beim erste mal, und das wäre die Cluster Größe (siehe Link oben, habs mal rauskopiert)...

The compression algorithms in NTFS are designed to support cluster sizes of up to 4 KB. When the cluster size is greater than 4 KB on an NTFS volume, none of the NTFS compression functions are available.

Zum Vergrößern anklicken....

Hmtja… Ich habe aber nicht umformatiert… Nach Nutzung des Explorers wurde komprimiert. Im gleichen Dateisystem. Bleibt halt ulkig.

@vander
Ich nutze die Kommandozeile statt dem Explorer weil das… geräuschloser… abläuft und meinem Eindruck nach ’n Tick schneller. Es behindert nicht beim Arbeiten mit weiteren Explorern. Und wir wissen ja: Rückfragen, verklemmte Dateien - rumms steigt der Kamerad aus. Deswegen mag ich XCOPY und ROBOCOPY

CN8

Ich habe aber nicht umformatiert…

Zum Vergrößern anklicken....

also scheided die Cluster Größe somit aus...

Bleibt halt ulkig.

Zum Vergrößern anklicken....

Wäre ich jetzt religiös, würde ich sagen: Die Wege des Herrn sind unerklärlich, und MS manchmal auch...

…nicht «manchmal» sondern «immer» :heilg