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"

[Celelibi]

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

Je viens de tester avec un open/lseek/write (pour éviter les buffers de fopen/fwrite) sur un NFS. Et il apparaît que si je modifie une même page, on obtient tout et n'importe quoi :
- Parfois une machine pense être la seule à avoir modifié le fichier
- Parfois elle récupère bien les modifications de l'autre machine
- Dans tous les cas, le NFS ne contient que la version du dernier programme à avoir modifié le fichier

Si je modifie des pages différentes :
- Chaque machine pense avoir été la seule à modifier le fichier (NFS incohérent entre les machines)
- Le NFS contient bien toutes les modifications

Quand je dis que le NFS est incohérent, c'est que chaque machine voit un fichier différent (qui ne contient que ses propres modifs ou la version complète). Mais un touch depuis une machine tierce permet de forcer tout le monde à recharger le fichier.

Avec mmap... C'est quasiment la même chose. Modifier une même page donnera l'avantage au dernier processus à fermer/unmapper le fichier. Modifier des pages différentes donne le bon résultat sur le NFS, mais des fichiers incohérents entre les machines. Et le comportement est le même, que je map le fichier complet, ou juste la page souhaitée.

Mais ceci n'est rien d'autre qu'un comportement observé, je ne garanti rien de reproductible.

Je n'ai pas testé avec des msync. Mais peut-être qu'un msync avec un mutex distribué permet de résoudre le problème des pages mitoyennes.
Cependant, je continue de trouver ça assez sale de se dire que Linux n'ira pas réécrire tout le fichier une fois qu'il a été close et unmappé.

[jouana]

salut,
la fonction select est faite plus ou moins pour ça
Elle vérifie si un fd est libre d'écriture et de lecture
Il est utilisé dans les appli réseau pour boucler dessus sans bloquer sur la lecture.
Mais tu peut aussi l'utiliser sur d'autre fd dans se cas la c'est la solution
bonne journée

[matafan]

In fd est propre à un process. On ne peux pas utiliser select() pour sérialiser l'accès à un fichier entre plusieurs process. D'ailleurs même à l'intérieur d'un même process, select() ne sert pas à ça ; il n'empêchera pas deux threads d'aller écrire simultanément dans le même fichier.

[jouana]

Et la RFC de nfs elle permet pas de faire des trucs qui justement gère ces petits problèmes