Solía ​​pensar que los cambios de archivos se guardan directamente en el disco, es decir, tan pronto como cierro el archivo y decido hacer clic / seleccionar guardar. Sin embargo, en una conversación reciente, un amigo mío me dijo que eso no suele ser cierto; El sistema operativo (específicamente estábamos hablando de sistemas Linux) mantiene los cambios en la memoria y tiene un demonio que realmente escribe el contenido de la memoria en el disco.

Incluso dio el ejemplo de las unidades flash externas: estas están montadas en el sistema (copiadas en la memoria) y, a veces, la pérdida de datos ocurre porque el demonio aún no guardó el contenido en la memoria flash; Es por eso que desmontamos las unidades flash.

No tengo conocimiento sobre el funcionamiento de los sistemas operativos, por lo que no tengo ni idea de si esto es cierto y en qué circunstancias. Mi pregunta principal es: ¿sucede esto como se describe en los sistemas Linux / Unix (y tal vez otros sistemas operativos)? Por ejemplo, ¿significa esto que si apago la computadora inmediatamente después de editar y guardar un archivo, mis cambios probablemente se perderán? Tal vez depende del tipo de disco: ¿discos duros tradicionales versus discos de estado sólido?

La pregunta se refiere específicamente a los sistemas de archivos que tienen un disco para almacenar la información, aunque cualquier aclaración o comparación sea bien recibida.

si apago la computadora inmediatamente después de editar y guardar un archivo, ¿mis cambios probablemente se perderán?

Puede ser que sean. No diría "lo más probable", pero la probabilidad depende de muchas cosas.

Una manera fácil de aumentar el rendimiento de las escrituras de archivos es que el sistema operativo solo almacene en caché los datos, le diga (mienta) a la aplicación por la que pasó la escritura y luego haga la escritura más tarde. Esto es especialmente útil si hay otra actividad de disco al mismo tiempo: el sistema operativo puede priorizar las lecturas y las escrituras más tarde. También puede eliminar por completo la necesidad de una escritura real, por ejemplo, en el caso de que un archivo temporal se elimine rápidamente después.

El problema de almacenamiento en caché es más pronunciado si el almacenamiento es lento. Copiar archivos de un SSD rápido a una memoria USB lenta probablemente implicará una gran cantidad de almacenamiento en caché de escritura, ya que la memoria USB simplemente no puede seguir el ritmo. Pero su cpcomando regresa más rápido, por lo que puede seguir trabajando, posiblemente incluso editando los archivos que se acaban de copiar.

Por supuesto, el almacenamiento en caché como ese tiene el inconveniente que observa, algunos datos pueden perderse antes de que realmente se guarden. El usuario se molestará si su editor le dice que la escritura fue exitosa, pero que el archivo no estaba realmente en el disco. Es por eso que hay una fsync()llamada al sistema , que se supone que debe regresar solo después de que el archivo haya llegado al disco. Su editor puede usar eso para asegurarse de que los datos estén bien antes de informar al usuario que la escritura se realizó correctamente.

Dije "se supone que debe hacerlo", ya que la unidad en sí misma podría decirle las mismas mentiras al sistema operativo y decir que la escritura está completa, mientras que el archivo realmente solo existe en un caché de escritura volátil dentro de la unidad. Dependiendo de la unidad, puede que no haya forma de evitarlo.

Además de fsync(), también existen las sync()y syncfs()llamadas al sistema que piden el sistema para asegurarse de que todas las escrituras de todo el sistema o todas las escrituras en un sistema de archivos en particular han dado en el disco. La utilidad syncse puede utilizar para llamar a esos.

Luego también está la O_DIRECTbanderaopen() , que se supone que "intenta minimizar los efectos de caché de las E / S desde y hacia este archivo". La eliminación del almacenamiento en caché reduce el rendimiento, por lo que es utilizado principalmente por aplicaciones (bases de datos) que hacen su propio almacenamiento en caché y desean controlarlo. ( O_DIRECTno está exento de problemas, los comentarios al respecto en la página de manual son algo divertidos).

Lo que sucede en un apagado también depende del sistema de archivos. No solo debes preocuparte por los datos del archivo, sino también por los metadatos del sistema de archivos. Tener los datos del archivo en el disco no sirve de mucho si no puede encontrarlos. Solo extender un archivo a un tamaño mayor requerirá asignar nuevos bloques de datos, y deben marcarse en algún lugar.

La forma en que un sistema de archivos trata los cambios de metadatos y el orden entre metadatos y escrituras de datos varía mucho. Por ejemplo, ext4si configura el indicador de montaje data=journal, todas las escrituras, incluso las escrituras de datos, pasan por el diario y deberían ser bastante seguras. Eso también significa que se escriben dos veces, por lo que el rendimiento disminuye. Las opciones predeterminadas intentan ordenar las escrituras para que los datos estén en el disco antes de que se actualicen los metadatos. Otras opciones u otro sistema de archivos pueden ser mejores o peores; Ni siquiera intentaré un estudio exhaustivo.

En la práctica, en un sistema con poca carga, el archivo debería llegar al disco en unos segundos. Si se trata de almacenamiento extraíble, desmonte el sistema de archivos antes de extraer los medios para asegurarse de que los datos se envíen realmente a la unidad, y no haya más actividad. (O haga que su entorno GUI lo haga por usted).

Hay una manera extremadamente simple de demostrar que no puede ser cierto que las ediciones de archivos siempre se guarden directamente en el disco, es decir, el hecho de que hay sistemas de archivos que no están respaldados por un disco en primer lugar . Si un sistema de archivos no tiene un disco en primer lugar, entonces no puede escribir los cambios en el disco, nunca .

Algunos ejemplos son:

• tmpfs, un sistema de archivos que solo existe en la RAM (o más precisamente, en la memoria caché del búfer)
• ramfs, un sistema de archivos que solo existe en la RAM
• cualquier sistema de archivos de red (NFS, CIFS / SMB, AFS, AFP, ...)
• cualquier sistema de ficheros virtual ( sysfs, procfs, devfs, shmfs, ...)

Pero incluso para sistemas de archivos respaldados por disco, esto generalmente no es cierto. La página Cómo corromper una base de datos SQLite tiene un capítulo llamado Error de sincronización que describe muchas formas diferentes en las que las escrituras (en este caso se comprometen con una base de datos SQLite) pueden fallar al llegar al disco. SQLite también tiene un documento técnico que explica los numerosos aros que debe atravesar para garantizar Atomic Commit In SQLite . (Tenga en cuenta que la escritura atómica es mucho más difícil que solo escribir , pero, por supuesto, escribir en el disco es un subproblema de la escritura atómica, y también puede aprender mucho sobre ese problema en este documento). sección sobre Cosas que pueden salir mal, que incluye una subsección sobreFlushes de disco incompletos que dan algunos ejemplos de complejidades sutiles que pueden evitar que una escritura llegue al disco (como el controlador de HDD que informa que ha escrito en el disco cuando no lo ha hecho; sí, hay fabricantes de HDD que hacen esto, e incluso podría ser legal según la especificación ATA, porque está redactado de manera ambigua a este respecto).

Es cierto que la mayoría de los sistemas operativos, incluidos Unix, Linux y Windows, utilizan un caché de escritura para acelerar las operaciones. Eso significa que apagar una computadora sin apagarla es una mala idea y puede conducir a la pérdida de datos. Lo mismo es cierto si elimina un almacenamiento USB antes de que esté listo para ser eliminado.

La mayoría de los sistemas también ofrecen la opción de realizar escrituras sincrónicas. Eso significa que los datos estarán en el disco antes de que una aplicación reciba una confirmación de éxito, a costa de ser más lenta.

En resumen, hay una razón por la cual debería apagar su computadora correctamente y preparar adecuadamente el almacenamiento USB para su extracción.

1. Almacenamiento basado en flash

¿Depende del tipo de disco (discos duros tradicionales versus discos de estado sólido) o de cualquier otra variable que no conozca? ¿Sucede (si sucede) solo en Linux o está presente en otros sistemas operativos?

Cuando tenga una opción, no debe permitir que el almacenamiento basado en flash pierda energía sin un apagado limpio.

En el almacenamiento de bajo costo como las tarjetas SD, puede esperar perder bloques de borrado completos (varias veces más grandes que 4KB), perdiendo datos que podrían pertenecer a diferentes archivos o estructuras esenciales del sistema de archivos.

Algunos SSD caros pueden afirmar que ofrecen mejores garantías ante fallas de energía. Sin embargo, las pruebas de terceros sugieren que muchos SSD caros no lo hacen. La capa que reasigna bloques para "nivelación de desgaste" es compleja y patentada. Las posibles fallas incluyen la pérdida de todos los datos en el disco.

Aplicando nuestro marco de prueba, probamos 17 unidades de estado sólido de seis proveedores diferentes utilizando más de tres mil ciclos de inyección de fallas en total. Nuestros resultados experimentales revelan que 14 de los 17 dispositivos SSD probados exhiben comportamientos de fallas sorprendentes bajo fallas de alimentación, incluyendo corrupción de bits, escrituras cortadas, escrituras no serializables, corrupción de metadatos y falla total del dispositivo.

2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled

2. Girar unidades de disco duro

Los discos duros giratorios tienen diferentes características. Por seguridad y simplicidad, recomiendo asumir que tienen la misma incertidumbre práctica que el almacenamiento basado en flash.

A menos que tenga evidencia específica, que claramente no tiene. No tengo cifras comparativas para girar discos duros.

Una unidad de disco duro puede dejar un sector escrito de forma incompleta con una suma de comprobación incorrecta, lo que nos dará un buen error de lectura más adelante. En términos generales, este modo de falla de los discos duros es completamente esperado; Los sistemas de archivos nativos de Linux están diseñados pensando en ello. Su objetivo es preservar el contrato fsync()frente a este tipo de falla por pérdida de potencia. (Realmente nos gustaría ver esto garantizado en SSD).

Sin embargo, no estoy seguro de si los sistemas de archivos de Linux logran esto en todos los casos, o si eso es posible.

El próximo arranque después de este tipo de falla puede requerir una reparación del sistema de archivos. Siendo Linux, es posible que la reparación del sistema de archivos haga algunas preguntas que no comprenda, en las que solo puede presionar Y y esperar que se resuelva por sí solo.

2.1 Si no sabe cuál es el contrato fsync ()

El contrato fsync () es una fuente de buenas y malas noticias. Debes entender las buenas noticias primero.

Buenas noticias: fsync()está bien documentado como la forma correcta de escribir datos de archivo, por ejemplo, cuando presiona "guardar". Y es ampliamente entendido que, por ejemplo, los editores de texto deben reemplazar los archivos existentes usando atómicamente rename(). Esto está destinado a garantizar que siempre mantenga el archivo antiguo u obtenga el nuevo archivo (que se fsync()editó antes del cambio de nombre). No desea quedarse con una versión medio escrita del nuevo archivo.

Malas noticias: durante muchos años, llamar a fsync () en el sistema de archivos Linux más popular podría dejar todo el sistema colgado durante decenas de segundos. Dado que las aplicaciones no pueden hacer nada al respecto, era muy común utilizar optimistamente rename () sin fsync (), que parecía ser relativamente confiable en este sistema de archivos.

Por lo tanto, existen aplicaciones que no usan fsync () correctamente.

La próxima versión de este sistema de archivos generalmente evitó el bloqueo de fsync (), al mismo tiempo que comenzó a confiar en el uso correcto de fsync ().

Todo esto es bastante malo. Probablemente, el tono despectivo y la inventiva que utilizaron muchos de los desarrolladores de kernel en conflicto no ayudaron a comprender esta historia.

La resolución actual es que el sistema de archivos Linux más popular actual el valor predeterminado es admitir el patrón rename () sin requerir fsync ()implementa "compatibilidad error por error" con la versión anterior. Esto se puede deshabilitar con la opción de montaje noauto_da_alloc.

