Bye bye CTAN mirror

Mal etwas außerhalb der Publisher-Welt. Bis vor kurzem hatte ich einen täglichen CTAN¹-Abzug, den ich per Git versioniert habe. Über ein Web-Frontend konnte man darauf zugreifen und sich den Zustand eines jeden Tages seit dem 17.3.2013 anzeigen lassen. Ganz praktisch, wenn man eine alte Version eines TeX-Pakets haben wollte.

Leider habe ich die Fähigkeiten von Git etwas überschätzt und muss es hauptsächlich aufgrund der Größe und der Serverauslastung abstellen.

Warum überhaupt eine tägliche Sicherung?

CTAN behauptet von sich (das steckt ja im Namen) ein Archiv zu sein. Technisch gesehen ist es aber nicht, denn jede neue Version eines Pakets überschreibt eine alte Version, und damit ist die alte Version nicht mehr verfügbar. Das kann aber zu einem Problem werden, wenn man – aus welchen Gründen auch immer – auf eine alte Version zurückgreifen muss. Dieses Problem kann man nur durch ein echtes Archiv lösen.

Die Technik dahinter

Ein CTAN-Verzeichnis hat etwa die Größe von knapp 40 Gigabyte. Per rsync mache ich jeden Morgen eine lokale Kopie, die per git add / git commit in ein Git Repository eingecheckt wird. Dadurch ist der Zustand eines jeden Tages eingefroren und kann zurückgeholt werden.

Um das Git-Repository für den Anwender sichtbar zu machen, habe ich ein Frontend dafür geschrieben, das mit einer eigenen Bibliothek auf das Repository zugreift und per Date-Picker die Sicht auf jeden Tag seit Beginn des Abzugs auswählbar macht. Außerdem wurden die Dateien verlinkt, so dass man zur letzten Änderung einer jeden Datei zurückspringen kann.

Ein paar Zahlen

In der Zwischenzeit (das sind ca. fünfeinhalb Jahre) ist das Repository auf 750 Gigabyte angewachsen in 2078 Commits.

Im eigentlichen CTAN gibt es derzeit 15252 Verzeichnisse, 246940 Dateien in etwa 37 GB Größe.

Git speichert, im Gegensatz zu SVN, nicht Änderungen zwischen den Dateien, sondern jede geänderte Datei einzeln. Das heißt: eine kleine Änderung einer großen Datei erzeugt zwei große Dateien. Erst in einem separaten Prozess kann Git Dateien auch packen, d.h. es kann dann doch mit Diffs umgehen.

Ein einzelner Lauf, um Daten zu packen, verbraucht den gesamten Hauptspeicher des Servers, so dass er alle anderen Prozesse lahmlegt. Ein einzelner Commit hingegen, der die Dateien nicht optimiert, geht sehr flott. Damit würde aber die Größe des Repositories riesig groß werden. Das lässt sich leider nicht auf einem Server durchführen, in dem andere wichtige Dienste laufen.

Ausblick

Die Überschrift ist etwas irreführend, weil ich den Dienst zum Ende des Jahres einstelle. Mit reichlich Wehmut, weil ich viel Arbeit hinein gesteckt habe und weil ich die Idee eines echten Archivs immer noch für sehr sinnvoll halte.

Für den Dienst müsste man einen eigenen Root-Server mit viel Rechenleistung bereitstellen, damit die aufwändigen Git-Prozesse schneller ablaufen. Alternativ dazu wäre ein Versionskontrollsystem denkbar, das mit großen Dateien besser zurecht kommt. Vielleicht ist hier das gute alte SVN doch geeigneter?

Immer wieder wird Git Large File Storage (LFS) genannt, doch das scheint nicht dieses Problem zu lösen. Das Problem wird nur verlagert.

Und falls es jemanden interessiert: hier ein Vortrag darüber aus der Anfangszeit des Dienstes.