{"id":98090,"date":"2020-10-24T02:42:38","date_gmt":"2020-10-24T00:42:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux"},"modified":"2020-11-18T00:58:48","modified_gmt":"2020-11-17T22:58:48","slug":"ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Stockage durable des donn\u00e9es et API de fichiers Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En explorant la durabilit\u00e9 du stockage de donn\u00e9es dans les syst\u00e8mes cloud, j'ai d\u00e9cid\u00e9 de me tester, pour m'assurer que je comprends les \u00e9l\u00e9ments de base. Je ai commenc\u00e9 par lire la sp\u00e9cification NVMe<\/a><\/noindex> pour comprendre quelles garanties relatives \u00e0 la durabilit\u00e9 du stockage de donn\u00e9es (c'est-\u00e0-dire, la garantie que les donn\u00e9es seront disponibles apr\u00e8s une panne syst\u00e8me) nous fournissent les disques NVMe. J'ai tir\u00e9 les principales conclusions suivantes : il faut consid\u00e9rer les donn\u00e9es comme endommag\u00e9es \u00e0 partir du moment o\u00f9 la commande d'\u00e9criture des donn\u00e9es est donn\u00e9e, et jusqu'\u00e0 ce que leur \u00e9criture sur le support d'information soit termin\u00e9e. Cependant, dans la plupart des programmes d'\u00e9criture de donn\u00e9es, les appels syst\u00e8mes sont utilis\u00e9s sans aucune pr\u00e9caution.<\/p>\n

Dans ce document, j'explore les m\u00e9canismes de durabilit\u00e9 du stockage de donn\u00e9es fournis par les API de fichiers Linux. Il semble que tout cela devrait \u00eatre simple : le programme appelle la commande write()<\/code>, et apr\u00e8s que cette commande soit termin\u00e9e, les donn\u00e9es doivent \u00eatre enregistr\u00e9es de mani\u00e8re fiable sur le disque. Mais write()<\/code> elle ne fait que copier les donn\u00e9es de l'application dans le cache du noyau, situ\u00e9 en m\u00e9moire vive. Pour forcer le syst\u00e8me \u00e0 \u00e9crire les donn\u00e9es sur le disque, il faut utiliser certains m\u00e9canismes suppl\u00e9mentaires.<\/p>\n

\"Stockage<\/a><\/noindex><\/p>\n

Dans l'ensemble, ce document est un ensemble de notes sur ce que j'ai appris sur le sujet qui m'int\u00e9resse. Pour r\u00e9sumer tr\u00e8s bri\u00e8vement l'essentiel, il en ressort que pour organiser un stockage de donn\u00e9es durable, il faut utiliser la commande fdatasync()<\/code> ou ouvrir les fichiers avec le drapeau O_DSYNC<\/code>. Si vous \u00eates int\u00e9ress\u00e9 \u00e0 en savoir plus sur ce qui se passe avec les donn\u00e9es lors de leur passage du code \u00e0 disque, jetez un coup d'\u0153il \u00e0 cet<\/a><\/noindex> article.
\n<\/a><\/noindex><\/p>\n

Les caract\u00e9ristiques de l'utilisation de la fonction write()<\/h2>\n

\nAppel syst\u00e8me write()<\/code> sont d\u00e9finies dans la norme IEEE POSIX<\/a><\/noindex> comme une tentative d'\u00e9criture de donn\u00e9es dans un descripteur de fichier. Apr\u00e8s la r\u00e9ussite de l'op\u00e9ration, write()<\/code> les op\u00e9rations de lecture de donn\u00e9es doivent renvoyer exactement les octets qui ont \u00e9t\u00e9 pr\u00e9c\u00e9demment \u00e9crits, m\u00eame si les donn\u00e9es sont acc\u00e9d\u00e9es depuis d'autres processus ou threads (voici<\/a><\/noindex> section correspondante de la norme POSIX). Ici<\/a><\/noindex>, dans la section consacr\u00e9e \u00e0 l'interaction des flux avec les op\u00e9rations de fichiers courantes, il est not\u00e9 que si chacun des deux flux appelle ces fonctions, chaque appel doit soit voir toutes les cons\u00e9quences d\u00e9sign\u00e9es r\u00e9sultant de l'ex\u00e9cution de l'autre appel, soit ne voir aucune cons\u00e9quence. Cela permet de conclure que toutes les op\u00e9rations d'entr\u00e9e\/sortie sur les fichiers doivent maintenir un verrou sur la ressource avec laquelle elles travaillent.<\/p>\n

