io - que - ¿En qué se diferencian las marcas O_SYNC y O_DIRECT de open(2)/iguales?
que es el branding y como se aplica (4)
AFAIK, O_DIRECT omite el caché de la página. O_SYNC usa el caché de página pero lo sincroniza inmediatamente. La caché de la página se comparte entre procesos, por lo que si hay otro proceso que esté funcionando en el mismo archivo sin el indicador O_DIRECT, puede leer los datos correctos.
El uso y los efectos de los indicadores O_SYNC y O_DIRECT son muy confusos y parecen variar algo entre las plataformas. Desde la página de manual de Linux (vea un ejemplo here ), O_DIRECT proporciona E / S síncrona, minimiza los efectos de caché y requiere que usted maneje la alineación del tamaño de bloque usted mismo. O_SYNC solo garantiza E / S síncronas. Aunque ambos garantizan que los datos se escriben en el caché del disco duro, creo que se supone que las operaciones de E / S directas son más rápidas que las E / S sincrónicas simples ya que omiten el caché de la página (aunque la página de manual de FreeBSD para open (2) indica que el caché se omite cuando se usa O_SYNC. Vea here ).
¿Cuáles son exactamente las diferencias entre los indicadores O_DIRECT y O_SYNC? Algunas implementaciones sugieren usar O_SYNC | O_DIRECT. ¿Por qué?
Actuall under linux 2.6, o_direct está sincronizado, vea la página del manual:
manpage of open, hay 2 secciones al respecto ..
Bajo 2.4 no está garantizado.
O_DIRECT (Desde Linux 2.4.10) Intente minimizar los efectos de caché de la E / S hacia y desde este archivo. En general, esto degradará el rendimiento, pero es útil en situaciones especiales, como cuando las aplicaciones realizan su propio almacenamiento en caché. La E / S de archivos se realiza directamente a / desde los buffers de espacio de usuario. El indicador O_DIRECT por sí solo hace un esfuerzo por transferir datos de forma sincrónica, pero no ofrece las garantías del indicador O_SYNC de que los datos y los metadatos necesarios se transfieren. Para garantizar la E / S síncrona, O_SYNC debe usarse además de O_DIRECT. Vea las NOTAS a continuación para mayor discusión.
Una interfaz semánticamente similar (pero en desuso) para dispositivos de bloque se describe en raw (8).
pero bajo 2.6 está garantizado, ver
O_DIRECTO
El indicador O_DIRECT puede imponer restricciones de alineación en la longitud y la dirección de los búferes del espacio de usuario y el desplazamiento del archivo de las E / S. En Linux, las restricciones de alineación varían según el sistema de archivos y la versión del kernel y pueden estar ausentes por completo. Sin embargo, actualmente no hay una interfaz independiente del sistema de archivos para que una aplicación descubra estas restricciones para un archivo o sistema de archivos determinado. Algunos sistemas de archivos proporcionan sus propias interfaces para hacerlo, por ejemplo, la operación XFS_IOC_DIOINFO en xfsctl (3).
En Linux 2.4, los tamaños de transferencia y la alineación del búfer del usuario y el desplazamiento del archivo deben ser múltiplos del tamaño de bloque lógico del sistema de archivos. En Linux 2.6, la alineación con los límites de 512 bytes es suficiente.
O_DIRECT I / Os nunca debe ejecutarse al mismo tiempo que la llamada del sistema fork (2), si el búfer de memoria es un mapeo privado (es decir, cualquier mapeo creado con la marca mmap (2) MAP_PRIVATE; esto incluye la memoria asignada en el montón y estáticamente buffers asignados). Cualquiera de estas E / S, ya sea que se envíen a través de una interfaz de E / S asíncrona o desde otro subproceso en el proceso, deben completarse antes de llamar a fork (2). De lo contrario, se pueden producir daños en los datos y un comportamiento indefinido en los procesos primarios y secundarios. Esta restricción no se aplica cuando el búfer de memoria para las E / S O_DIRECT se creó utilizando shmat (2) o mmap (2) con el indicador MAP_SHARED. Tampoco se aplica esta restricción cuando el búfer de memoria ha sido recomendado como MADV_DONTFORK con madvise (2), asegurando que no estará disponible para el niño después de la bifurcación (2).
El indicador O_DIRECT se introdujo en SGI IRIX, donde tiene restricciones de alineación similares a las de Linux 2.4. IRIX también tiene una llamada fcntl (2) para consultar las alineaciones y los tamaños apropiados. FreeBSD 4.x introdujo una bandera del mismo nombre, pero sin restricciones de alineación.
La compatibilidad con O_DIRECT se agregó bajo Linux en la versión 2.4.10 del núcleo. Los núcleos de Linux más antiguos simplemente ignoran esta bandera. Es posible que algunos sistemas de archivos no implementen el indicador y open () fallará con EINVAL si se usa.
Las aplicaciones deben evitar mezclar O_DIRECT y E / S normal en el mismo archivo, y especialmente en la superposición de regiones de bytes en el mismo archivo. Incluso cuando el sistema de archivos maneja correctamente los problemas de coherencia en esta situación, es probable que el rendimiento general de E / S sea más lento que usar cualquiera de los dos modos solo. Del mismo modo, las aplicaciones deben evitar mezclar mmap (2) de archivos con E / S directa a los mismos archivos.
El comportamiento de O_DIRECT con NFS diferirá de los sistemas de archivos locales. Los kernels más antiguos, o kernels configurados de ciertas maneras, pueden no ser compatibles con esta combinación. El protocolo NFS no admite pasar el indicador al servidor, por lo que O_DIRECT I / O solo omitirá el caché de la página en el cliente; el servidor todavía puede almacenar en caché la E / S. El cliente le pide al servidor que haga la E / S síncrona para preservar la semántica síncrona de O_DIRECT. Algunos servidores tendrán un rendimiento bajo en estas circunstancias, especialmente si el tamaño de E / S es pequeño. Algunos servidores también pueden estar configurados para mentir a los clientes sobre el hecho de que la E / S haya alcanzado un almacenamiento estable; esto evitará la penalización en el rendimiento con cierto riesgo para la integridad de los datos en caso de un fallo de alimentación del servidor. El cliente NFS de Linux no impone restricciones de alineación en O_DIRECT I / O.
En resumen, O_DIRECT es una herramienta potencialmente poderosa que debe usarse con precaución. Se recomienda que las aplicaciones traten el uso de O_DIRECT como una opción de rendimiento que está deshabilitada de forma predeterminada.
"Lo que siempre me ha molestado acerca de O_DIRECT es que toda la interfaz es simplemente estúpida y probablemente fue diseñada por un mono desquiciado en algunas sustancias serias que controlan la mente". --- Linus
Consulte este artículo de lwn para obtener una descripción clara de las funciones de O_DIRECT y O_SYNC y su impacto en la integridad de los datos:
O_DIRECT solo solo promete que el kernel evitará copiar datos del espacio del usuario al kernel, y en su lugar, los escribirá directamente a través de DMA (acceso directo a la memoria; si es posible). Los datos no entran en cachés. No hay una garantía estricta de que la función retornará solo después de que todos los datos hayan sido transferidos.
O_SYNC garantiza que la llamada no se devolverá antes de que todos los datos se hayan transferido al disco (por lo que el sistema operativo puede decir). Esto todavía no garantiza que los datos no se encuentren en algún lugar del caché de escritura del disco duro, pero es todo lo que el sistema operativo puede garantizar.
O_DIRECT | O_SYNC es la combinación de estos, es decir, "garantía DMA +".