J'ai écrit une alternative plus rapide ratarmount , qui « fonctionne pour moi », parce que ce problème a continué à me casser les pieds.
Vous pouvez l'utiliser comme ceci:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
Lorsque vous avez terminé, vous pouvez le démonter comme n'importe quel support FUSE:
fusermount -u mount-folder
Pourquoi est-il plus rapide qu'archivemount?
Cela dépend de ce que vous mesurez.
Voici une référence de l'empreinte mémoire et du temps requis pour le premier montage, ainsi que des temps d'accès pour une cat <file-in-tar>commande simple et une findcommande simple .
Des dossiers contenant chacun 1 000 fichiers ont été créés et le nombre de dossiers varie.
Le graphique en bas à gauche montre des barres d'erreur indiquant les temps mesurés minimum et maximum cat <file>pour 10 fichiers choisis au hasard.
Temps de recherche de fichier
La comparaison qui tue est le temps qu'il faut pour cat <file>terminer. Pour une raison quelconque, cela évolue linéairement avec la taille du fichier TAR (environ octets par fichier x nombre de fichiers) pour l'archivemount tout en étant à temps constant dans ratarmount. Cela donne l'impression qu'archivemount ne prend même pas en charge la recherche.
Pour les fichiers TAR compressés, cela est particulièrement visible.
cat <file>prend plus de deux fois plus de temps que le montage de l'ensemble du fichier .tar.bz2! Par exemple, le TAR avec 10 000 fichiers vides (!) Prend 2,9 secondes pour être monté avec archivemount mais en fonction du fichier consulté, l'accès avec catprend entre 3 ms et 5 s. Le temps que cela prend semble dépendre de la position du fichier à l'intérieur du TAR. Les fichiers à la fin du TAR sont plus longs à rechercher; indiquant que la "recherche" est émulée et tout le contenu du TAR avant la lecture du fichier.
L'obtention du contenu du fichier peut prendre plus de deux fois plus de temps que le montage de l'ensemble du TAR est inattendu en soi. Au moins, il devrait se terminer dans le même temps que le montage. Une explication serait que le fichier est recherché par émulation plus d'une fois, peut-être même trois fois.
Apparemment, Ratarmount prend toujours le même temps pour obtenir un fichier car il prend en charge la recherche réelle. Pour les TAR compressés bzip2, il cherche même le bloc bzip2, dont les adresses sont également stockées dans le fichier d'index. Théoriquement, la seule partie qui doit évoluer avec le nombre de fichiers est la recherche dans l'index et qui doit évoluer avec O (log (n)) car elle est triée par chemin et nom de fichier.
Empreinte mémoire
En général, si vous avez plus de 20 000 fichiers à l'intérieur du TAR, l'empreinte mémoire de ratarmount sera plus petite car l'index est écrit sur le disque lors de sa création et a donc une empreinte mémoire constante d'environ 30 Mo sur mon système.
Une petite exception est le backend du décodeur gzip, qui pour une raison quelconque nécessite plus de mémoire à mesure que le gzip s'agrandit. Cette surcharge de mémoire peut être l'index requis pour rechercher à l'intérieur du TAR mais une enquête plus approfondie est nécessaire car je n'ai pas écrit ce backend.
En revanche, archivemount conserve l'intégralité de l'index, qui est, par exemple, 4 Go pour les fichiers de 2 Mo, entièrement en mémoire aussi longtemps que le TAR est monté.
Temps de montage
Ma fonctionnalité préférée est le montage sur le montant de la carte qui permet de monter le TAR sans délai notable lors d'un essai ultérieur. Cela est dû au fait que l'index, qui mappe les noms de fichiers aux métadonnées et à la position à l'intérieur du TAR, est écrit dans un fichier d'index créé à côté du fichier TAR.
Le temps requis pour le montage se comporte un peu bizarrement en termes d'archivage. À partir d'environ 20 000 fichiers, il commence à évoluer de manière quadratique plutôt que linéaire en fonction du nombre de fichiers. Cela signifie qu'à partir d'environ 4 millions de fichiers, ratarmount commence à être beaucoup plus rapide qu'archivemount même si pour les petits fichiers TAR, il est jusqu'à 10 fois plus lent! Là encore, pour les petits fichiers, peu importe que cela prenne 1 s ou 0,1 s pour monter le tar (la première fois).
Les temps de montage des fichiers compressés bz2 sont les plus comparables à tout moment. Ceci est très probable car il est lié à la vitesse du décodeur bz2. Ratarmount est environ 2x plus lent ici. J'espère faire de ratarmount le vainqueur incontestable en parallélisant le décodeur bz2 dans un avenir proche, ce qui, même pour mon système de 8 ans, pourrait donner une accélération de 4x.
Il est temps d'obtenir des métadonnées
Lorsque vous findlistez simplement tous les fichiers avec à l'intérieur du TAR (find semble également appeler stat pour chaque fichier!?), Ratarmount est 10 fois plus lent que archivemount pour tous les cas testés. J'espère pouvoir améliorer cela à l'avenir. Mais actuellement, cela ressemble à un problème de conception en raison de l'utilisation de Python et SQLite au lieu d'un programme C pur.