[gull] Petit problème de maths, pour créer de liens

[Félix Hauri]

On Fri, May 02, 2008 at 10:40:52PM +0200, Yves Martin wrote:
>  Salut,
> 
> Donc pour résumer, tes structures identiques sont des installations de
> distributions Linux très similaires: grand nombre de fichiers de petites tailles
> en N exemplaires.
Oui, et non... Il s'agit effectivement dans plusieurs cas de distribs linux très
similaires, mais egallement de contenus de serveurs samba, ftp, web et/ou nfs...
càd des données de travail d'ordre privé (entreprises ou personnelles).

Quelques fichiers .tex (petits), des ms-office (>1M), des .dwg, ~30Mo -> ??,
bcp de .pdf de toutes tailles et même quelque CD-ROMs en .iso...

Il y a quelque fichiers pouvant aller jusqu'a >2Go...
Bref, un peu de tout, mais sur des serveurs confinés.

> Dans ce cas, la taille n'est pas suffisamment discriminante à mon avis. Et une
> somme de contrôle est trop coûteuse surtout si on veut assurer par des
> comparaisons complètes.
A méditer...

> L'avantage d'une comparaison est de stopper net à la première différence alors
> que le calcul d'un hash fera parcourir tout le fichier.
Si j'ai 20'000 fichiers de 512000 octets, comment les comparer pour faire
ressortir des groupes de fichiers identiques?

> Comme ce sont des structures proches, le nom du fichier ou même son chemin
> partiel ([...]/usr/bin/kinit par exemple) accompagné de la taille sont déjà à
> mon avis très discriminant.
Dans les branches ``serveurs de fichiers'', certains fichiers, voire branches
sont parfois déplacés ou renommés, bref mon job doit égallement et même 
essentiellement régler ce problème.

> Mais franchement, je ferai de toute façon une comparaison exacte, au risque de
> te retrouver un binaire qui ne fonctionne plus (erreur de liaison par exemple).
J'en suis là:
  etape 1 recensement des fichiers, tailles et inodes,
  etape 2 calculs de md5 pour les inodes dont les mêmes tailles existent
         au moins en 3* (pas de md5 juste pour 2 fichiers) exemplaires.
  etape 3 comparaison des fichiers et elimination des inodes ``doublons''.

* 2, 3, 252 (fd), le calcul des md5 devrait effectivement être relativisable...
A méditer encore...

Nota: je peux égallement enviseager de calculer des md5 simultanement sur 
plusieurs fichiers que je compare bit-à-bit en même temps...

> Pour gagner de la place encore, tu pourrais imaginer lier des répertoires entier
> si leur contenu est strictement identique mais c'est gagne-petit (1 ou 2 inode
> pour les entrées de répertoire).
Les hard-links sont impossibles sur des répertoires (en principe et sauf 
bidouille). càd pas posix like.

Enviseager des liens symboliques... Bof!
Quoique, cela pourrait aider égallement à la lisibilité des archives, en ce sens
que les 2èmes répertoires identiques.

De plus, si je relie une base de répertoire contenant une centaine de
sous-répertoire, je gagne une centaine d'inodes...

Mais là, on est vraiement dans le gagne-petit...
A méditer en 4è étape, pour la version 3.0 ;-)

> Je ne connais pas assez lisp - mais je te conseillerai plutôt le C.
C'est par vocation que j'évite le C, comme l'assembleur.

> J'ai déjà écrit du Perl avec des objectifs de performance et la lecture de
> fichier peut être piégeuse - "more than one way to do it" mais il y en a
> quelques unes à privilégier pour aller vite et ne pas consommer trop de RAM.
:->>
Sans commentaires!

> Si tu veux bien m'envoyer ton script Perl - j'aimerai y regarder de plus prêt.
Actuellement un peu ``sale'' à mon avis, je m'en vais finaliser ma version 2
et surtout la nettoyer un peu, avant de la montrer.

Pour l'instant perl lance ``cmp''. Peut-être que ``diff -q'', ou
autre chose pour comparer plus de deux fichiers en une lecture...

Merci, a+.

-- 
 Félix Hauri  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch