Système de fichiers virtuel en écriture seule pour stocker des fichiers dans des archives

J'ai un processus parallèle embarrassant qui crée une énorme quantité de fichiers presque (mais pas complètement) identiques. Existe-t-il un moyen d'archiver les fichiers "à la volée", afin que les données ne consomment pas plus d'espace que nécessaire?

Le processus lui-même accepte les paramètres de ligne de commande et imprime le nom de chaque fichier créé sur stdout. Je l'invoque avec parallel --gnuqui s'occupe de distribuer les entrées (qui proviennent d'un autre processus) et de collecter les sorties:

arg_generating_process | parallel --gnu my_process | magic_otf_compressor

EXEMPLE SIMPLE pour la première partie du tuyau dans bash:

for ((f = 0; $f < 100000; f++)); do touch $f; echo $f; done

À quoi pourrait magic_otf_compressorressembler? Il est censé traiter chaque ligne d'entrée comme un nom de fichier, copier chaque fichier dans une .tararchive compressée (la même archive pour tous les fichiers traités!), Puis la supprimer. (En fait, il devrait suffire d'imprimer le nom de chaque fichier traité, un autre | parallel --gnu rmpourrait se charger de supprimer les fichiers.)

Existe-t-il un tel outil? Je ne pense pas à compresser chaque fichier individuellement, cela gaspillerait beaucoup trop d'espace. J'ai examiné archivemount(gardera le système de fichiers en mémoire -> impossible, mes fichiers sont trop gros et trop nombreux) et avfs( je n'ai pas pu le faire fonctionner avec FUSE). Qu'est-ce que j'ai raté?

Je ne suis qu'à un pas de pirater un tel outil moi-même, mais quelqu'un doit l'avoir fait avant ...

EDIT : Essentiellement, je pense que je cherche un frontal stdin pour libtar(par opposition au frontal de ligne de commande tarqui lit les arguments de, eh bien, la ligne de commande).

Il semble tarvouloir connaître tous les noms de fichiers à l'avance. C'est donc moins à la volée et plus après la volée. cpione semble pas avoir ce problème:

| cpio -vo 2>&1 > >(gzip > /tmp/arc.cpio.gz) | parallel rm

Un cas classique de RTFM (tout ça!) . L' -Toption GNU tarlira les fichiers à archiver à partir d'un autre fichier (dans mon cas /dev/stdin, vous pouvez également utiliser -), et il y a même une --remove-filesoption:

alias magic_otf_compressor='tar --create -T - --remove-files -O | pixz'

(en utilisant la version parallèle de xzpour la compression, mais vous pouvez utiliser votre compresseur préféré à la place). A utiliser comme:

arg_generating_process |
  parallel --gnu my_process |
  magic_otf_compressor > file.tar.xz

EDIT : Comme le souligne Ole, tarsemble lire la liste complète des fichiers avec l' -Toption pour une raison quelconque. Le test suivant le confirme:

for ((f = 0; $f < 1000; f++)); do
    touch $f; echo $f;
done | tar -c -f otf.tar -T - -v

Il y a un délai d'une seconde sur mon système avant que tous les fichiers soient imprimés en même temps; en revanche, si la tarcommande est remplacée par cat, tous les fichiers sont imprimés lors de leur création. J'ai déposé une demande d'assistance auprès des utilisateurs de tar, voyons.

EDIT ^ 2 : le plus récent tarde la source corrige cela. Ce n'est pas encore dans Ubuntu 13.10, mais pourrait être inclus avec 14.04.

D'une certaine manière, cela ne semble pas être un bon travail pour un compresseur solide (archiveurs sur bande + compression). L'insertion de fichiers l'un après l'autre ressemble à un travail zipou à un autre format qui permet un accès aléatoire aux fichiers dans l'archive et une insertion incrémentielle.

Le fait que les fichiers soient similaires n'aidera pas beaucoup dans les deux cas. Dans zip, les fichiers sont compressés séparément et dans les compresseurs solides, il y a généralement une fenêtre dans laquelle la compression a lieu.

Si les fichiers sont basés sur du texte, vous pouvez stocker des différences par rapport à un seul fichier de référence. Pour le binaire, c'est un peu plus délicat mais cela peut être fait.

Il existe également un moyen formel (non pas en écriture seule, mais des systèmes de fichiers appropriés). Par exemple, les systèmes de fichiers ZFS et BTRFS offrent une compression transparente. Vous pouvez également utiliser ce http://developer.berlios.de/projects/fusecompress

Cela peut ne pas sembler évident, mais je parie que ce squashfsserait parfait pour cela - et il est même implémenté dans le noyau. Depuis la version 4.1 squashfspeut gérer les pseudo-fichiers comme spécifié sur la mksquashligne de commande ou via un shell-script et mksquashfsgénérera les fichiers lors de la création de l'archive.

Il peut gérer des tuyaux - par exemple, vous pouvez capturer un autre processus stdoutdans une archive squash montable - même fifos - c'est plutôt cool. Dans votre cas, si vous pouviez travailler la logistique de script de la tuyauterie de sortie de votre processus à travers elle, vous pouvez envelopper votre processus entièrement dans mksquashfset le vent avec une seule archive. Voici un peu de la readmefaçon dont cela fonctionne et il y en a plus ici :

Mksquashfs 4.1 ajoute la prise en charge des "pseudo fichiers dynamiques" et une opération de modification. Les pseudo-fichiers dynamiques permettent la création dynamique de fichiers lors de l'exécution de Mksquashfs, leur contenu étant le résultat de l'exécution d'une commande ou d'un morceau de script shell. L'opération de modification permet de modifier le mode / uid / gid d'un fichier existant dans le système de fichiers source.

Création d'exemples de fichiers dynamiques

Créez un fichier "dmesg" contenant la sortie de dmesg.

    dmesg f 444 root root dmesg

Créez un fichier RELEASE contenant le nom de la version, la date, l'hôte de génération et un numéro de version incrémentiel. La version incrémentielle est un effet secondaire de l'exécution du script shell, et garantit que chaque fois que Mksquashfs est exécuté, un nouveau numéro de version est utilisé sans nécessiter d'autre script shell.

    RELEASE f 444 root root \
        if [ ! -e /tmp/ver ]; then \
        echo 0 > /tmp/ver; \
        fi; \
        ver=`cat /tmp/ver`; \
            ver=$((ver +1)); \
            echo $ver > /tmp/ver; \
            echo -n "release x.x"; \
            echo "-dev #"$ver `date` "Build host" `hostname`

Copiez 10K de l'appareil / dev / sda1 dans l'entrée de fichier. Ordinairement, Mksquashfs étant donné un périphérique, un fifo ou un socket nommé placera ce fichier spécial dans le système de fichiers Squashfs, cela permet à l'entrée de ces fichiers spéciaux d'être capturée et placée dans le système de fichiers Squashfs.

        input f 444 root root dd if=/dev/sda1 bs=1024 count=10