c linux msync (MS_ASYNC) commande de vidage

Est-ce que l’ordre des pages avec msync (MS_ASYNC) sur Linux est garanti d’être le même que l’ordre dans lequel les pages ont été écrites?

Si cela dépend des circonstances, y a-t-il un moyen pour moi (access complet au serveur) de m’assurer qu’ils sont dans le même ordre?

Contexte

J’utilise actuellement OpenLDAP Symas MDB comme stockage persistant de clé / valeur et sans MDB_MAPASYNC – ce qui entraîne l’utilisation de msync(MS_ASYNC) (j’ai parcouru le code source) – les écritures sont si lentes que même lors du traitement des données, un seul cœur attend en permanence sur IO à parfois <1Mo / s. Après analyse, le problème semble être celui de nombreuses petites opérations d’IO. MDB_MAPASYNC je peux facilement atteindre le débit maximal de mon disque, mais la documentation de MDB indique que, dans ce cas, la firebase database peut être corrompue. Malheureusement, le code est trop complexe pour moi / je n’ai actuellement pas le temps de parcourir pas à pas l’ensemble de la base de code pour découvrir pourquoi. Par ailleurs, je n’ai pas besoin de nombreuses fonctionnalités fournies par MDB (transactions , curseurs, conformité ACID), je pensais donc écrire mon propre magasin KV sauvegardé par mmap, en utilisant msync(MS_ASYNC) et en veillant à écrire de manière à ce qu’une page non vidée ne perde que les dernières données touchées, et non corrompre la firebase database ou perdre d’autres données.

Mais pour cela, il me faudrait une réponse à ma question, que je ne trouve absolument pas en cherchant sur Google ou en parcourant des listes de diffusion Linux malheureusement (j’ai trouvé quelques mails concernant les correctifs msync, mais rien d’autre)

Sur une note, j’ai regardé à travers des dizaines d’autres magasins KV persistants disponibles, et n’ai pas été en mesure de trouver un meilleur ajustement pour moi (écritures rapides, facile à utiliser, intégré (donc pas de services http ou similaires), vitesse déterministe (donc pas de garbage collection ni de compression aléatoire telle que leveldb), exigences d’espace saines (donc pas de bases de données rien que pour append), longueurs de clé variables, clés binarys et données), mais si vous en connaissez un qui pourrait m’aider ici, je ‘ d soyez aussi très reconnaissant.

msync(MS_ASYNC) ne garantit pas la commande des magasins, car les algorithmes d’E / S d’ascenseurs fonctionnant en arrière-plan tentent d’optimiser l’efficacité en fusionnant et en ordonnant les écritures afin de maximiser le débit du périphérique.

De l’ man 2 msync :

Depuis Linux 2.6.19, MS_ASYNC est en fait une opération MS_ASYNC , car le kernel suit correctement les pages altérées et les vide dans la mémoire si nécessaire.

Malheureusement, le seul mécanisme permettant de synchroniser un mappage avec son stockage de sauvegarde est le blocage MS_SYNC , qui ne dispose également d’aucune garantie de commande (si vous synchronisez une région de 1 Mio, les 256 pages de 4 Ko peuvent se propager dans le lecteur dans n’importe quel ordre). tout ce que vous savez, c’est que si msync revient, tous les 1 Mio ont été synchronisés).