Im Enteo-Forum gab es kürzlich eine angeregte Diskussion über die Frage, ob es seit Enteo v6 und erst recht mit DSM 7 nicht sinnvoller wäre, für neue Repositories die Option "Nur eine Kopie des Paketverzeichnisses halten" zu aktivieren, da man damit jede Menge teuren Storage-Space sparen könnte. Was natürlich auf den ersten Blick wie eine hervorragende Idee aussieht, entpuppt sich (womöglich) bei näherer Betrachtung als "Schuss in den Ofen".

Da ich das ganze Thema schon länger mal komplett durchdenken wollte, habe ich die Forum-Diskussion zum Anlass genommen, diesen Artikel zu schreiben...

Beginnen möchte ich mit der einfachst-möglichen Umgebung, wo es nur ein Repository und eine LAN-Site (bzw. damit auch nur ein Depot) gibt, und in dieser Site auch die Paketdaten nicht komprimiert gehalten werden. Alle Pakete liegen in Revision 1 vor.

Dass die Pakete selbst im Original irgendwo unkomprimiert liegen müssen, damit die Packaging Workbench damit arbeiten kann, ist wohl unbestritten. Ob die Dateien dabei in einem Unterverzeichnis von WORK oder INSTALL liegen, macht auch keinen Unterschied, sodass sich die Option hier noch nicht auf den benötigten Speicherplatz auswirkt. Dieses Verzeichnis ist also im Standardfall "\\DEPOT1\DSM$\WORK\«Repositoryname»\Projects\«Paket-ID»" oder "\\DEPOT1\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»", wenn die Option aktiviert wird.

Wird ein Paket dann zur Distribution vorbereitet, werden die Dateien in das Unterverzeichnis "REV\1" des Paketverzeichnisses komprimiert. Auch hier ist es also zunächst unerheblich, ob sich dieses Verzeichnis unterhalb von WORK oder INSTALL befindet.

Interessant wird das Ganze dann, wenn jetzt die Distribution definiert wird:

• im Standardfall, wo also die Option "Nur ein Kopie des Paketverzeichnisses halten" NICHT ausgewählt wurde, werden die Dateien nach "\\DEPOT1\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\1" entpackt
• wurde die Option ausgewählt, findet der Entpackvorgang ebenfalls nach "\\DEPOT1\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\1" statt – die Dateien waren aber auch bei Verwendung der Option dort noch nicht entpackt vorhanden, sondern ausschließlich in komprimierter Form.

Wichtig ist hier nun festzustellen, dass die Dateien also in jedem Fall doppelt entpackt vorliegen (als Arbeitskopie direkt im Paketverzeichnis und als Installationskopie im "REV\1" Unterverzeichnis), unabhängig davon, ob die Option zum Verwenden nur einer Kopie des Paketverzeichnisses ausgewählt wurde oder nicht. Das heißt, dass es in diesem Szenario völlig unerheblich ist, ob die Option verwendet wird oder nicht – der Storage-Verbrauch wird in beiden Fällen identisch sein.

Betrachten wir das nächste Szenario, wo es nicht nur ein Depot gibt, sondern mindestens eine weitere Site (oder beliebig viele), die über eigene Depots verfügen. Die Pakete liegen, wie im ersten Beispiel, wieder ausschließlich in Revision 1 vor.

In diesem Fall findet die Replikation zwischen den Depots ja von WORK nach WORK oder von INSTALL nach INSTALL statt – repliziert werden aber in jedem Fall die komprimierten Dateien, was sich auch nicht durch irgendwelche Konfigurationseinstellungen ändert lässt.

In der Standard-Konfiguration werden die komprimierten Archive also von "\\DEPOT1\DSM$\WORK\«Repositoryname»\Projects\«Paket-ID»\Rev\1" nach "\\DEPOT2\DSM$\WORK\«Repositoryname»\Projects\«Paket-ID»\Rev\1" repliziert. Wird die Option zum Halten nur eines Paketverzeichnisses aktiviert, findet der Replikationsschritt von "\\DEPOT1\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\1" nach "\\DEPOT2\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\1" statt.

Das heißt, dass bis hierher die Option weder auf den Distributions-Traffic noch auf den Speicherplatzverbrauch auf DEPOT2 eine Auswirkung hat.

Im nächsten Schritt müssen die komprimierten Pakete entpackt werden. Unter der Annahme, dass sich auf DEPOT2 (oder in dessen Nähe) ein Distributionsdienst befindet, werden hierfür keine Daten zwischen DEPOT1 und DEPOT2 (also über eine WAN-Strecke) übertragen. Die entpackten Dateien werden für beide Konfigurationseinstellungen unter "\\DEPOT2\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\1" abgelegt, sodass auch hier der benötige Platz gleich bleibt.

Es kann festgestellt werden, dass sich durch Aktivieren der Optione auch auf weiteren Depots kein Storage-Platz einsparen lässt!

Kommen wir nun zu dem Fall, dass Pakete nicht immer in Revision 1 vorliegen, sondern auch höhere Revisionen existieren. Der Einfachheit halber, wird zunächst wieder Szenario 1 mit nur einem Depot betrachtet:

