Dateisystem zur Archivierung

Ich habe einige komplexe schreibgeschützte Daten in meinem Dateisystem. Es enthält Tausende von Schnappschüssen bestimmter Revisionen eines SVN-Repositorys und die Ausgabe von Regressionstests. Identische Dateien zwischen Snapshots werden bereits mithilfe von Hardlinks de-dupliziert. Auf diese Weise muss die Speicherkapazität nicht groß sein, verbraucht aber immer noch viele Inodes, und dies macht fsck für mein Hauptdateisystem schmerzhaft lang.

Ich möchte diese Daten in ein anderes Dateisystem verschieben, damit das Hauptdateisystem nicht zu stark beeinträchtigt wird. Hast du vorschläge Squashfs scheint eine mögliche Wahl zu sein, aber ich muss prüfen, ob es mit harten Links effizient umgehen kann.

Wenn es um Langsamkeit geht, haben Sie ext4 ausprobiert? Sie haben ein paar Funktionen hinzugefügt, die fsck wirklich schnell machen, indem sie nicht verwendete Inodes nicht betrachten :

Fsck ist eine sehr langsame Operation, insbesondere der erste Schritt: Überprüfen aller Inodes im Dateisystem. In Ext4 wird am Ende der Inode-Tabelle jeder Gruppe eine Liste nicht verwendeter Inodes gespeichert (aus Sicherheitsgründen mit einer Prüfsumme), sodass fsck diese Inodes nicht überprüft. Das Ergebnis ist, dass sich die gesamte fsck-Zeit je nach Anzahl der verwendeten Inodes von 2 auf 20 Mal verbessert (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Es muss beachtet werden, dass es fsck und nicht Ext4 ist, der die Liste der nicht verwendeten Inodes erstellt. Dies bedeutet, dass Sie fsck ausführen müssen, um die Liste der nicht verwendeten Inodes zu erstellen, und nur der nächste fsck-Lauf schneller ist (Sie müssen einen fsck übergeben, um ein Ext3-Dateisystem trotzdem in Ext4 zu konvertieren). Es gibt auch eine Funktion, die an dieser fsck-Beschleunigung teilnimmt - "flexible Blockgruppen"

Btrfs bietet native Unterstützung für Snapshots, sodass Sie für die Deduplizierung keine festen Links verwenden müssen. Sie können Ihr aktuelles Setup neu erstellen, indem Sie ein btrfs-Dateisystem erstellen und es mit der frühesten benötigten Revision laden, einen Snapshot erstellen und das Repository dann zu jedem Zeitpunkt weiterleiten, zu dem Sie einen Snapshot benötigen, und jeweils einen Snapshot erstellen Schritt. Dies sollte effizienter als Hardlinks sein und auch einfacher einzurichten sein.

Ich denke auch (obwohl ich mir dessen nicht sicher bin), dass Squashfs Dateien transparent dedupliziert. Selbst wenn es keine harten Links verarbeitet, würden Sie dennoch Vorteile sehen. Wenn Sie die Daten im Dateisystem nie ändern müssen, ist squashfs wahrscheinlich der richtige Weg, da fsck dann durch md5sum ersetzt werden könnte;)

Ich würde XFS bevorzugen, da ich sehr gute Erfahrungen mit diesem Dateisystem habe. Aber ich empfehle wirklich, dass Sie einen Test mit Ihren Daten und allen vorgeschlagenen Dateisystemen durchführen.

Ich kenne mehrere Shops, die eine DataDomain genau für diesen Zweck verwenden.

Ihr Archivskript kann sehr einfach sein (z. B. tar oder rsync und cron), und Sie müssen sich nicht um die Verwaltung von Hardlinks oder Verzeichnissen kümmern, die auf den meisten Dateisystemen nicht fest verlinkt werden können. Es sind keine inkrementellen Kopien erforderlich, außer um Bandbreite zu sparen. Die ganze Magie geschieht unter der Blockschicht. Es ist nicht ungewöhnlich, virtuelle Daten im Wert von 15 bis 20 TB zu hosten, während nur realer Speicherplatz im Wert von 1 bis 2 TB verwendet wird. Sie haben noch viel für Ihre Festplattensicherungen übrig.

Die Daten würden über NFS oder iSCSI bereitgestellt, aber ich bin mir nicht sicher, ob dies ein Problem ist

Wenn FreeBSD ZFS v23 erhält, ist die Deduplizierung für den Rest von uns verfügbar.