{"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\/es\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Almacenamiento de datos sostenible y API de archivos en Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Yo, al investigar la persistencia del almacenamiento de datos en sistemas en la nube, decid\u00ed ponerme a prueba y asegurarme de que entiendo los conceptos b\u00e1sicos. Yo comenc\u00e9 leyendo la especificaci\u00f3n NVMe<\/a><\/noindex> para entender cu\u00e1les son las garant\u00edas relacionadas con el almacenamiento persistente de datos (es decir, las garant\u00edas de que los datos estar\u00e1n disponibles despu\u00e9s de una falla del sistema) que nos ofrecen los discos NVMe. Mis principales conclusiones son las siguientes: se debe considerar que los datos est\u00e1n da\u00f1ados desde el momento en que se da la orden de escritura y hasta que se complete su escritura en el medio de informaci\u00f3n. Sin embargo, en la mayor\u00eda de los programas de escritura de datos, se utilizan tranquilamente llamadas al sistema.<\/p>\n

En este material, investigo los mecanismos de almacenamiento persistente de datos que proporcionan las API de archivos de Linux. Parece que todo deber\u00eda ser simple aqu\u00ed: el programa llama al comando write()<\/code>, y despu\u00e9s de que este comando finaliza su trabajo, los datos deber\u00edan ser almacenados de forma segura en el disco. Pero write()<\/code> solo copia los datos de la aplicaci\u00f3n en la cach\u00e9 del n\u00facleo, que se encuentra en la memoria RAM. Para forzar al sistema a escribir los datos en el disco, se deben usar algunos mecanismos adicionales.<\/p>\n

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

En general, este material es un conjunto de notas sobre lo que aprend\u00ed en el tema que me interesa. Si quiero resumir lo m\u00e1s importante, dir\u00eda que para organizar un almacenamiento persistente de datos se debe utilizar el comando fdatasync()<\/code> o abrir archivos con la bandera O_DSYNC<\/code>. Si te interesa conocer en detalle qu\u00e9 sucede con los datos en el camino del c\u00f3digo de programa al disco, echa un vistazo a esto<\/a><\/noindex> el art\u00edculo.
\n<\/a><\/noindex><\/p>\n

Las caracter\u00edsticas del uso de la funci\u00f3n write()<\/h2>\n

\nLlamada del sistema write()<\/code> est\u00e1n definidas en el est\u00e1ndar IEEE POSIX<\/a><\/noindex> como un intento de escribir datos en un descriptor de archivo. Despu\u00e9s de la finalizaci\u00f3n exitosa write()<\/code> de la operaci\u00f3n, la lectura de datos debe devolver exactamente esos bytes que fueron escritos previamente, incluso si los datos est\u00e1n siendo accedidos desde otros procesos o hilos (aqu\u00ed<\/a><\/noindex> la secci\u00f3n correspondiente del est\u00e1ndar POSIX). Aqu\u00ed<\/a><\/noindex>, en la secci\u00f3n dedicada a la interacci\u00f3n de los hilos con operaciones de archivo convencionales, hay una nota que dice que si cada uno de los dos hilos llama a estas funciones, cada llamada debe ver o todas las consecuencias designadas que resultan de la ejecuci\u00f3n de la otra llamada, o no ver ninguna consecuencia en absoluto. Esto permite concluir que todas las operaciones de entrada\/salida de archivos deben mantener un bloqueo del recurso con el que trabajan.<\/p>\n

\u00bfSignifica esto que la operaci\u00f3n write()<\/code> es at\u00f3mica? Desde un punto de vista t\u00e9cnico \u2014 s\u00ed. Las operaciones de lectura de datos deben devolver ya sea todo, o nada de lo que ha sido escrito mediante write()<\/code>. Pero la operaci\u00f3n write()<\/code>, de acuerdo con el est\u00e1ndar, no necesariamente debe completar escribiendo todo lo que se le propuso escribir. Se le permite escribir solo una parte de los datos. Por ejemplo, podemos tener dos hilos, cada uno de los cuales adjunta 1024 bytes a un archivo descrito por el mismo descriptor de archivo. Desde el punto de vista del est\u00e1ndar, es aceptable que el resultado de cada operaci\u00f3n de escritura solo pueda adjuntar un byte al archivo. Estas operaciones seguir\u00e1n siendo at\u00f3micas, pero despu\u00e9s de que se completen, los datos que escribieron en el archivo estar\u00e1n mezclados. Aqu\u00ed<\/a><\/noindex> una discusi\u00f3n muy interesante sobre este tema en Stack Overflow.<\/p>\n

Las funciones fsync() y fdatasync()<\/h2>\n

\nLa forma m\u00e1s sencilla de volcar datos en el disco es a trav\u00e9s de la llamada a la funci\u00f3n fsync()<\/a><\/noindex>. Esta funci\u00f3n solicita al sistema operativo que transfiera todos los bloques modificados desde la cach\u00e9 al disco. Esto incluye todos los metadatos del archivo (tiempo de acceso, tiempo de modificaci\u00f3n del archivo, etc.). Creo que la necesidad de estos metadatos surge raramente, por lo que, si sabes que no son importantes para ti, puedes utilizar la funci\u00f3n fdatasync()<\/code>. Hay ayuda<\/a><\/noindex> en fdatasync()<\/code> indica que durante la ejecuci\u00f3n de esta funci\u00f3n se guarda en disco un volumen de metadatos que es \"necesario para el correcto funcionamiento de las siguientes operaciones de lectura de datos\". Y esto es precisamente lo que preocupa a la mayor\u00eda de las aplicaciones.<\/p>\n

Uno de los problemas que puede surgir aqu\u00ed es que estos mecanismos no garantizan que se pueda encontrar el archivo despu\u00e9s de un posible fallo. En particular, al crear un nuevo archivo, es necesario llamar a fsync()<\/code> para el directorio que lo contiene. De lo contrario, despu\u00e9s de un fallo, puede suceder que este archivo no exista. La raz\u00f3n de esto se debe a que en UNIX, debido al uso de enlaces duros, un archivo puede existir en varios directorios. Por lo tanto, al invocar fsync()<\/code> no hay forma de que un archivo se entere de qu\u00e9 directorio espec\u00edfico tambi\u00e9n necesita ser volcado en el disco (aqu\u00ed<\/a><\/noindex> se puede leer m\u00e1s sobre esto). Parece que el sistema de archivos ext4 es capaz autom\u00e1ticamente<\/a><\/noindex> aplicar fsync()<\/code> a los directorios que contienen los archivos correspondientes, pero en el caso de otros sistemas de archivos, esto puede no ser as\u00ed.<\/p>\n

Este mecanismo puede ser implementado de diferentes maneras en varios sistemas de archivos. Yo utilic\u00e9 blktrace<\/a><\/noindex> para averiguar cu\u00e1les operaciones de disco se utilizan en los sistemas de archivos ext4 y XFS. Ambos emiten comandos de escritura en disco est\u00e1ndar tanto para el contenido de los archivos como para el registro del sistema de archivos, vac\u00edan la cach\u00e9 y finalizan el trabajo ejecutando una escritura FUA (Acceso forzado a la unidad, escritura de datos directamente en el disco, omitiendo la cach\u00e9) en el registro. Probablemente, hacen esto para confirmar el hecho de que se realiz\u00f3 la operaci\u00f3n. En discos que no soportan FUA, esto provoca dos vaciados de cach\u00e9. Mis experimentos mostraron que fdatasync()<\/code> un poco m\u00e1s r\u00e1pido fsync()<\/code>. Utilidad blktrace<\/code> indica que fdatasync()<\/code> generalmente escribe menos datos en el disco (en ext4 fsync()<\/code> escribe 20 KiB, y fdatasync()<\/code> \u2014 16 KiB). Adem\u00e1s, descubr\u00ed que XFS es un poco m\u00e1s r\u00e1pido que ext4. Y aqu\u00ed, con la ayuda de blktrace<\/code> logr\u00e9 averiguar que fdatasync()<\/code> vuelca menos datos al disco (4 KiB en XFS).<\/p>\n

Situaciones ambiguas que surgen al usar fsync()<\/h2>\n

\nPuedo recordar tres situaciones ambiguas relacionadas fsync()<\/code>, con las que me encontr\u00e9 en la pr\u00e1ctica.<\/p>\n

El primer caso ocurri\u00f3 en 2008. En ese momento, la interfaz de Firefox 3 \"se colgaba\" si se realizaba la escritura en disco de una gran cantidad de archivos. El problema resid\u00eda en que en la implementaci\u00f3n de la interfaz se utilizaba una base de datos SQLite para almacenar informaci\u00f3n sobre su estado. Despu\u00e9s de cada cambio en la interfaz, se llamaba a la funci\u00f3n fsync()<\/code>, lo que daba buenas garant\u00edas de almacenamiento persistente de datos. En el sistema de archivos ext3 que se utilizaba entonces, la funci\u00f3n fsync()<\/code> reinici\u00f3 el disco con todas las p\u00e1ginas \"sucias\" en el sistema, y no solo aquellas relacionadas con el archivo correspondiente. Esto significaba que un clic en el bot\u00f3n de Firefox pod\u00eda iniciar la escritura de megabytes de datos en el disco magn\u00e9tico, lo que pod\u00eda tardar muchos segundos. La soluci\u00f3n al problema, seg\u00fan entend\u00ed de esto<\/a><\/noindex> el material, consist\u00eda en trasladar el trabajo con la base de datos a tareas as\u00edncronas en segundo plano. Esto implica que antes en Firefox se implementaron requisitos m\u00e1s estrictos para la persistencia del almacenamiento de datos de lo que realmente era necesario, y las caracter\u00edsticas del sistema de archivos ext3 solo agravaron este problema.<\/p>\n

La segunda discrepancia ocurri\u00f3 en 2009. Entonces, despu\u00e9s de una falla en el sistema, los usuarios del nuevo sistema de archivos ext4 se encontraron con que muchos archivos reci\u00e9n creados ten\u00edan una longitud cero, mientras que no ocurri\u00f3 lo mismo con el sistema de archivos m\u00e1s antiguo ext3. En el p\u00e1rrafo anterior, mencion\u00e9 que ext3 volcaba demasiados datos al disco, lo que ralentizaba considerablemente el rendimiento fsync()<\/code>. Para mejorar la situaci\u00f3n, en ext4 solo se vuelcan al disco aquellas p\u00e1ginas \"sucias\" que est\u00e1n relacionadas con un archivo espec\u00edfico. Y los datos de otros archivos permanecen en memoria durante mucho m\u00e1s tiempo que con ext3. Esto se hizo para mejorar el rendimiento (por defecto, los datos permanecen en este estado 30 segundos, se puede ajustar esto con dirty_expire_centisecs<\/a><\/noindex>; aqu\u00ed<\/a><\/noindex> , se pueden encontrar materiales adicionales sobre esto). Esto implica que un gran volumen de datos puede perderse permanentemente tras un fallo. La soluci\u00f3n a este problema radica en utilizar fsync()<\/code> en aplicaciones que necesitan garantizar la persistencia del almacenamiento de datos y maximizar su protecci\u00f3n contra las consecuencias de fallos. La funci\u00f3n fsync()<\/code> funciona con ext4 mucho m\u00e1s eficazmente que con ext3. La desventaja de este enfoque es que, al igual que antes, ralentiza la realizaci\u00f3n de algunas operaciones, como la instalaci\u00f3n de programas. Para m\u00e1s detalles, consulte aqu\u00ed<\/a><\/noindex> y aqu\u00ed<\/a><\/noindex>.<\/p>\n

El tercer problema relacionado con fsync()<\/code>, surgi\u00f3 en 2018. Entonces, en el marco del proyecto PostgreSQL, se determin\u00f3 que si la funci\u00f3n fsync()<\/code> se encuentra con un error, marca las p\u00e1ginas \"sucias\" como \"limpias\". Como resultado, las siguientes llamadas fsync()<\/code> No se hacen nada con p\u00e1ginas como estas. Debido a esto, las p\u00e1ginas modificadas se mantienen en memoria y nunca se escriben en el disco. Esto es una verdadera cat\u00e1strofe, ya que la aplicaci\u00f3n considerar\u00e1 que algunos datos se han escrito en el disco, cuando en realidad no ser\u00e1 as\u00ed. Tales fallas fsync()<\/code> son raras, y la aplicaci\u00f3n en tales situaciones casi no puede hacer nada para combatir el problema. En nuestros d\u00edas, cuando eso ocurre, PostgreSQL y otras aplicaciones se cierran inesperadamente. Aqu\u00ed<\/a><\/noindex>, en el material \"\u00bfPueden las aplicaciones recuperarse de fallos de fsync?\", este problema se investiga en todos los detalles. Actualmente, la mejor soluci\u00f3n a este problema es usar Direct I\/O con la bandera O_SYNC<\/code> o con la bandera O_DSYNC<\/code>. Con este enfoque, el sistema reportar\u00e1 los errores que puedan surgir al ejecutar operaciones espec\u00edficas de escritura de datos, pero este enfoque requiere que la aplicaci\u00f3n gestione los buffers por s\u00ed misma. Lea m\u00e1s sobre esto aqu\u00ed<\/a><\/noindex> y aqu\u00ed<\/a><\/noindex>.<\/p>\n

Apertura de archivos utilizando las banderas O_SYNC y O_DSYNC<\/h2>\n

\nVolvemos a discutir los mecanismos de Linux que proporcionan almacenamiento de datos persistente. En particular, se refiere al uso de la bandera O_SYNC<\/code> o de la bandera O_DSYNC<\/code> al abrir archivos utilizando la llamada del sistema open()<\/a><\/noindex>. Con este enfoque, cada operaci\u00f3n de escritura de datos se realiza como si despu\u00e9s de cada comando write()<\/code> se dieran al sistema, respectivamente, comandos fsync()<\/code> y fdatasync()<\/code>. Hay de la especificaci\u00f3n POSIX<\/a><\/noindex> esto se llama \"Finalizaci\u00f3n de Integridad de Archivos de Entrada\/Salida Sincronizados\" y \"Finalizaci\u00f3n de Integridad de Datos\". La principal ventaja de este enfoque es que solo se necesita realizar una llamada al sistema para garantizar la integridad de los datos, en lugar de dos (por ejemplo, write()<\/code> y fdatasync()<\/code>). La principal desventaja de este enfoque es que todas las operaciones de escritura que utilicen el descriptor de archivo correspondiente estar\u00e1n sincronizadas, lo que puede limitar las posibilidades de estructuraci\u00f3n del c\u00f3digo de la aplicaci\u00f3n.<\/p>\n

El uso de Direct I\/O con la bandera O_DIRECT<\/h2>\n

\nLlamada del sistema open()<\/code> soporta la bandera O_DIRECT<\/code>, que est\u00e1 dise\u00f1ada para realizar operaciones de entrada\/salida, interactuando directamente con el disco, omitiendo la cach\u00e9 del sistema operativo. Esto, en muchos casos, significa que los comandos de escritura emitidos por el programa se traducir\u00e1n directamente en comandos dirigidos a trabajar con el disco. Pero, en general, este mecanismo no reemplaza las funciones fsync()<\/code> o fdatasync()<\/code>. El hecho es que el propio disco puede retrasar o almacenar en cach\u00e9<\/a><\/noindex> los comandos correspondientes para la escritura de datos. Y, lo que es peor, en algunos casos especiales, las operaciones de entrada y salida realizadas utilizando la bandera O_DIRECT<\/code>, se trasladan<\/a><\/noindex> a operaciones de escritura en b\u00fafer tradicionales. La forma m\u00e1s f\u00e1cil de resolver este problema es abrir archivos tambi\u00e9n con la bandera O_DSYNC<\/code>, lo que significa que cada operaci\u00f3n de escritura ir\u00e1 seguida de una llamada fdatasync()<\/code>.<\/p>\n

Resulta que en el sistema de archivos XFS se ha a\u00f1adido recientemente un \"atajo\" para O_DIRECT|O_DSYNC<\/code>-la escritura de datos. Si se vuelve a escribir un bloque utilizando O_DIRECT|O_DSYNC<\/code>, entonces XFS, en lugar de vaciar el cach\u00e9, ejecutar\u00e1 el comando FUA de escritura si el dispositivo lo soporta. Me di cuenta de esto al usar la herramienta blktrace<\/code> en Linux 5.4\/Ubuntu 20.04. Este enfoque deber\u00eda ser m\u00e1s eficiente, ya que al utilizarlo se escribe en el disco una cantidad m\u00ednima de datos y se aplica una sola operaci\u00f3n, no dos (escritura y vaciado del cach\u00e9). Encontr\u00e9 un enlace a parche<\/a><\/noindex> un n\u00facleo de 2018 en el que se implement\u00f3 este mecanismo. All\u00ed hay una discusi\u00f3n sobre la aplicaci\u00f3n de esta optimizaci\u00f3n en otros sistemas de archivos, pero, por lo que s\u00e9, XFS es hasta ahora el \u00fanico sistema de archivos que lo soporta.<\/p>\n

La funci\u00f3n sync_file_range()<\/h2>\n

\nEn Linux hay una llamada al sistema sync_file_range()<\/a><\/noindex>, que permite vaciar en disco solo una parte del archivo, no todo el archivo. Esta llamada inicia un vaciado as\u00edncrono de datos y no espera a que se complete. Pero en la documentaci\u00f3n de sync_file_range()<\/code> se menciona que este comando es \"muy peligroso\". No se recomienda su uso. Las caracter\u00edsticas y peligros sync_file_range()<\/code> est\u00e1n muy bien descritos en este<\/a><\/noindex> el material. En particular, parece que esta llamada utiliza RocksDB para gestionar cu\u00e1ndo el n\u00facleo vac\u00eda los datos \"sucios\" en el disco. Pero al mismo tiempo, all\u00ed, para garantizar el almacenamiento persistente de datos, se emplea tambi\u00e9n fdatasync()<\/code>. Hay el c\u00f3digo<\/a><\/noindex> RocksDB tiene comentarios interesantes sobre este tema. Por ejemplo, parece que la llamada sync_file_range()<\/code> al usar ZFS no provoca el vaciado de datos en el disco. La experiencia me indica que el c\u00f3digo que se utiliza raramente puede contener errores. Por lo tanto, recomendar\u00eda no utilizar esta llamada al sistema sin necesidad extrema.<\/p>\n

Llamadas al sistema que ayudan a garantizar el almacenamiento persistente de datos.<\/h2>\n

\nHe llegado a la conclusi\u00f3n de que, para realizar operaciones de entrada\/salida que garanticen un almacenamiento de datos sostenible, se pueden utilizar tres enfoques. Todos ellos requieren invocar la funci\u00f3n fsync()<\/code> para el directorio donde se cre\u00f3 el archivo. Estos son los enfoques:<\/p>\n

    \n
  1. Invocar la funci\u00f3n fdatasync()<\/code> o fsync()<\/code> despu\u00e9s de la funci\u00f3n write()<\/code> (es mejor usar fdatasync()<\/code>).<\/li>\n
  2. Trabajar con el descriptor de archivo abierto con la bandera O_DSYNC<\/code> o O_SYNC<\/code> (es mejor\u2014 con la bandera O_DSYNC<\/code>).<\/li>\n
  3. Usar el comando pwritev2()<\/code> con la bandera RWF_DSYNC<\/code> o RWF_SYNC<\/code> (es preferible\u2014 con la bandera RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Notas sobre rendimiento<\/h2>\n

    \nNo he realizado una medici\u00f3n minuciosa del rendimiento de los diversos mecanismos que he investigado. Las diferencias en la velocidad que he notado son bastante peque\u00f1as. Esto significa que podr\u00eda estar equivocado y que, bajo otras condiciones, lo mismo podr\u00eda mostrar resultados diferentes. Primero hablar\u00e9 sobre lo que afecta m\u00e1s al rendimiento y luego sobre lo que influye menos en el rendimiento.<\/p>\n

      \n
    1. La sobrescritura de datos del archivo es m\u00e1s r\u00e1pida que la anexi\u00f3n de datos al archivo (la ganancia en rendimiento puede ser del 2 al 100%). Anexar datos a un archivo requiere hacer cambios adicionales en los metadatos del archivo, incluso despu\u00e9s de la llamada al sistema fallocate()<\/code>, pero la magnitud de este efecto puede variar. Recomiendo, para asegurar el mejor rendimiento, invocar fallocate()<\/code> para la asignaci\u00f3n previa del espacio necesario. Luego, este espacio debe llenarse expl\u00edcitamente con ceros y se debe invocar fsync()<\/code>. Gracias a esto, los bloques correspondientes en el sistema de archivos ser\u00e1n marcados como \"asignados\", no como \"no asignados\". Esto proporciona una peque\u00f1a (alrededor del 2%) mejora del rendimiento. Adem\u00e1s, en algunos discos, la primera operaci\u00f3n de acceso a un bloque puede realizarse m\u00e1s lentamente que las dem\u00e1s. Esto significa que llenar el espacio con ceros puede conducir a una mejora significativa (alrededor del 100%) en el rendimiento. En particular, esto puede ocurrir con los discos AWS EBS<\/a><\/noindex> (estos son datos no oficiales, no pude confirmarlos). Lo mismo se aplica a los almacenes GCP Persistent Disk<\/a><\/noindex> (y esta es ya informaci\u00f3n oficial, corroborada por pruebas). Otros expertos han hecho observaciones similares , relacionadas con diferentes discos.<\/a><\/noindex>Cuantos menos llamados al sistema, mayor es el rendimiento (la ganancia puede ser de alrededor del 5%). Parece que invocar<\/li>\n
    2. o invocar open()<\/code> con la bandera O_DSYNC<\/code> es m\u00e1s r\u00e1pido que la llamada pwritev2()<\/code> con la bandera RWF_SYNC<\/code> m\u00e1s r\u00e1pido de llamar fdatasync()<\/code>Sospecho que esto se debe a que, con este enfoque, lo que importa es que para resolver una misma tarea se requieren menos llamadas del sistema (una llamada en lugar de dos). Pero la diferencia en el rendimiento es muy peque\u00f1a, por lo que puedes no prestarle atenci\u00f3n y usar en tu aplicaci\u00f3n lo que no compliqu\u00e9 su l\u00f3gica.<\/li>\n<\/ol>\n

      \nSi te interesa el tema del almacenamiento sostenible de datos, aqu\u00ed tienes algunos materiales \u00fatiles:<\/p>\n