De: "Basile Starynkevitch" <bas...@starynkevitch.net>
À: "Liste Debian" <debian-user-french@lists.debian.org>
Envoyé: Jeudi 12 Janvier 2023 20:59:25
Objet: Re: Détecter un changement dans un répertoire
On 12/01/2023 20:16, RogerT wrote:
Pourquoi : pour prendre des décisions de traitement sur évènement « fichier
créé/modifié/supprimé/etc. ».
FS : ext4 ou btrfs ou nfs.
NFS va poser problème. Il est connu et documenté que inotify ne fonctionne pas
avec NFS, mais avec des systèmes de fichiers locaux et natifs à Linux (dont
ext4 et btrfs).
Ok. il suffit de ne pas utiliser NFS.
Merci.
BQ_BEGIN
Qté de fichiers : il y a différents cas ;
1/ surveiller un répertoire où sont déposés des fichiers régulièrement, qui
vont en être enlevés après traitement ; ici, le nombre de fichiers présents à
chaque instant sera de l’ordre d’une centaine, voire d’un millier pour
constituer une file d’attente si le traitement est long et que le flux de dépôt
de fichiers augmente.
Là, je crois que inotify et ses dérivés devraient faire l’affaire sans
atteindre ses limites qui serait de 5E5 fichiers à surveiller.
BQ_END
A mon avis, c'est faisable programmatiquement (en C++ ou Rust ou C ou Ocaml)
sur une machine Linux suffisamment puissante (disons 32Go de RAM au moins, et 8
cœurs). Il faut lire [ https://man7.org/linux/man-pages/man7/inotify.7.html |
https://man7.org/linux/man-pages/man7/inotify.7.html ] où on peut lire les
limitations:
BQ_BEGIN
The inotify API does not report file accesses and modifications
that may occur because of [
https://man7.org/linux/man-pages/man2/mmap.2.html | mmap(2) ] , [
https://man7.org/linux/man-pages/man2/msync.2.html | msync(2) ] , and [
https://man7.org/linux/man-pages/man2/munmap.2.html | munmap(2) ] .
BQ_END
Pour 100-1.000 fichiers, aucun souci.
32 Go/8 coeurs pour 500.000 fichiers ? Tant que ça ?
L'article que j'ai cité aujoud'hui parle de 1 ko/fichier soit 500 Mo pour
traiter 5E5 fichiers, ce qui est considérable pour de nombreuses applications.
Citation :
Cet article de janvier 2022 apporte des réponses sur la limite et la
récursivité :
[ https://www.baeldung.com/linux/inotify-upper-limit-reached |
https://www.baeldung.com/linux/inotify-upper-limit-reached ]
« Here, the system allows 524288 (2^19) watches. »
« Because each watch is a structure, available memory is also a bottleneck for
using inotify .
In fact, a watch can take up to 1KB of space. This means a million watches
could result in 1GB of extra RAM usage. »
BQ_BEGIN
2/ multiplier les surveillances pour différentes applications ; là je dirais de
l’ordre de 10E4-10E6 fichiers maximum. Je ne vois pas des milliards de fichiers
à surveiller.
Là, inotify devrait encore pouvoir servir si on ne dépasse pas sa fameuse
limite.
BQ_END
Mais dix millions de fichiers à surveiller, ça me parait beaucoup. Oui bien
alors, faire une programmation fine (multi-thread, mulit-processus) qui prendra
du temps (des mois de travail) et nécessiterait un ordinateur coûteux (serveur
ou desktop à 10k€, pas un NAS à 500€).
Erreur de formulation, je voulais dire E4-E6 ou 10^4-10^6 (10.000- 1.000.000).
Maximum.
On peut et on doit s'imposer la limite de inotify annoncée de 5E5 (500.000).
Je ne crois pas à une solution simple, rapide (basée sur inotify ) et 100%
fiable pour dix millions de fichiers, ou bien alors il faut développer un gros
logiciel .... Le diable est dans les détails.
Et 100.000-500.000 ?
Bonne soirée
Pour ma part, je cherche des partenaires intéressés par le projet logiciel
libre RefPerSys en [ http://refpersys.org/ | http://refpersys.org/ ] -
contactez moi alors par courriel (peut-être même au bureau [
https://list.cea.fr/ | CEA LIST ] en [ mailto:basile.starynkevi...@cea.fr |
basile.starynkevi...@cea.fr ] )
Bonne soirée.
--
Basile Starynkevitch [ mailto:bas...@starynkevitch.net |
<bas...@starynkevitch.net> ] (only mine opinions / les opinions sont miennes
uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
