Discussion :

[bloomenthal]

Bonjour,

Je suis en train de développer une application qui tournera sur un cluster de "beaucoup" de machines (pour faire de la simulation numérique), avec une couche MPI.

Précisément, je finalise la partie I/O disque (je dois faire des sauvegardes régulières).

Les données du problème se situent toutes dans un gigantesque fichier partagé entre tous les noeuds. Cependant, chaque noeud du cluster travaille sur des parties disjointes des données

Mon problème :
actuellement, j'utilise mmap dans chaque processus afin d'accéder au fichier efficacement (le mécanisme derrière mmap étant intelligent, l'utilisation mémoire est très faible, c'est l'idéal).
Or, de temps en temps, je dois faire des sauvegardes des données.
Or, il n'y a aucune raison que, lorsqu'un processus écrit une des pages sur le disque pour mettre à jour ses données n'écrase pas une partie des données venant d'être écrites par un autre processus ! En effet, les processus travaillent sur des données disjointes, mais le découpage en pages peut chevaucher la zone de plusieurs processus... !

Je me demandais donc si vous avez une idée pour pallier à ce problème. J'ai pensé à plusieurs solutions, qui ne me satisfont pas :
- Ajouter du padding dans le fichier pour que les pages ne chevauchent pas les données de plusieurs processus -> pour des pages de 4096 octets, la taille du fichier va litéralement exploser
- Rajouter une couche de communication MPI pour ne faire l'écriture disque que par un seul process. Mais ça, au niveau réseau, ça va être assez dramatique au niveau latence et efficacité...

Donc, si vous avec une idée, ou connaissez un mécanisme permettant de faire un réglage fin de mmap (je n'y crois pas trop), je suis preneur !

Toutes suggestions bienvenues !

Merci

[Sve@r]

Après lecture et relecture, j'arrive à la conclusion que ton problème vient du fait que le découpage en pages peut chevaucher la zone de plusieurs processus.

Affecte à chaque noeud une partie bien précise du fichier et là, plus de souci. Chaque noeud n'ira écrire que la partie qui le concerne quand ça lui chante...

[Celelibi]

De base, je trouve ça pas très beau de se dire "j'ouvre un même fichier en écriture depuis plusieurs processus, mais c'est pas grave on travaille sur des zones différentes.".
Le problème, c'est pas mmap, mais toute la hiérarchie de buffers qui peuvent se chevaucher entre noeuds.

mmap utilise ses propres buffers, mais fopen et cie. utilise les siens aussi (cf setvbuf). Linux possède aussi les siens. Et si un seul des buffers mis en jeux chevauche celui d'un autre noeud, t'as perdu...
(Le buffer de fopen n'intervient certainement pas avec mmap, c'était pour l'exemple ; et pour dire que remplacer mmap par fopen ne résoudrait pas le problème.)
Si pour mmap on peut raisonnablement supposer que le buffer est géré par page, on ne peut rien dire pour celui du noyau. Autrement dit, gérer le découpage entre noeuds sur des frontières de pages n'est pas une bonne solution non plus à mon avis.

Si chaque noeud travaille sur des partie disjointes du fichier, ça serait pas mieux de découper le fichier en plein de fichiers plus petits ?

[matafan]

Je ne pense pas qu'il y ait de problème si le fichier est mappé avec MAP_SHARED (plutôt que MAP_PRIVATE). Tant que deux process ne vont pas écrire exactement à la même adresse (même si les deux process écrivent dans la même page, d'ailleurs), il n'y aura pas de conflits.

[jouana]

ah mon avis sa sent la merde en mémoire :/

vérifie si c'est pas toi qui déborde

man mmap
man getpagesize
man msync

Et si deux processus écrive en même temps sur la page avec msync tu vas superposé tes données vu que msync synchronise la mémoire avec le fichier que tu a mapper en mémoire pour le sauvegarder sur ton dd et la l'emplacement est pas propre a ton process

informe toi sur les semaphores et les threads

[Celelibi]

Je ne pense pas qu'il y ait de problème si le fichier est mappé avec MAP_SHARED (plutôt que MAP_PRIVATE). Tant que deux process ne vont pas écrire exactement à la même adresse (même si les deux process écrivent dans la même page, d'ailleurs), il n'y aura pas de conflits.

Sauf que là on est sur un cluster. Le noyau ne peut rien faire pour garantir la cohérence entre les noeuds. Le fichier est partagé... via NFS ou similaire je pense.

[jouana]

re,
tien temps que j'y pense
man select
cela aide pas mal pour la gestion des fd en lecture écriture afin d'éviter les pb de concurrence sur un fd si tu as des questions demande toujours

[matafan]

Sauf que là on est sur un cluster. Le noyau ne peut rien faire pour garantir la cohérence entre les noeuds. Le fichier est partagé... via NFS ou similaire je pense.

Ca ne change rien puisque "chaque noeud du cluster travaille sur des parties disjointes des données"