[Admin-ml] Dossier r=?ISO-8859-1?B?6Q==?=calcitrant

Fabrice Vincent f.vincent at allibert-trekking.com
Lun 25 Mai 14:15:03 CEST 2009


Salut tous,

Je raccroche l'enfilade, après le grand pont du WE dernier...

> find /var/virusmails -type f -print0 |xargs -0 rm
> 
> Ca devrait être plus rapide que le simple find car il execute un seul
> rm pour n fichier trouvés (n=5000 par défaut mais on peut le changer
> par l'option -n de xargs).
> 
Encore mieux: ne pas faire appel à un second process (qui fait un second
accès) et tout faire faire par le process find en utilisant l'option
-delete:
find /var/virusmails -type f -delete

Et pour limiter la recherche au répertoire sans parcourir les sous
répertoires, et en ne supprimant que les .gz:
find /var/virusmails -type f -delete -maxdepth 1 -name '*.gz'



Pour la petite histoire, un répertoire d'un filesystem unix classique ne
peut contenir qu'un nombre limité de fichier dans sa table d'allocation
"primaire" (environ 1000 sur HP-UX, je ne sais pas combien sur HFS+ *), car
il utilise le bloc disque qui lui est alloué par le système. Quand le bloc
contenant cette table est presque plein, il doit allouer 1 à 1 des blocs
supplémentaires, d'abord en indirection directe, puis (rapidement) en chaine
d'indirection.
Et la, bonjour les perfs quand il faut parcourir le tout...

Conséquence: c'est une très mauvaise idée de stocker plus de quelques
milliers de fichiers dans un répertoire ! Au delà, il vaut mieux utiliser
une arborescence et y répartir plus ou moins uniformément les fichiers...
Avec un niveau d'arborescence, on peut déjà stocker efficacement plus d'un
million de fichier (1000 répertoires contenant 1000 fichiers), et avec deux
niveaux on peut dépasser le milliard de fichier sans soucis...

Une solution est de répartir de manière aléatoire, ou suivant le hashcode du
nom de fichier. Malheureusement, peu de développeur pense à ce problème. :(

NB: mes connaissances (et mon expérience) sur ce sujet date d'il y a
quelques années. Les choses évoluent et les systèmes de fichiers les plus
récents ont peut être trouvé la parade à ce problème. Quoi que...

Pour en revenir au problème de la quarantaine amavisd, il suffirait de
répartir les mail infectés dans une arborescence à un niveau pour stocker
sans soucis un million de mail...
N'utilisant pas amavisd moi même, je ne sais pas si il accepterai qu'un
script déplace toutes les heures les mail de /var/virusmails dans un
arborescence (style /var/virusmails/00/ à /var/virusmails/ff/ ). Mais ça
peut être une piste pour conserver une quarantaine sans pour autant pourrir
les perf du serveur quand on accède à la quarantaine...

A+
Fabrice

* si quelqu'un connaît la limite de HFS+ ça m'intéresse ! 






Plus d'informations sur la liste de diffusion Admin-ml