Cela signifie-t-il que l'op\u00e9ration write()<\/code> est atomique? D'un point de vue technique - oui. Les op\u00e9rations de lecture de donn\u00e9es doivent retourner soit tout, soit rien de ce qui a \u00e9t\u00e9 \u00e9crit via write()<\/code>. Mais l'op\u00e9ration write()<\/code>, conform\u00e9ment \u00e0 la norme, n'est pas n\u00e9cessairement tenue de se terminer en \u00e9crivant tout ce qui lui a \u00e9t\u00e9 propos\u00e9 d'\u00e9crire. Elle est autoris\u00e9e \u00e0 \u00e9crire seulement une partie des donn\u00e9es. Par exemple, nous pourrions avoir deux flux, chacun ajoutant 1024 octets \u00e0 un fichier d\u00e9crit par le m\u00eame descripteur de fichier. D'un point de vue normatif, un r\u00e9sultat o\u00f9 chacune des op\u00e9rations d'\u00e9criture parvient \u00e0 ajouter au fichier seulement un octet serait acceptable. Ces op\u00e9rations resteront atomiques, mais une fois termin\u00e9es, les donn\u00e9es qu'elles auront \u00e9crites dans le fichier seront m\u00e9lang\u00e9es. Voici<\/a><\/noindex> il y a une discussion tr\u00e8s int\u00e9ressante \u00e0 ce sujet sur Stack Overflow.<\/p>\n

Les fonctions fsync() et fdatasync()<\/h2>\n