Esta no es una protección completa. Básicamente, vacía el IO pendiente en el momento rename (), pero no espera a que se complete el IO antes de cambiar el nombre. ¡Esto es mucho mejor que, por ejemplo, una ventana de peligro de 60 segundos! Consulte también la respuesta a ¿Qué sistemas de archivos requieren fsync () para evitar accidentes al reemplazar un archivo existente con rename ()?

Algunos sistemas de archivos menos populares no brindan protección. XFS se niega a hacerlo. Y UBIFS tampoco lo ha implementado, aparentemente podría aceptarse pero necesita mucho trabajo para hacerlo posible. La misma página señala que UBIFS tiene varios otros problemas "TODO" para la integridad de los datos, incluida la pérdida de energía. UBIFS es un sistema de archivos utilizado directamente en el almacenamiento flash. Me imagino que algunas de las dificultades que menciona UBIFS con el almacenamiento flash podrían ser relevantes para los errores de SSD.

En un sistema con poca carga, el núcleo permitirá que los datos de los archivos recién escritos se asienten en la memoria caché de la página durante unos 30 segundos después de write(), antes de enjuagarlos en el disco, para optimizar el caso en el que se eliminan o modifican nuevamente pronto.

El valor dirty_expire_centisecspredeterminado de Linux es 3000 (30 segundos) y controla cuánto tiempo antes de que "caduquen" los datos recién escritos. (Ver https://lwn.net/Articles/322823/ ).

Consulte https://www.kernel.org/doc/Documentation/sysctl/vm.txt para obtener más afinables relacionados, y google para obtener muchos más. (por ejemplo, google on dirty_writeback_centisecs).

El valor predeterminado para Linux /proc/sys/vm/dirty_writeback_centisecses 500 (5 segundos) , y PowerTop recomienda configurarlo en 1500 (15 segundos) para reducir el consumo de energía.

La escritura diferida también le da tiempo al núcleo para ver qué tan grande será un archivo, antes de comenzar a escribirlo en el disco. Los sistemas de archivos con asignación retrasada (como XFS y probablemente otros en estos días) ni siquiera eligen en qué lugar del disco colocar los datos de un archivo recién escrito hasta que sea necesario, por separado de la asignación de espacio para el propio inodo. Esto reduce la fragmentación al permitirles evitar poner el inicio de un archivo grande en una brecha de 1 meg entre otros archivos, por ejemplo.

Si se escriben muchos datos, la reescritura en el disco puede activarse mediante un umbral de la cantidad de datos sucios (aún no sincronizados en el disco) que puede haber en el caché de página.

Sin embargo, si no está haciendo mucho más, la luz de actividad del disco duro no se encenderá durante 5 (o 15) segundos después de presionar guardar en un archivo pequeño.

Si su editor utilizó fsync()después de escribir el archivo, el núcleo lo escribirá en el disco sin demora. (Y fsyncno volverá hasta que los datos hayan sido enviados al disco).

El almacenamiento en caché de escritura dentro del disco también puede ser una cosa, pero los discos normalmente intentan enviar su caché de escritura al almacenamiento permanente lo antes posible, a diferencia de los algoritmos de caché de página de Linux. Las memorias caché de escritura en disco son más un búfer de almacenamiento para absorber pequeñas ráfagas de escrituras, pero tal vez también para retrasar las escrituras a favor de las lecturas, y dar a los discos espacio de firmware para optimizar un patrón de búsqueda (por ejemplo, hacer dos escrituras o lecturas cercanas en lugar de una , luego buscando lejos, luego buscando de regreso.)

En un disco giratorio (magnético), es posible que vea algunos retrasos de búsqueda de 7 a 10 ms cada uno antes de que los datos de un comando de escritura SATA estén realmente a salvo del apagado, si hubiera lecturas / escrituras pendientes antes de su escritura. (Algunas otras respuestas a esta pregunta entran en más detalles sobre las memorias caché de escritura en disco y las barreras de escritura que los FSes con diario pueden usar para evitar la corrupción).