En ce moment, j'utilise ArchiveMountpour monter une archive de 123 000 ko qui contient plus de 3 millions de fichiers à l'intérieur. Jusqu'à présent, il monte depuis plus de 5 heures et n'est toujours pas terminé.

Existe-t-il une meilleure façon de monter un .tar.gzfichier? J'essaie de monter dans un dossier, et non compressé, cela prend quelques concerts. Je n'ai même pas besoin du mode écriture, juste la lecture seule est suffisante.

Vous pouvez également créer une image squashfs compressée

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

Pour ce faire, vous devrez extraire votre archvie tar.gz.

L'avantage est également que l'image a une meilleure tolérance aux pannes que gz.

Le problème ici est avec le format, le format TAR (Tape ARchive) est conçu pour un accès séquentiel, pas un accès aléatoire. Et gzip est un bon complément à tar, car il s'agit d'un format de compression basé sur le flux, également pas pour un accès aléatoire.

Ainsi, un outil de haut niveau qui n'interagit pas directement avec les blocs compressés, devra analyser l'intégralité du fichier à chaque fois qu'il a besoin de lire quoi que ce soit, d'abord pour vous obtenir la liste des fichiers, puis peut-être le cache invalide et il le relit , puis pour chaque fichier que vous copiez, il peut le relire. Vous pouvez créer un outil qui se souvient de la position de chaque fichier et des blocs dont il a besoin pour décompresser pour l'obtenir, mais il semble que peu de gens se soient souciés de cela.

Si vous voulez que cela aille plus vite, faites un tar tzf file.tar.gz > filelist, ouvrez cette liste de fichiers dans vim , gedit ou autre, supprimez les lignes de fichiers dont vous n'avez pas besoin, enregistrez, puis extrayez-les avec tar xzf file.tar.gz -T filelist -C extracted/.

Pour obtenir un accès aléatoire à un fichier compressé, vous devez peut-être utiliser zip avec des extensions posix, rar, ou comme le suggère dru8274, squashfs, ou même ZFS avec la compression activée, ou btrfs si btrfs a obtenu que la compression fonctionne au moment de la lecture.

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.

Cela ne couvrira pas tous les cas d'utilisation car il restreint l'utilisation à un éditeur de texte. Mais, si vous ne vous souciez que de l'accès en lecture, cela peut vous être utile dans certaines situations. vim, lorsqu'il est exécuté sur une archive tar, vous affichera la hiérarchie de contenu de l'archive (similaire à la façon dont il affichera une hiérarchie de fichiers s'il est exécuté sur un répertoire). En sélectionnant l'un des fichiers dans la liste, il ouvrira le fichier sélectionné dans un tampon en lecture seule.

Encore une fois, cela n'offre pas nécessairement un accès aux images ou à d'autres médias, mais si tout ce dont vous avez besoin est de voir le contenu ou d'accéder uniquement aux fichiers texte, cela devrait être utile.

Remarque : cela ne fonctionnera pas sur tous les formats d'archives.

Mon approche. Si vous avez suffisamment d'espace disque libre sur un lecteur USB externe ou un lecteur de disque dur externe / secondaire avec suffisamment d'espace, envisagez simplement d'extraire votre fichier .tar.gz. Penser que vous ne voulez probablement pas 3 millions de fichiers sur votre disque système principal, car cela pourrait ralentir les choses. Je recommanderais que le disque externe dans ce cas dispose d'un système de fichiers qui gère facilement un grand nombre de fichiers: en pensant à ReiserFS, ext4 (avec l'option dir_index), XFS, peut-être BtrFS. Cela pourrait prendre 1 à 2 heures pour faire l'extrait, mais vous pouvez simplement aller déjeuner entre-temps ou le laisser fonctionner pendant la nuit; à votre retour, l'accès aux fichiers extraits devrait être performant.