\nLe moyen le plus simple de forcer les donn\u00e9es sur le disque est d'appeler la fonction fsync()<\/a><\/noindex>. Cette fonction demande au syst\u00e8me d'exploitation de transf\u00e9rer tous les blocs modifi\u00e9s du cache vers le disque. Cela inclut \u00e9galement tous les m\u00e9tadonn\u00e9es du fichier (heure d'acc\u00e8s, heure de modification du fichier, etc.). Je pense que le besoin de ces m\u00e9tadonn\u00e9es se produit rarement, donc si vous savez qu'elles ne sont pas essentielles pour vous, vous pouvez utiliser la fonction fdatasync()<\/code>. Il y a aide<\/a><\/noindex> pour fdatasync()<\/code> indique que lors de l'ex\u00e9cution de cette fonction, un volume de m\u00e9tadonn\u00e9es est sauvegard\u00e9 sur le disque, qui est \"n\u00e9cessaire pour l'ex\u00e9cution correcte des op\u00e9rations suivantes de lecture de donn\u00e9es\". Et c'est pr\u00e9cis\u00e9ment ce qui pr\u00e9occupe la plupart des applications.<\/p>\n

Un des probl\u00e8mes qui peuvent survenir ici est que ces m\u00e9canismes ne garantissent pas que le fichier sera d\u00e9tectable apr\u00e8s un \u00e9ventuel \u00e9chec. En particulier, lorsque vous cr\u00e9ez un nouveau fichier, il est n\u00e9cessaire d'appeler fsync()<\/code> pour le r\u00e9pertoire qui le contient. Sinon, apr\u00e8s un crash, il se peut que ce fichier n'existe plus. La raison en est qu'en UNIX, en raison de l'utilisation de liens durs, un fichier peut exister dans plusieurs r\u00e9pertoires. Par cons\u00e9quent, lors de l'appel fsync()<\/code> il n'y a aucun moyen de savoir pour quel r\u00e9pertoire les donn\u00e9es doivent \u00e9galement \u00eatre \u00e9crites sur disque (ici<\/a><\/noindex> on peut en lire plus en d\u00e9tail). Il semble que le syst\u00e8me de fichiers ext4 soit capable d'appliquer automatiquement<\/a><\/noindex> \u00e0 des r\u00e9pertoires contenant les fichiers correspondants, mais dans le cas d'autres syst\u00e8mes de fichiers, cela peut ne pas \u00eatre le cas. fsync()<\/code> Ce m\u00e9canisme peut \u00eatre impl\u00e9ment\u00e9 diff\u00e9remment dans divers syst\u00e8mes de fichiers. J'ai utilis\u00e9<\/p>\n

pour comprendre quelles op\u00e9rations de disque sont utilis\u00e9es dans les syst\u00e8mes de fichiers ext4 et XFS. Les deux produisent des commandes d'\u00e9criture sur disque habituelles, tant pour le contenu des fichiers que pour le journal du syst\u00e8me de fichiers, qui vidangent le cache et terminent le travail en ex\u00e9cutant une \u00e9criture FUA (Force Unit Access, \u00e9criture des donn\u00e9es directement sur le disque, contournant le cache) dans le journal. Il est probable qu'ils agissent ainsi pour confirmer le fait de l'op\u00e9ration. Sur les disques qui ne prennent pas en charge FUA, cela entra\u00eene deux vidanges de cache. Mes exp\u00e9riences ont montr\u00e9 que blktrace<\/a><\/noindex> un peu plus rapide fdatasync()<\/code> . L'utilitaire fsync()<\/code>indique que blktrace<\/code> \u00e9crit g\u00e9n\u00e9ralement moins de donn\u00e9es sur le disque (dans ext4 fdatasync()<\/code> \u00e9crit 20 Ko, tandis que fsync()<\/code> \u2014 \u00e9crit 16 Ko). De plus, j'ai d\u00e9couvert que XFS est l\u00e9g\u00e8rement plus rapide qu'ext4. Et ici, avec l'aide de fdatasync()<\/code> j'ai pu d\u00e9terminer que blktrace<\/code> vidange moins de donn\u00e9es sur le disque (4 Ko dans XFS). fdatasync()<\/code> Situations ambigu\u00ebs qui surviennent lors de l'utilisation de fsync()<\/p>\n

Je peux me souvenir de trois situations ambigu\u00ebs concernant<\/h2>\n

\n, auxquelles j'ai \u00e9t\u00e9 confront\u00e9 dans la pratique. fsync()<\/code>Le premier de ces cas s'est produit en 2008. \u00c0 l'\u00e9poque, l'interface de Firefox 3 \u00ab gelait \u00bb lorsque de nombreux fichiers \u00e9taient \u00e9crits sur disque. Le probl\u00e8me \u00e9tait que, dans la mise en \u0153uvre de l'interface, une base de donn\u00e9es SQLite \u00e9tait utilis\u00e9e pour stocker les informations sur son \u00e9tat. Apr\u00e8s chaque modification survenue dans l'interface, la fonction<\/p>\n

, qui garantissait un bon stockage des donn\u00e9es, \u00e9tait appel\u00e9e. Dans le syst\u00e8me de fichiers ext3 utilis\u00e9 alors, la fonction fsync()<\/code>, ce qui offrait de bonnes garanties de stockage durable des donn\u00e9es. Dans le syst\u00e8me de fichiers ext3 utilis\u00e9 \u00e0 l'\u00e9poque, la fonction fsync()<\/code> elle enregistrait toutes les \u00ab pages sales \u00bb dans le syst\u00e8me sur le disque, et pas seulement celles qui \u00e9taient li\u00e9es au fichier concern\u00e9. Cela signifiait qu'un clic sur un bouton dans Firefox pouvait d\u00e9clencher l'\u00e9criture de plusieurs m\u00e9gaoctets de donn\u00e9es sur le disque magn\u00e9tique, ce qui pouvait prendre plusieurs secondes. La solution \u00e0 ce probl\u00e8me, comme je l'ai compris de ce fichier) :<\/a><\/noindex> le mat\u00e9riel, consistait \u00e0 d\u00e9placer le travail de la base de donn\u00e9es vers des t\u00e2ches de fond asynchrones. Cela signifie qu'auparavant, Firefox appliquait des exigences beaucoup plus strictes en mati\u00e8re de durabilit\u00e9 du stockage des donn\u00e9es, que cela n'\u00e9tait r\u00e9ellement n\u00e9cessaire, et que les particularit\u00e9s du syst\u00e8me de fichiers ext3 aggravaient ce probl\u00e8me.<\/p>\n

La deuxi\u00e8me incoh\u00e9rence est survenue en 2009. \u00c0 l'\u00e9poque, apr\u00e8s une d\u00e9faillance du syst\u00e8me, les utilisateurs du nouveau syst\u00e8me de fichiers ext4 ont constat\u00e9 que de nombreux fichiers r\u00e9cemment cr\u00e9\u00e9s avaient une longueur nulle, tandis qu'avec l'ancien syst\u00e8me de fichiers ext3, cela ne se produisait pas. Dans le paragraphe pr\u00e9c\u00e9dent, je parlais du fait qu'ext3 enregistrait trop de donn\u00e9es sur le disque, ce qui ralentissait consid\u00e9rablement le syst\u00e8me fsync()<\/code>. Afin d'am\u00e9liorer la situation, ext4 n'enregistre sur le disque que les \u00ab pages sales \u00bb qui sont li\u00e9es \u00e0 un fichier sp\u00e9cifique. Les donn\u00e9es des autres fichiers restent en m\u00e9moire beaucoup plus longtemps qu'avec ext3. Cela a \u00e9t\u00e9 fait pour am\u00e9liorer les performances (par d\u00e9faut, les donn\u00e9es restent dans cet \u00e9tat pendant 30 secondes, ce qui peut \u00eatre ajust\u00e9 \u00e0 l'aide de dirty_expire_centisecs<\/a><\/noindex>; ici<\/a><\/noindex> , des ressources suppl\u00e9mentaires peuvent \u00eatre trouv\u00e9es \u00e0 ce sujet). Cela signifie qu'un grand volume de donn\u00e9es peut \u00eatre irr\u00e9m\u00e9diablement perdu apr\u00e8s une d\u00e9faillance. La solution \u00e0 ce probl\u00e8me consiste \u00e0 utiliser fsync()<\/code> dans les applications n\u00e9cessitant une durabilit\u00e9 des donn\u00e9es et maximisant leur protection contre les cons\u00e9quences des d\u00e9faillances. La fonction fsync()<\/code> fonctionne sous ext4 de mani\u00e8re beaucoup plus efficace que sous ext3. L'inconv\u00e9nient de cette approche est qu'elle ralentit, comme auparavant, l'ex\u00e9cution de certaines op\u00e9rations, comme l'installation de programmes. Pour les d\u00e9tails, veuillez consulter ici<\/a><\/noindex> et ici<\/a><\/noindex>.<\/p>\n

Le troisi\u00e8me probl\u00e8me relatif fsync()<\/code>, est survenu en 2018. \u00c0 cette \u00e9poque, dans le cadre du projet PostgreSQL, il a \u00e9t\u00e9 constat\u00e9 que si la fonction fsync()<\/code> rencontraient une erreur, elles marquaient les \u00ab pages sales \u00bb comme \u00ab propres \u00bb. En cons\u00e9quence, les appels suivants fsync()<\/code> Rien n'est fait avec de telles pages. En raison de cela, les pages modifi\u00e9es sont stock\u00e9es en m\u00e9moire et ne sont jamais \u00e9crites sur le disque. C'est une v\u00e9ritable catastrophe, car l'application croira que certaines donn\u00e9es sont enregistr\u00e9es sur le disque, alors qu'en r\u00e9alit\u00e9 ce n'est pas le cas. De tels \u00e9checs fsync()<\/code> sont rares, l'application dans de telles situations peut \u00e0 peine faire quelque chose pour lutter contre le probl\u00e8me. De nos jours, lorsque cela se produit, PostgreSQL et d'autres applications se terminent de mani\u00e8re inattendue. Ici<\/a><\/noindex>, dans le mat\u00e9riel \u00ab Les applications peuvent-elles r\u00e9cup\u00e9rer apr\u00e8s des \u00e9checs d'fsync ? \u00bb, ce probl\u00e8me est explor\u00e9 dans tous les d\u00e9tails. Actuellement, la meilleure solution \u00e0 ce probl\u00e8me est d'utiliser Direct I\/O avec le drapeau O_SYNC<\/code> ou avec le drapeau O_DSYNC<\/code>. Avec cette approche, le syst\u00e8me signalera les erreurs qui peuvent survenir lors de l'ex\u00e9cution de certaines op\u00e9rations d'\u00e9criture de donn\u00e9es, mais cela n\u00e9cessite que l'application g\u00e8re les tampons par elle-m\u00eame. Pour plus de d\u00e9tails, lisez ici<\/a><\/noindex> et ici<\/a><\/noindex>.<\/p>\n

