Cuando tu programa Python escribe en un archivo, el retorno de esa llamada a función   ; es simplemente un acuse de recibo. Como desarrolladores, nos basamos en abstracciones de alto nivel para enmascarar las complejas realidades del hardware. Escribimos código que parece determinista e instantáneo, asumiendo a menudo que una llamada a función exitosa equivale a la permanencia física. no garantiza el almacenamiento  Considere este sencillo fragmento de Python que cumple una función en un sistema de procesamiento de transacciones:    Cuando eso  transaction_id = "TXN-987654321" # Open a transaction log in text mode with open("/var/log/transactions.log", "a") as log_file: # Write the commitment record log_file.write(f"COMMIT: {transaction_id}\n") print("Transaction recorded") transaction_id = "TXN-987654321" # Open a transaction log in text mode with open("/var/log/transactions.log", "a") as log_file: # Write the commitment record log_file.write(f"COMMIT: {transaction_id}\n") print("Transaction recorded")  La sentencia   se ejecuta y la aplicación se reanuda, operando bajo el supuesto de que los datos están seguros. Sin embargo, los datos no han llegado al disco. Ni siquiera al sistema de archivos. Simplemente ha comenzado una compleja carrera de relevos a través de seis capas de abstracción distintas, cada una con sus propios búferes y objetivos arquitectónicos. print  En este artículo, describiremos el ciclo de vida técnico de esa carga de datos, es decir, la cadena   a medida que se mueve desde el espacio de usuario de Python hasta el silicio del SSD. "COMMIT: TXN-987654321\n"  [Capa 1]: Espacio de usuario (Python y Libc)  El búfer de aplicación  Nuestro viaje comienza en la memoria de proceso del intérprete de Python. Al llamar   en un archivo abierto en modo texto, Python no suele invocar inmediatamente una llamada al sistema. Los cambios de contexto al núcleo son costosos. En su lugar, Python utiliza un búfer de espacio de usuario para acumular datos. Por defecto, este búfer tiene un tamaño de 8 KB, elegido específicamente para alinearse con el tamaño de página de memoria del sistema operativo subyacente. file.write()  Nuestra carga de datos se encuentra en este búfer de RAM. Es propiedad exclusiva del proceso Python. Si la aplicación finaliza abruptamente, quizás debido a una señal   o un fallo de segmentación, los datos se pierden instantáneamente. Nunca abandonaron la memoria de la aplicación. SIGKILL  El Flush y el envoltorio de Libc  La instrucción   concluye y activa una   automática. Esto posteriormente activa una función   . Python expulsa estos datos y transfiere la carga útil a la biblioteca estándar de C del sistema, como   en Linux.   actúa como la interfaz estandarizada para el kernel. Mientras que funciones de C como   gestionan sus propios búferes de espacio de usuario, la operación de vaciado de Python suele llamar directamente a la     de nivel inferior.   configura los registros de la CPU con el número de descriptor de archivo, el puntero al búfer y la longitud de la carga útil. A continuación, ejecuta una instrucción de la CPU, como   en arquitecturas x86-64, para capturar el kernel. with .close() .flush() glibc libc fwrite función write(2) libc SYSCALL  En este punto, cruzamos el límite del espacio del usuario al espacio del kernel.  [Capa 2]: El límite del núcleo (VFS)  La CPU cambia al modo privilegiado. El kernel de Linux gestiona la interrupción, revisa los registros de la CPU e identifica una solicitud de escritura en un descriptor de archivo. Transfiere la solicitud al   . El VFS actúa como la capa de unificación del kernel. Proporciona una API consistente para el sistema, independientemente de si el almacenamiento subyacente es Ext4, XFS, NFS o un disco RAM. Sistema de Archivos Virtual (VFS)  El VFS realiza comprobaciones iniciales de validez, como la verificación de permisos y el estado del descriptor de archivo. A continuación, utiliza el descriptor de archivo para localizar el controlador del sistema de archivos específico responsable de la ruta, que en este caso es Ext4. El VFS invoca la operación de escritura específica para ese controlador.  [Capa 3]: La caché de páginas (E/S optimista)  Hemos llegado al centro de rendimiento de la pila de almacenamiento de Linux: el   . Page Cache  En Linux, la E/S de archivos se   . Cuando el controlador Ext4 recibe la solicitud de escritura, normalmente no inicia una comunicación inmediata con el disco. En su lugar, se prepara para escribir en la caché de páginas. La caché de páginas es una sección de la RAM del sistema   . Cabe destacar que Ext4 generalmente delega las operaciones de memoria relacionadas con la caché de páginas al subsistema genérico de gestión de memoria del kernel. Lo que sucede a continuación es... asigna fundamentalmente a la memoria dedicada al almacenamiento en caché de datos de archivos  El kernel administra la memoria en unidades de tamaño fijo llamadas   (normalmente 4 KB en configuraciones estándar de Linux). Dado que la carga útil del registro de transacciones es pequeña (   ), cabe completamente en una sola página. El kernel asigna (o localiza) la página de RAM de 4 KB específica que corresponde al desplazamiento actual del archivo. páginas "COMMIT: TXN-987654321\n"  Copia la carga de datos en esta página de memoria.  Marca esta página como   . Una página sucia implica que los datos en la RAM son más recientes que los del almacenamiento persistente. "sucia"    Una vez copiados los datos a la RAM, la llamada al sistema   devuelve   a   , que a su vez regresa a Python. Fundamentalmente, la aplicación recibe una señal de éxito   que se produzca cualquier E/S física. El kernel   , posponiendo la costosa operación del disco a un proceso en segundo plano. Los datos son vulnerables a un pánico del kernel o a un corte de energía. El retorno: write(2) SUCCESS libc antes de prioriza el rendimiento y la latencia sobre la persistencia inmediata  [Capa 4]: El sistema de archivos (Ext4 y JBD2)  Los datos pueden residir en la caché de páginas durante un tiempo considerable. La configuración predeterminada de Linux permite que las páginas corruptas persistan en la RAM hasta 30 segundos. Finalmente, un subproceso del kernel en segundo plano inicia el proceso de escritura diferida para limpiar estas páginas corruptas. El   debe ahora persistir los datos. También debe actualizar los metadatos asociados, como el tamaño del archivo y los punteros a los bloques físicos del disco. Estas estructuras de metadatos existen inicialmente solo en la memoria del sistema. Para evitar la corrupción durante una falla, Ext4 emplea una técnica llamada registro en diario. sistema de archivos Ext4  Antes de que el sistema de archivos actualice permanentemente la estructura de archivos, Ext4 interactúa con su capa de registro, el   . Ext4 suele operar en un modo denominado "registro ordenado". Orquesta la operación enviando distintas solicitudes de escritura a la Capa de Bloque (Capa 5, siguiente sección) en una secuencia específica. JBD2 (Dispositivo de Bloques de Registro)    . Primero, Ext4 envía una solicitud para escribir el contenido de los datos en su ubicación final en el disco. Esto garantiza que los bloques de almacenamiento contengan información válida antes de que cualquier puntero de metadatos los haga referencia. Paso 1: Escritura de datos    . Una vez finalizada la escritura de datos, JBD2 envía una solicitud de escritura para los metadatos. Escribe una descripción de los cambios en un búfer circular reservado en el disco, llamado diario. Esta entrada actúa como confirmación de que la estructura del archivo se actualiza correctamente. Paso 2: Confirmación del diario    . Finalmente, el sistema de archivos vacía los metadatos modificados de la memoria del sistema a su ubicación permanente en las tablas de inodos del disco. Si el sistema falla antes de este paso, el sistema operativo puede reproducir el diario para restaurar la consistencia del sistema de archivos. Paso 3: El punto de control  [Capa 5]: La capa de bloque y el programador de E/S  El sistema de archivos empaqueta sus datos pendientes en una estructura conocida como   (E/S de bloque). Posteriormente, envía esta estructura a la   . Esta capa actúa como controlador de tráfico para el subsistema de almacenamiento. Optimiza el flujo de solicitudes antes de que lleguen al hardware mediante un   , como MQ-Deadline o BFQ. Si el sistema está sometido a una gran carga con miles de pequeñas solicitudes de escritura aleatorias, el programador las intercepta para mejorar la eficiencia. Generalmente realiza dos operaciones clave. bio capa de bloque programador de E/S    . El programador intenta combinar solicitudes adyacentes en menos operaciones de mayor tamaño. Al fusionar varias escrituras pequeñas dirigidas a sectores contiguos del disco, el sistema reduce la cantidad de comandos individuales que debe enviar al dispositivo. Fusionando solicitudes    . El programador también reordena la cola. Prioriza las solicitudes para maximizar el rendimiento del dispositivo o garantizar la equidad entre los diferentes procesos en ejecución. Reordenamiento de solicitudes  Una vez que el programador organiza la cola, envía la solicitud al controlador de dispositivo específico, como el   . Este controlador traduce la solicitud de bloque genérica al protocolo específico requerido por el hardware, como el conjunto de comandos NVMe transmitido a través del   . controlador NVMe bus PCIe  [Capa 6]: El hardware (el controlador SSD)  La carga útil atraviesa el bus PCIe y llega al SSD. Sin embargo, incluso dentro del hardware, el almacenamiento en búfer desempeña un papel fundamental. Los SSD empresariales modernos funcionan como ordenadores especializados. Ejecutan firmware propietario en procesadores ARM multinúcleo para gestionar la compleja física del almacenamiento de datos.    . La caché DRAM y el acuse de recibo  Para ocultar la latencia de la memoria flash NAND, cuya escritura es más lenta que la lectura, el controlador SSD acepta inicialmente los datos en su caché DRAM interna. Una vez que los datos llegan a esta caché, el controlador envía una confirmación al sistema operativo indicando que la escritura se ha completado. En ese preciso nanosegundo,   . Residen en la placa de circuito impreso de la unidad, no en la placa base del servidor. Las unidades empresariales de alta gama contienen condensadores para vaciar esta caché durante un corte repentino de energía, pero las unidades de consumo a menudo carecen de esta protección. los datos aún se encuentran en la memoria volátil   Traducción y borrado de Flash  La capa de traducción flash (FTL) del SSD ahora asume el control. Dado que la memoria flash NAND no se puede sobrescribir directamente, primero debe borrarse en bloques grandes. La FTL determina la ubicación física óptima de los datos para garantizar un desgaste uniforme en toda la unidad, un proceso conocido como nivelación del desgaste.   Almacenamiento físico  Finalmente, el controlador aplica voltaje a los transistores en la memoria NAND. Esto modifica su estado físico para representar los datos binarios.  Sólo después de esta transformación física los   .  datos son verdaderamente persistentes  Conclusión: Entendiendo el contrato de durabilidad  El recorrido de una escritura pone de relieve el equilibrio explícito que los sistemas operativos establecen entre rendimiento y seguridad. Al permitir que las capas almacenen y difieran el trabajo, los sistemas alcanzan un alto rendimiento, pero la definición de "escritura" se vuelve incierta. Si una aplicación requiere una durabilidad de datos estricta al finalizar, donde la pérdida de datos es inaceptable, los desarrolladores no pueden confiar en el comportamiento predeterminado de una llamada   en la capa de aplicación. write()  Para garantizar la persistencia, es necesario atravesar explícitamente estas capas de abstracción mediante   . Esta   de Python invoca la llamada al sistema   (en sistemas Linux), que fuerza el vaciado de las páginas sucias al sistema de archivos, confirma el diario, envía la E/S del bloque y emite un comando estándar de "Vaciar caché" al controlador de almacenamiento, exigiendo al hardware que vacíe sus búferes volátiles en la NAND. Solo cuando   regresa, el proceso termina. os.fsync(fd) llamada fsync fsync

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

La anatomía de una operación de escritura

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Una breve introducción a la teoría del cerebro de Boltzmann

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Una breve introducción a la teoría del cerebro de Boltzmann

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps