Limitation des appels systèmes noyaux pour les systèmes de fichiers distribués

=Sujet= Sur des infrastructures de calcul (HPC) on peut observer sous certaines condition un phénomène appeler "stat storm" [1], il s'agit de rafale d'appels systèmes noyaux déclenchés pour tester l'existence de bibliothèque lors du lancement d'une application. Ce phénoméne se trouve démultiplier lors de l'usage de systèmes de fichiers distribués comme NFS et d'application parallèle. Plusieurs approches ont été étudiées et mises en place [1][2] mais aucune n'apporte de solution générale. Nous proposons ici d'étudier l'usage d'un cache de résultats avec consultation et diffusion par multicat.

=Technologies= Le prototype sera réalisé en Python, un deuxième prototype pourra être aussi réalisé en Rust. La technologie Fuse [3] sera utilisée pour interagir avec la partie système de fichier du noyau. Cette technologie permet de développer des systèmes fichiers en espace utilisateur sans avoir à développer un module noyaux [3]

=Consignes=
 * Lire les références [1,2,3]
 * Expérimenter fuse avec la version python3 [4] et l'exemple passthrough [5]
 * Observer et décrire par schéma avec échange le déroulement de appels stat
 * Décrire par un schéma et un diagramme de séquence le déroulement d'un appel stat avec un cache de requete
 * Implémenter un premier prototype sans multicast
 * Implémenter un second prototype avec multicast

=Références=


 * [1] https://guix.gnu.org/en/blog/2021/taming-the-stat-storm-with-a-loader-cache/
 * [2] https://fzakaria.com/2022/09/12/making-runpath-redundant-for-nix.html
 * [3] https://en.wikipedia.org/wiki/Filesystem_in_Userspace
 * [4] http://www.rath.org/pyfuse3-docs/
 * [5] http://www.rath.org/pyfuse3-docs/example.html#passthrough-overlay-file-system

=Ressources pour le prototype Rust (optionnel)=
 * [a] https://github.com/cloud-hypervisor/fuse-backend-rs
 * [b] https://bluejekyll.github.io/blog/posts/multicasting-in-rust/
 * [c] https://github.com/bluejekyll/multicast-example