L'ouverture de fichiers avec les drapeaux O_SYNC et O_DSYNC<\/h2>\n

\nRevenons \u00e0 la discussion sur les m\u00e9canismes Linux garantissant la conservation des donn\u00e9es. En effet, il s'agit de l'utilisation du drapeau O_SYNC<\/code> ou du drapeau O_DSYNC<\/code> lors de l'ouverture de fichiers \u00e0 l'aide de l'appel syst\u00e8me open()<\/a><\/noindex>. Avec cette approche, chaque op\u00e9ration d'\u00e9criture de donn\u00e9es est effectu\u00e9e comme si apr\u00e8s chaque commande write()<\/code> le syst\u00e8me recevait, respectivement, les commandes fsync()<\/code> et fdatasync()<\/code>. Il y a de la sp\u00e9cification POSIX.<\/a><\/noindex> Ceci est appel\u00e9 \u00ab Compl\u00e9tion des int\u00e9grit\u00e9s de fichier d'E\/S synchronis\u00e9es \u00bb et \u00ab Compl\u00e9tion de l'int\u00e9grit\u00e9 des donn\u00e9es \u00bb. L'avantage principal de cette approche est que pour garantir l'int\u00e9grit\u00e9 des donn\u00e9es, il ne faut effectuer qu'un seul appel syst\u00e8me, et non deux (par exemple \u2014 write()<\/code> et fdatasync()<\/code>). Le principal inconv\u00e9nient de cette approche est que toutes les op\u00e9rations d'\u00e9criture utilisant le descripteur de fichier correspondant seront synchronis\u00e9es, ce qui peut limiter les possibilit\u00e9s de structuration du code de l'application.<\/p>\n

L'utilisation de Direct I\/O avec le drapeau O_DIRECT<\/h2>\n

\nAppel syst\u00e8me open()<\/code> soutient le drapeau O_DIRECT<\/code>, qui est con\u00e7u pour effectuer des op\u00e9rations d'entr\u00e9e\/sortie en contournant le cache du syst\u00e8me d'exploitation, interagissant directement avec le disque. Cela signifie, dans de nombreux cas, que les commandes d'\u00e9criture \u00e9mises par le programme seront directement traduites en commandes destin\u00e9es \u00e0 travailler avec le disque. Mais en g\u00e9n\u00e9ral, ce m\u00e9canisme n'est pas un remplacement des fonctionnalit\u00e9s fsync()<\/code> ou fdatasync()<\/code>. En effet, le disque lui-m\u00eame peut retarder ou mettre en cache<\/a><\/noindex> les commandes d'enregistrement de donn\u00e9es appropri\u00e9es. Et, ce qui est pire, dans certains cas particuliers, les op\u00e9rations d'entr\u00e9e-sortie effectu\u00e9es en utilisant le drapeau O_DIRECT<\/code>, sont transmises<\/a><\/noindex> en op\u00e9rations tampons traditionnelles. Le moyen le plus simple de r\u00e9soudre ce probl\u00e8me est d'ouvrir les fichiers avec le drapeau O_DSYNC<\/code>, ce qui signifie qu'apr\u00e8s chaque op\u00e9ration d'\u00e9criture, un appel sera effectu\u00e9 fdatasync()<\/code>.<\/p>\n

