Fim (File Integrity Manager) sort dans sa version 1.2.0 avec divers gains de performance.
Fim est un gestionnaire de fichiers libre (licence GPLv3) qui permet de gérer beaucoup de fichiers de n'importe quelle taille. Il peut par exemple, gérer des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et aider à les effacer.
Les nouveautés de la version 1.2.0
Amélioration globale de la performance
- Diminution de la taille du state en mémoire et sur le disque en utilisant Ascii85 au lieu de Hexa pour stocker les hash
- Ajout du Super-fast commit
- Augmentation de la capacité à gérer une très grande quantité de fichiers (1 098 138 fichiers fonctionne pour moi)
- Optimisation de la comparaison des state pour pouvoir comparer rapidement deux State contenant 1 000 000 de fichiers
Général
- Fim est maintenant distribué sous forme d'image Docker sur Docker Hub
- Chaque commit sur Fim est maintenant testé sur Mac OS X grâce au builder Travis Mac
À noter : le format utilisé pour le state est nouveau et non-compatible avec le format précédent. Cela nécessite donc une ré-indexation / une nouvelle table de hashs : fim ci -y -c "Migration vers Fim 1.2.0"
.
Corrections de bogues
- Vérification des droits sur le répertoire .fim avant toute exécution de commandes
- Ignore maintenant les millisecondes des dates de modification (certains JDK ne les écrivent pas ou les écrivent à 0)
- Ajout de l'option
--output-max-lines
permettant d'allonger la liste présentée maintenant par défaut : 200 lignes du même type tronquées. - Les fichiers vides ne sont plus répertoriés comme dupliqués.
Aller plus loin
- Changelog (235 clics)
- Documentation (666 clics)
- Download (306 clics)
- Github project (527 clics)
- Fim sur Docker Hub (179 clics)
- Dépêche précédente, Fim 1.1.0 (309 clics)
# fichier en erreur ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Est-ce qu'il y a une détection des fichiers en erreur ?
Mon cas d'usage est celui de copies multiples de répertoire contenant mes archives photos (sauvegardes sur différent support faites au cours du temps). Parfois des images sont corrompues. Comment faire pour "remerger" toutes ces copies en un seul répertoire propre de référence.
"La première sécurité est la liberté"
[^] # Re: fichier en erreur ?
Posté par Etienne Vrignaud . Évalué à 2.
Il existe la commande
fim --detect-corruption
qui peut t'aider. Mais elle ne propose pas d'effacer les fichiers corrompus. Peut-être que ca pourrais être pratique. Et donc tu aurais plus qu'a merger les répertoires contenant des archives.Mais ca c'est la cas idéal où tous les contenus sont identiques.
Si les contenus des fichiers ont évolués ou qu'ils été renommés depuis les copies, c'est pas simple de merger.
[^] # Re: fichier en erreur ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En fait, il faudrait un répertoire de référence, et des copies, si un fichier est corrompu dans le répertoire de référence, on le remplace par une copie (même nom, même taille, voir même path relatif).
"La première sécurité est la liberté"
# Gérer les fichiers
Posté par binoyte . Évalué à 10.
Ça veut dire quoi «gérer les fichiers» ? N'importe quel gestionnaire de fichiers (nautilus, midnight commander etc.) le fait, non ?
C'est quoi au juste FIM ?
+ une liste de somme de contrôle ?
+ une bibliothèque dans laquelle on peut attacher des métadonnées aux fichiers ?
Je m'excuse mais je ne comprends pas bien, malgré la lecture du précédent billet et du site officiel.
[^] # Re: Gérer les fichiers
Posté par memz . Évalué à 4. Dernière modification le 25 mai 2016 à 16:27.
D'après la doc c'est une liste de sommes de contrôle avec un historique des modifications (mais le programme ne stocke pas le contenu des fichiers donc on ne peut pas récupérer un ancien fichier). On peut comparer cette liste aux fichiers réellement présents sur le système pour détecter ceux qui ont été ajoutés, supprimés ou modifiés, ceux qui sont corrompus ou dupliqués.
Disant ça, j'ai l'impression que ça manque d'outils annexes pour être vraiment utile (automatiser la suppression de duplicatas, la synchronisation de plusieurs dépôts, la restauration de dépôts corrompus comme le demande le voisin du dessus…).
[^] # Re: Gérer les fichiers
Posté par Etienne Vrignaud . Évalué à 4.
Comme vous le faites très justement remarquer, Fim réalise des opération assez basiques. Il permet de faire un index des hash des fichiers d'une arborescence.
Ce qui est interessant avec Fim c'est qu'il fourni des commandes pour utiliser à bon escient ces hash.
Fim se caratérise par les fonctionnalités suivantes:
- Le mode super-fast permet de réaliser diverses opérations très rapidement en évitant de hasher tout le contenu fichiers ce qui accélère énormément les opérations.
- La comparaison du State courant avec le State précédent permet d'obtenir des informations intéressantes comme les modification, ajout, suppression, renommage.
- La détection rapide des fichiers dupliqués.
Tout cela est diffile a réaliser avec des script qui font du hashage brutal de tous les fichiers d'un répertoire.
Et cela ne sera pas performant.
Concernant les fonctionnalités avancées qui semblent manquer, je ne suis pas sûre que cela soit destiné à Fim.
Fim à été créé pour être un outil simple d'utilisation. Pour une utilisation avec plusieurs dépots ou autre, il vaut mieux passer à des outils comme git-lfs (https://git-lfs.github.com/) ou git-annex (https://git-annex.branchable.com/).
[^] # Re: Gérer les fichiers
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'aurais tenté avec une lecture de l'arborescence complète, puis comparaison byte à byte en cas de collision nom/taille. Faudrait que je tente le coup avec des morceaux d'un ancien code.
"La première sécurité est la liberté"
[^] # Re: Gérer les fichiers
Posté par Etienne Vrignaud . Évalué à 1.
En gros, c'est ce que fait le mode 'do not hash' de fim quand on utilise l'option -n
# Liens symboliques ?
Posté par François (site web personnel) . Évalué à 2.
Est-ce que fim supporte bien les dossiers remplis de liens symboliques ? Même avec ls, c'est pénible.
Le cas typique est un grand nombre de fichiers gérés avec git-annex.
[^] # Re: Liens symboliques ?
Posté par Etienne Vrignaud . Évalué à 2.
Fim supporte très bien les liens symboliques. Il les ignore.
# Paquet binaire
Posté par Arkem . Évalué à 1.
Lorsque je fais une recherche sur fim dans Synaptic, je trouve "a scriptable frame buffer and ascii art image viewer"… évidemment, ce n'est pas le bon programme. Est-il prévu qu'il soit supporté par nos distributions dans un futur plus ou moins proche?
[^] # Re: Paquet binaire
Posté par Etienne Vrignaud . Évalué à 1.
C'est une chose que je n'ai pas encore étudiée.
Je pense qu'il serait intéressant de distribuer Fim sous forme de Snap, le nouveau type de packaging qui vient avec Ubuntu 16.04.
Sinon les contributions pour réaliser des packaging du type .deb ou .rpm sont les bien venues.
# Binaire ?
Posté par Kerro . Évalué à 2.
Tu as peut-être des impératifs particuliers, mais c'est typiquement le genre de choses qu'on stocke sous forme d'octets bruts (en binaire, je ne sais pas trop comment expliquer). Pour la simple raison que c'est le « vrai » format des hashes, et que c'est ce qui est retourné par les fonctions de hachage.
[^] # Re: Binaire ?
Posté par memz . Évalué à 2. Dernière modification le 25 mai 2016 à 17:12.
Encore selon la doc [1], le catalogue est sous forme de fichiers json compressés. C'est à dire dans un format texte, où effectivement un hash prend moins de caractères et donc moins d'espace mémoire en ascii85 qu'en hexa (par exemple, dans un fichier texte en ASCII, tu verras "5A>@%" au lieu de "ff4ab3c" - si chaque caractère est codé sur 1 octet, tu as économisé 2 octets).
Une somme de contrôle c'est une information qu'on représente habituellement en base 16 mais ça peut être une base 85, une image ou autre. Ça n'altère pas l'information elle-même du moment qu'on s'entend sur les règles.
Après on peut discuter de la pertinence de JSON dans ce cas.
[1] https://evrignaud.github.io/fim/#_state_file_content
[^] # Re: Binaire ?
Posté par Etienne Vrignaud . Évalué à 4.
C'est une bonne remarque. Mais le format de stockage des State n'est pas du binaire.
C'est du json compressé avec un algo gzip.
Et donc pour produire du json valide il faut convertir le binaire résultant du hachage en chaine de caractère.
J'ai trouvé que c'était la façon la plus simple de stocker les informations du State et la façon la plus évolutive.
En effet, il est possible d'ajouter autant d'attribut que l'on veut à un State, pas de problèmes du type taille de record ou autre.
# NIH et autres considérations
Posté par steph1978 . Évalué à 2. Dernière modification le 02 juin 2016 à 13:34.
J'ai des besoins de gestion de fichiers qui pourrait être couverts par FIM.
En particulier, j'ai une vilaine tendance à dupliquer mes fichiers de travail un peu partout, sur plusieurs machines, sur plusieurs disques externes.
Cette tendance est à la baisse depuis la création de mon instance d'un owncloud sur un serveur en datacenter. Mais j'ai encore un gros travail de consolidation à faire.
J'ai fait un bout de script python+lmdb qui me permet de détecter des doublons, basé lui aussi sur SHA2.
Je trouve certains choix de Fim pertinents :
- interface calquée sur celle d'un VCS (svn ou git) : init, commit, diff, etc.
- prise d'empreinte à différent points d'un fichier pour accélérer le diff
Par contre mon script python ne prend que quelques MB de RAM quelque soit le nombre de fichiers et sous-répertoires ; Ce grâce à LMDB qui fait du mmap (allocation de l'espace mémoire de l'index hors du heap, utilisant le cache FS). Alors quand je vois "JAVA_OPTIONS="-Xmx4g -XX:MaxMetaspaceSize=4g" dans le script de lancement, je fais un bon. Ce n'est même pas la RAM que j'ai sur ce serveur (2GB).
[^] # Re: NIH et autres considérations
Posté par Etienne Vrignaud . Évalué à 2.
L'indication
"JAVA_OPTIONS="-Xmx4g -XX:MaxMetaspaceSize=4g"
est juste un maximum d'allocation mémoire pour la JVM.Fim dans une utilisation "normale" utilise moins de ram.
Voici des chiffres que j'ai collectés sur une utilisation de Fim avec 348 344 fichiers.
Lors de la création du repository Fim a besoin de 1,9 GB de Heap et 13 MB de Metaspace.
Pour les utilisations suivantes pour comparer l'état actuel avec le précédent il a besoin de 2,5 GB de Heap et toujours 13 MB de Metaspace.
Durant l'execution de Fim le State complet est chargé en mémoire et donc quand on fait des comparaisons de State, les deux sont chargés en mémoire. C'est cela qui charge beaucoup la ram.
Peut-être que certains aspects dans Fim peuvent améliorés. N'oublions pas que Fim est juste en version 1.
Il est toujours possible d'exprimer des besoins afin que j'étudie une piste d'optimisation, suivant les problèmes rencontrés.
Ou alors de contribuer par des pull request.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.