AIO en C sur Unix - utilisation de aio_fsync

Question

Je ne comprends pas ce que fait cette fonction aio_fsync. J'ai lu des pages man et même googlé mais ne peux pas trouver une définition compréhensible. Pouvez-vous l'expliquer de manière simple, de préférence avec un exemple?

Answer 1

aio_fsync est juste la version asynchrone de fsync; Une fois l'une terminée, toutes les données sont réécrites sur le support physique.

Remarque 1: aio_fsync() lance simplement la requête; l'opération de type fsync() n'est pas terminée tant que la requête n'est pas terminée, similaire aux autres appels aio_ *.

Remarque 2: seules les opérations aio_ * déjà mises en file d'attente lors de l'appel d'aio_fsync() sont incluses.

Comme vous du commentaire mentionné, si vous ne semblez pas utiliser fsync ou aio_fsync, les données vous toujours dans le fichier après la fin de votre programme. Cependant, si la machine était brusquement mise hors tension, elle ne serait probablement pas là. Cela est dû au fait que lorsque vous écrivez dans un fichier, le système d'exploitation écrit réellement sur le Page Cache qui est une copie des secteurs de disque conservés dans la RAM, et non sur le disque lui-même. Bien sûr, avant même qu'il ne soit réécrit sur le disque, vous pouvez toujours voir les données dans la RAM. Lorsque vous appelez fsync() ou aio_fsync(), il s'assurera que write(), aio_writes(), etc. pour toutes les parties de ce fichier sont réécrites sur le disque physique, pas seulement sur la RAM.

Si vous n'appelez jamais fsync(), etc., le système d'exploitation finira par réécrire les données sur le disque à chaque fois qu'il aura le temps de le faire. Ou un arrêt ordonné du système d'exploitation devrait le faire aussi bien. Je dirais que vous ne devriez généralement pas vous soucier de les appeler manuellement, sauf si vous devez vous assurer que vos données, disons un enregistrement de journal, sont vidées sur le disque physique et doivent être plus susceptibles de survivre à un brusque arrêt du système. Il est clair que les moteurs de base de données le feraient pour les transactions et les journaux.

Cependant, il existe d'autres raisons pour lesquelles les données peuvent ne pas survivre à cela et il est très complexe d'assurer une cohérence absolue face aux défaillances. Donc, si votre application n'en a absolument pas besoin, il est parfaitement raisonnable de laisser le système d'exploitation gérer cela pour vous. Par exemple, si la sortie .o du compilateur s'est avérée incomplète/corrompue parce que vous avez mis la machine sous tension au milieu d'une compilation ou peu de temps après, cela ne surprendra personne - vous devrez simplement redémarrer l'opération de compilation.