Le fichier append est-il atomique sous UNIX?

En général, que pouvons-nous prendre pour acquis lorsque nous ajoutons à un fichier sous UNIX à partir de plusieurs processus? Est-il possible de perdre des données (un processus écrasant les modifications de l'autre)? Est-il possible que les données soient mutilées? (Par exemple, chaque processus ajoute une ligne par ajout à un fichier journal, est-il possible que deux lignes soient mutilées?) Si l'ajout n'est pas atomique dans le sens ci-dessus, quel est le meilleur moyen d'assurer l'exclusion mutuelle?

Une écriture dont la taille est inférieure à 'PIPE_BUF' est supposée être atomique. Cela devrait être d'au moins 512 octets, bien que cela puisse facilement être plus grand (Linux semble l'avoir réglé à 4096).

Cela suppose que vous parlez de tous les composants entièrement compatibles POSIX. Par exemple, ce n'est pas vrai sur NFS.

Mais en supposant que vous écriviez dans un fichier journal que vous avez ouvert en mode 'O_APPEND' et que vous gardiez vos lignes (y compris le saut de ligne) sous 'PIPE_BUF' octets de long, vous devriez pouvoir avoir plusieurs écrivains dans un fichier journal sans aucun problème de corruption. Toutes les interruptions arriveront avant ou après l'écriture, pas au milieu. Si vous voulez que l'intégrité du fichier survive à un redémarrage, vous devrez également appeler fsync(2)après chaque écriture, mais c'est terrible pour les performances.

Clarification : lisez les commentaires et la réponse d'Oz Solomon . Je ne suis pas sûr que ce O_APPENDsoit censé avoir cette PIPE_BUFatomicité de taille. Il est tout à fait possible que ce soit simplement la manière dont Linux a été implémenté write(), ou cela peut être dû à la taille des blocs du système de fichiers sous-jacent.

Edit: mis à jour en août 2017 avec les derniers résultats Windows.

Je vais vous donner une réponse avec des liens vers le code de test et les résultats en tant qu'auteur du projet Boost.AFIO qui implémente un système de fichiers asynchrone et une bibliothèque C ++ d' entrées / sorties de fichiers.

Premièrement, O_APPEND ou l'équivalent FILE_APPEND_DATA sous Windows signifie que les incréments de l'étendue maximale du fichier ("longueur" du fichier) sont atomiques sous les auteurs simultanés. Ceci est garanti par POSIX et Linux, FreeBSD, OS X et Windows l'implémentent tous correctement. Samba l'implémente également correctement, NFS avant la v5 ne le faisant pas car il ne dispose pas de la capacité de formatage filaire pour l'ajout atomique. Ainsi, si vous ouvrez votre fichier avec un ajout uniquement, les écritures simultanées ne se déchireront pas les unes par rapport aux autres sur un système d'exploitation majeur, sauf si NFS est impliqué.

Cependant, les lectures simultanées aux appendices atomiques peuvent voir des écritures déchirées en fonction du système d'exploitation, du système de fichiers et des indicateurs avec lesquels vous avez ouvert le fichier - l'incrément de l'étendue maximale du fichier est atomique, mais la visibilité des écritures par rapport aux lectures peut ou non être atomique. Voici un résumé rapide par drapeaux, OS et système de classement:

Non O_DIRECT / FILE_FLAG_NO_BUFFERING:

Microsoft Windows 10 avec NTFS: mise à jour atomicité = 1 octet jusqu'à 10.0.10240 inclus, à partir de 10.0.14393 au moins 1 Mo, probablement infini (*).

Linux 4.2.6 avec ext4: mise à jour de l'atomicité = 1 octet

FreeBSD 10.2 avec ZFS: mise à jour de l'atomicité = au moins 1 Mo, probablement infini (*)

O_DIRECT / FILE_FLAG_NO_BUFFERING:

Microsoft Windows 10 avec NTFS: mise à jour atomicité = jusqu'à et y compris 10.0.10240 jusqu'à 4096 octets uniquement si la page est alignée, sinon 512 octets si FILE_FLAG_WRITE_THROUGH est désactivé, sinon 64 octets. Notez que cette atomicité est probablement une fonctionnalité de PCIe DMA plutôt que conçue. Depuis 10.0.14393, au moins 1 Mo, probablement infini (*).

Linux 4.2.6 avec ext4: mise à jour atomicité = au moins 1 Mo, probablement infini (*). Notez que les Linux précédents avec ext4 ne dépassaient certainement pas 4096 octets, XFS avait certainement un verrouillage personnalisé, mais il semble que Linux récent a finalement résolu ce problème.

FreeBSD 10.2 avec ZFS: mise à jour de l'atomicité = au moins 1 Mo, probablement infini (*)

Vous pouvez voir les résultats des tests empiriques bruts sur https://github.com/ned14/afio/tree/master/programs/fs-probe . Notez que nous testons les décalages déchirés uniquement sur des multiples de 512 octets, donc je ne peux pas dire si une mise à jour partielle d'un secteur de 512 octets se déchirerait pendant le cycle de lecture-modification-écriture.

Donc, pour répondre à la question du PO, les écritures O_APPEND n'interféreront pas les unes avec les autres, mais les lectures simultanées aux écritures O_APPEND verront probablement des écritures déchirées sur Linux avec ext4 à moins que O_DIRECT ne soit activé, après quoi vos écritures O_APPEND devront être d'un multiple de taille de secteur.

(*) "Probablement infini" provient de ces clauses de la spécification POSIX:

Toutes les fonctions suivantes doivent être atomiques les unes par rapport aux autres dans les effets spécifiés dans POSIX.1-2008 lorsqu'elles opèrent sur des fichiers normaux ou des liens symboliques ... [plusieurs fonctions] ... read () ... write ( ) ... Si deux threads appellent chacun l'une de ces fonctions, chaque appel verra soit tous les effets spécifiés de l'autre appel, soit aucun d'entre eux. [La source]

et

Les écritures peuvent être sérialisées par rapport à d'autres lectures et écritures. Si une lecture () de données de fichier peut être prouvée (par n'importe quel moyen) après une écriture () des données, elle doit refléter cette écriture (), même si les appels sont effectués par des processus différents. [La source]

mais inversement:

Ce volume de POSIX.1-2008 ne spécifie pas le comportement des écritures simultanées dans un fichier à partir de plusieurs processus. Les applications doivent utiliser une forme de contrôle d'accès concurrentiel. [La source]

Vous pouvez en savoir plus sur la signification de ceux-ci dans cette réponse

J'ai écrit un script pour tester empiriquement la taille maximale de l'append atomique. Le script, écrit en bash, génère plusieurs processus de travail qui écrivent tous des signatures spécifiques au travailleur dans le même fichier. Il lit ensuite le fichier à la recherche de signatures qui se chevauchent ou sont corrompues. Vous pouvez voir la source du script dans cet article de blog .

La taille maximale réelle de l'ajout atomique varie non seulement selon le système d'exploitation, mais aussi selon le système de fichiers.

Sous Linux + ext3, la taille est de 4096 et sous Windows + NTFS, la taille est de 1024. Voir les commentaires ci-dessous pour plus de tailles.

Voici ce que dit la norme: http://www.opengroup.org/onlinepubs/009695399/functions/pwrite.html .

Si l' O_APPENDindicateur des indicateurs d'état de fichier est mis, le décalage de fichier doit être mis à la fin du fichier avant chaque écriture et aucune opération de modification de fichier ne doit intervenir entre le changement de l'offset de fichier et l'opération d'écriture.