Il s'av\u00e8re qu'un \u00ab chemin rapide \u00bb a r\u00e9cemment \u00e9t\u00e9 ajout\u00e9 dans le syst\u00e8me de fichiers XFS pour O_DIRECT|O_DSYNC<\/code>-l'\u00e9criture des donn\u00e9es. Si un bloc est r\u00e9\u00e9crit en utilisant O_DIRECT|O_DSYNC<\/code>, alors XFS, au lieu de vider le cache, ex\u00e9cutera la commande d'\u00e9criture FUA si le p\u00e9riph\u00e9rique le prend en charge. Je m'en suis assur\u00e9 en utilisant l'outil blktrace<\/code> dans le syst\u00e8me Linux 5.4\/Ubuntu 20.04. Cette approche devrait \u00eatre plus efficace, car elle \u00e9crit un minimum de donn\u00e9es sur le disque et utilise une seule op\u00e9ration au lieu de deux (\u00e9criture et vidage du cache). J'ai trouv\u00e9 un lien vers un patch<\/a><\/noindex> un noyau de 2018 dans lequel ce m\u00e9canisme a \u00e9t\u00e9 impl\u00e9ment\u00e9. Il y a une discussion concernant l'utilisation de cette optimisation dans d'autres syst\u00e8mes de fichiers, mais, autant que je sache, XFS est le seul syst\u00e8me de fichiers qui le prend en charge pour le moment.<\/p>\n

La fonction sync_file_range()<\/h2>\n

\nDans Linux, il existe un appel syst\u00e8me sync_file_range()<\/a><\/noindex>, qui permet de vider vers le disque seulement une partie du fichier, au lieu de tout le fichier. Cet appel initie une vidange asynchrone des donn\u00e9es et n'attend pas sa fin. Mais dans la documentation de sync_file_range()<\/code> il est dit que cette commande est \u00ab tr\u00e8s dangereuse \u00bb. Son utilisation n'est pas recommand\u00e9e. Les particularit\u00e9s et dangers sync_file_range()<\/code> sont tr\u00e8s bien d\u00e9crits dans ce<\/a><\/noindex> mat\u00e9riau. En particulier, apparemment, cet appel utilise RocksDB pour g\u00e9rer quand le noyau vide les donn\u00e9es \u00ab sales \u00bb sur le disque. Mais l\u00e0, pour garantir un stockage persistant des donn\u00e9es, il utilise aussi fdatasync()<\/code>. Il y a le code<\/a><\/noindex> RocksDB a des commentaires int\u00e9ressants \u00e0 ce sujet. Par exemple, il semble que l'appel sync_file_range()<\/code> lors de l'utilisation de ZFS ne m\u00e8ne pas \u00e0 une vidange des donn\u00e9es sur le disque. L'exp\u00e9rience me dit que le code utilis\u00e9 rarement contient peut-\u00eatre des erreurs. Je conseillerais donc de ne pas utiliser cet appel syst\u00e8me sans n\u00e9cessit\u00e9 absolue.<\/p>\n

Appels syst\u00e8me qui aident \u00e0 garantir un stockage persistant des donn\u00e9es<\/h2>\n

