système de fichiers pour l'archivage

J'ai des données complexes en lecture seule dans mon système de fichiers. Il contient des milliers d'instantanés de certaines révisions d'un référentiel svn et la sortie de tests de régression. Les fichiers identiques entre les instantanés sont déjà dédoublés à l'aide de liens physiques. De cette façon, la capacité de stockage n'a pas besoin d'être grande, mais elle consomme toujours beaucoup d'inodes, et cela rend fsck douloureusement long pour mon système de fichiers principal.

Je voudrais déplacer ces données vers un autre système de fichiers, afin qu'elles n'affectent pas trop le système de fichiers principal. Avez-vous des suggestions? Squashfs semble être un choix possible, mais je devrai vérifier s'il peut gérer efficacement les liens durs.

Si c'est une lenteur de fsck, avez-vous essayé ext4? Ils y ont ajouté quelques fonctionnalités qui rendent fsck très rapide en ne regardant pas les inodes inutilisés :

Fsck est une opération très lente, en particulier la première étape: vérifier tous les inodes du système de fichiers. Dans Ext4, à la fin de la table des inodes de chaque groupe sera stockée une liste des inodes inutilisés (avec une somme de contrôle, par sécurité), donc fsck ne vérifiera pas ces inodes. Le résultat est que le temps total de fsck s'améliore de 2 à 20 fois, selon le nombre d'inodes utilisés (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Il faut noter que c'est fsck, et non Ext4, qui construira la liste des inodes inutilisés. Cela signifie que vous devez exécuter fsck pour obtenir la liste des inodes inutilisés, et seule la prochaine exécution de fsck sera plus rapide (vous devez passer un fsck afin de convertir un système de fichiers Ext3 en Ext4 de toute façon). Il y a aussi une fonctionnalité qui participe à cette accélération fsck - "groupes de blocs flexibles"

Btrfs a un support natif pour les instantanés, vous n'aurez donc pas à utiliser de liens durs pour la déduplication. Vous pouvez recréer votre configuration actuelle en créant un système de fichiers btrfs et en le chargeant avec la première révision dont vous avez besoin, et en prenant un instantané, puis en accélérant le référentiel à chaque moment dont vous avez besoin d'un instantané et en prenant un instantané à chaque étape. Cela devrait être plus efficace que les liens matériels et plus simple à configurer également.

Je pense également (bien que j'en sois loin d'être sûr) que squashfs déduplique les fichiers de manière transparente, donc même s'il ne gère pas les liens durs, vous verriez toujours des avantages. Si vous n'avez jamais besoin de modifier les données dans le système de fichiers, alors squashfs est probablement la voie à suivre, car fsck pourrait alors être remplacé par md5sum;)

Je préférerais XFS car j'ai de très bonnes expériences avec ce système de fichiers. Mais je vous recommande vraiment de faire un test avec vos données et tous les systèmes de fichiers suggérés.

Je connais plusieurs magasins qui utilisent un DataDomain exactement à cette fin.

Votre script d'archivage peut être très simple (tar ou rsync et cron, par exemple), et vous n'avez pas à vous soucier de la gestion des liens durs ou des répertoires qui ne peuvent pas être liés durement sur la plupart des systèmes de fichiers. Pas besoin de copies incrémentielles sauf pour économiser la bande passante. Toute la magie se produit en dessous dans la couche de blocs. Il n'est pas rare d'héberger 15 à 20 To de données virtuelles tout en utilisant seulement 1 à 2 To d'espace disque réel. Vous aurez encore beaucoup à faire pour vos sauvegardes sur disque.

Les données seraient servies via NFS ou iSCSI, mais je ne suis pas sûr que ce soit un problème

Lorsque FreeBSD obtient ZFS v23, la déduplication sera disponible pour le reste d'entre nous.