Je lance une application qui ouvre un fichier dans un montage NFS avec l'option O_DSYNC
. L'application écrit ensuite 6500
octets de données 1000 fois dans le fichier dans une boucle.Le client NFS agrège les demandes d'écriture même lorsque l'application ouvre le fichier avec O_DSYNC
J'ai surveillé le comportement du client et j'ai remarqué qu'il envoyait les écritures au système de fichiers sous-jacent par lots de 4096 et 8192 octets.
Conformément à man open
, les opérations d'écriture sur un fichier ouvert avec O_DSYNC
se termineront conformément aux exigences de l'achèvement de l'intégrité des données d'E/S synchronisées. Il dit en outre que,
O_DSYNC provides synchronized I/O data integrity completion, meaning write operations will flush data to the underlying hardware, but will only flush metadata updates that are required to allow a subsequent read operation to complete successfully.
Je suppose que avec O_DSYNC
, write()
appel ne reviendra pas jusqu'à ce que le système de fichiers sous-jacent a écrit avec succès les données. Ce n'est pas ce qui se passe ici. Le client NFS met en cache les écritures et les purge par multiples de 4k. Pourquoi cela est-il ainsi?
Notez que, j'utilise une instance Amazon EC2 exécutant la version Linux 4.9, avec une taille de page de 4096.
Quel comportement voyez-vous sur les anciennes versions? –
@AndrewHenle, Quand je cours simultanément un écrivain et un lecteur sur 2 machines différentes, de telle sorte que l'auteur dort pendant 4min après plus de 500 itérations de la boucle. Je note que l'application imprime un journal qu'il a écrit '6500xnumber_of_iterations' octets, mais le lecteur prétend être quelques octets court. Ceci est vu seulement sur 4.9 et pas sur 4.1. – user1071840
O_DSYNC se réfère uniquement aux tampons de fichiers dans votre processus. NFS a sa propre option SYNC pour faire des écritures immédiates contre la mise en cache. Vous devez également définir la synchronisation dans l'exportation NFS. – stark