\nJe suis arriv\u00e9 \u00e0 la conclusion qu'il existe trois approches pour effectuer des op\u00e9rations d'entr\u00e9e\/sortie qui garantissent un stockage durable des donn\u00e9es. Chacune d'elles n\u00e9cessite d'appeler une fonction fsync()<\/code> dans le r\u00e9pertoire o\u00f9 le fichier a \u00e9t\u00e9 cr\u00e9\u00e9. Voici ces approches :<\/p>\n

    \n
  1. L'appel de la fonction fdatasync()<\/code> ou fsync()<\/code> apr\u00e8s la fonction write()<\/code> (il est pr\u00e9f\u00e9rable d'utiliser fdatasync()<\/code>).<\/li>\n
  2. Le travail avec un descripteur de fichier ouvert avec le drapeau O_DSYNC<\/code> ou O_SYNC<\/code> (id\u00e9alement \u2014 avec le drapeau O_DSYNC<\/code>).<\/li>\n
  3. L'utilisation de la commande pwritev2()<\/code> avec le drapeau RWF_DSYNC<\/code> ou RWF_SYNC<\/code> (pr\u00e9f\u00e9rable \u2014 avec le drapeau RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Notes sur les performances<\/h2>\n

    \nJe n'ai pas effectu\u00e9 de mesurages pr\u00e9cis des performances des diff\u00e9rents m\u00e9canismes que j'ai examin\u00e9s. Les diff\u00e9rences de vitesse que j'ai remarqu\u00e9es sont assez peu significatives. Cela signifie que je peux me tromper, et que d'autres conditions pourraient donner des r\u00e9sultats diff\u00e9rents. D'abord, je parlerai de ce qui a le plus d'impact sur les performances, puis de ce qui en a moins.<\/p>\n

      \n
    1. La r\u00e9\u00e9criture des donn\u00e9es d'un fichier est plus rapide que l'ajout de donn\u00e9es \u00e0 un fichier (le gain de performance peut aller de 2 \u00e0 100 %). L'ajout de donn\u00e9es \u00e0 un fichier n\u00e9cessite des modifications suppl\u00e9mentaires des m\u00e9tadonn\u00e9es du fichier, m\u00eame apr\u00e8s l'appel syst\u00e8me fallocate()<\/code>, mais l'ampleur de cet effet peut varier. Je recommande, pour garantir la meilleure performance, d'appeler fallocate()<\/code> pour r\u00e9server l'espace n\u00e9cessaire. Ensuite, cet espace doit \u00eatre explicitement rempli de z\u00e9ros et appeler fsync()<\/code>. Cela permet aux blocs appropri\u00e9s dans le syst\u00e8me de fichiers d'\u00eatre marqu\u00e9s comme \"r\u00e9serv\u00e9s\", plut\u00f4t que comme \"non r\u00e9serv\u00e9s\". Cela donne une l\u00e9g\u00e8re am\u00e9lioration de la performance (environ 2 %). De plus, sur certains disques, la premi\u00e8re op\u00e9ration d'acc\u00e8s \u00e0 un bloc peut prendre plus de temps que les autres. Cela signifie que le remplissage de l'espace avec des z\u00e9ros peut entra\u00eener une am\u00e9lioration significative des performances (environ 100 %). En particulier, cela peut se produire avec les disques AWS EBS<\/a><\/noindex> (ce sont des donn\u00e9es non officielles, je n'ai pas pu les confirmer). Il en va de m\u00eame pour les stockages GCP Persistent Disk<\/a><\/noindex> (et cela, c'est d\u00e9j\u00e0 une information officielle, confirm\u00e9e par des tests). D'autres sp\u00e9cialistes ont fait des observations similaires<\/a><\/noindex>, concernant diff\u00e9rents disques.<\/li>\n
    2. Moins il y a d'appels syst\u00e8me, plus la performance est \u00e9lev\u00e9e (le gain peut \u00eatre d'environ 5 %). Il semble que l'appel open()<\/code> avec le drapeau O_DSYNC<\/code> ou l'appel pwritev2()<\/code> avec le drapeau RWF_SYNC<\/code> appel plus rapide fdatasync()<\/code>. Je soup\u00e7onne que cela est d\u00fb au fait qu'avec cette approche, le nombre d'appels syst\u00e8me n\u00e9cessaires pour r\u00e9soudre la m\u00eame t\u00e2che est r\u00e9duit (un appel au lieu de deux). Mais la diff\u00e9rence de performance est tr\u00e8s faible, donc vous pouvez tout \u00e0 fait l'ignorer et utiliser dans l'application ce qui ne compliquera pas sa logique.<\/li>\n<\/ol>\n

      \nSi le sujet du stockage durable des donn\u00e9es vous int\u00e9resse, voici quelques ressources utiles :<\/p>\n