Auf die Größe der Arbeitskopie (im WORK oder INSTALL) hat diese Option, wie oben schon festgestellt, keinen Einfluss. Wird dann für eine Revision größer 1 die Distribution vorbereitet, so werden in das "REV\«Revionsions-Nr»" Unterverzeichnis nur die Dateien komprimiert, die sich für diese Revision geändert haben. Auch hier ist es also unerheblich, ob sich dieses Verzeichnis unterhalb von WORK oder INSTALL befindet.

Die Distribution entpackt die Dateien dann nach "\\DEPOT1\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\«Revionsions-Nr»". Unter Enteo v6 sind dort auch nur die jeweils gegenüber der Vorgänger-Revisions geänderten Dateien abgelegt, sodass (wie beim initialen Paket in Revision 1) die Dateien zweifach entpackt vorliegen. Der Speicherplatz-Bedarf für diese Dateien ist aber gleich, egal ob eine oder zwei Kopien des Paketverzeichnisses verwendet werden.

Seit DSM 7 liegt im "REV\«Revionsions-Nr»" Unterverzeichnis zwar "scheinbar" jeweils das komplette Paket, doch nutzt DSM hier die Funktionalitäten des NTFS-Dateisystems und arbeitet mit Hardlinks, sodass sich identische Dateien tatsächlich nur einmal physikalisch auf dem Storage befinden. Der zusätzliche Speicherplatzbedarf durch die Hardlinks selbst kann vernächlässigt werden, sodass sich also auch hier kein Vorteil durch die Nutzung der Option, nur eine Kopie des Paketverzeichnisses zu halten, ergibt.

Werden nun wieder Umgebungen mit mehreren Sites betrachtet, so stellt man auch hier fest, dass der Speicherplatz-Bedarf unabhängig von der Nutzung der Option "Nur ein Kopie des Paketverzeichnisses halten" ist. Es gelten dabei die gleichen Überlegungen wie bei Paketen in Revision 1.

Zuguterletzt besteht ja auf Ebene einer Site die Möglichkeit, in dieser Site "komprimierte Paketdateien zu verwenden". In diesem Szenario greifen die Clients nicht auf die entpackten Paketdateien zu, sondern laden sich zunächst die komprimierten Archive in ein lokales Verzeichnis, um sie von dort zu entpacken. Diese Einstellung wird standardmäßig für Remote- und Offline-Sites gesetzt, wo der Vorteil des geringeren zu übertragenden Datenvolumens den Nachteil des erhöhten lokalen Platzbedarfs überwiegt.

Werden ausschließelich Sites mti komprimierten Paketdateien verwendet – was im Übrigen eine besonders ungewöhnliche Konfiguration darstellt – so ergibt sich für durch die Option, nur eine Kopie des Paketverzeichnisses zu verwenden, tatsächlich ein nicht zu vernachlässigendes Einsparpotenzial. Gehen wir die oben betrachteten Szenarien nochmals durch:

Die ungepackte Arbeitskopie der Paketdateien ist wieder unabhängig von sämtlichen Konfigurations-Einstellungen, genauso wie die komprimierte Kopie für die Distribution. Liegt allerdings die Distributions-Kopie im INSTALL-Verzeichnis (also unter "\\DEPOT1\DSM$\INSTALL\«Repositoryname»\Projects\«Paket-ID»\Rev\1"), so sind dort alle für die Site benötigten Dateien vorhanden und müssen nicht durch den Distributionsdienst vom WORK- ins INSTALL-Verzeichnis kopiert werden.

In Umgebungen mit mehreren Depots, wo die Distribution dann vom INSTALL direkt in das untergeordnete INSTALL-Verzeichnis erfolgt, spart man sich ebenfalls die Ablage der komprimierten Paketdateien im WORK-Verzeichnis.

Wie oben gesehen, gelten die bereits angestellten Überlegungen auch für höhere Paketrevisionen – unabhängig davon, ob eine oder zwei Paketverzeichnisstrukturen verwenden werden. Also gilt auch hier, dass für Depots, die ausschließlich Sites mit komprimierten Paketdateien bedienen, sich ebenfalls die Ablage dieser Dateien im WORK-Verzeichnis einsparen lässt.

Daher kann nun festgestellt werden, dass in diesen Szenarien sich also durch das Verwenden der Option auf allen Depots das Volumen der komprimierten Paketdateien einmalig einsparen lässt.

Als Fazit lässt sich meines Erachtens konstatieren: obwohl man im ersten Moment meinen könnte, dass die Option nur eine Kopie des Paketverzeichnisses zu verwenden, den Speicherplatzbedarf einer Enteo v6 oder DSM 7 Umgebung signifikant reduzieren könnte, stellt sich dies bei genauer Betrachtung in aller Regel als Irrtum heraus.

Lediglich in Umgebungen, wo alle Sites komprimierte Paketdateien verwenden, ist ein gewisses (und durchaus überschaubares) Einsparpotenzial realisierbar – doch kommen solche Umgebungen erfahrungsgemäß in der Realität niemals vor.

Es bleibt damit nur festzuhalten, dass man von der Verwendung dieser Option abraten muss, da man sich potenzielle Probleme einhandelt, ohne daraus einen Vorteil ziehen zu können.