si apago la computadora inmediatamente después de editar y guardar un archivo, lo más probable es que mis cambios se pierdan?
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 simplemente 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 en el disco al mismo tiempo:el sistema operativo puede priorizar las lecturas y hacer 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 del 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á mucho almacenamiento en caché de escritura, ya que la memoria USB simplemente no puede seguir el ritmo. Pero tu cp el comando regresa más rápido, por lo que puede continuar trabajando, posiblemente incluso editando los archivos que acaba de copiar.
Por supuesto, el almacenamiento en caché como ese tiene la desventaja 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. Por eso existe el fsync() llamada al sistema, que se supone que regresa 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í podría decir 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 están los sync() y syncfs() llamadas al sistema que le piden al sistema que se asegure de que todas las escrituras en todo el sistema o todas las escrituras en un sistema de archivos en particular hayan llegado al disco. La utilidad sync se puede usar para llamarlos.
Luego también está el O_DIRECT marcar a open() , que se supone que "trata de minimizar los efectos de caché de la E/S hacia y desde este archivo". La eliminación del almacenamiento en caché reduce el rendimiento, por lo que lo utilizan principalmente las aplicaciones (bases de datos) que realizan su propio almacenamiento en caché y quieren controlarlo.(O_DIRECT no está exento de problemas, los comentarios al respecto en la página de manual son algo divertidos).
Lo que sucede en un corte de energía también depende del sistema de archivos. No son solo los datos del archivo los que deberían preocuparte, sino los metadatos del sistema de archivos. Tener los datos del archivo en el disco no sirve de mucho si no puede encontrarlos. Simplemente ampliar un archivo a un tamaño mayor requerirá la asignación de nuevos bloques de datos, y deben marcarse en alguna parte.
La forma en que un sistema de archivos trata con los cambios de metadatos y el orden entre los metadatos y las escrituras de datos varía mucho. Por ejemplo, con ext4 , si establece el indicador de montaje data=journal , entonces 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 pocos 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 que no haya más actividad. (O haga que su entorno GUI lo haga por usted).
Hay un extremadamente forma sencilla de probar que no puede ser cierto que las ediciones de archivos siempre se guardan 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 es posible 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 el caché del búfer)ramfs, un sistema de archivos que solo existe en RAM- cualquiera sistema de archivos de red (NFS, CIFS/SMB, AFS, AFP, …)
- cualquiera sistema de archivos virtual (
sysfs,procfs,devfs,shmfs, …)
Pero incluso para los sistemas de archivos respaldados por disco, esto no suele ser 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, las confirmaciones en una base de datos SQLite) pueden no llegar al disco. SQLite también tiene un libro blanco que explica los muchos obstáculos que debe superar para garantizar Atomic Commit In SQLite . (Tenga en cuenta que Escritura atómica es un problema mucho más difícil que simplemente 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). Este documento tiene una sección sobre Cosas que pueden salir mal que incluye una subsección sobre vaciados de disco incompletos que brindan algunos ejemplos de complejidades sutiles que podrían evitar que una escritura llegue al disco (como que el controlador de HDD informe que ha escrito en el disco cuando en realidad no lo ha hecho; sí, hay fabricantes de HDD que hacen esto, y podría incluso ser legal de acuerdo con 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 una memoria caché de escritura para acelerar las operaciones. Eso significa que apagar una computadora sin apagarla es una mala idea y puede provocar la pérdida de datos. Lo mismo ocurre si elimina un dispositivo de 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 síncronas. 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 que debe apagar correctamente su computadora y preparar adecuadamente el almacenamiento USB para su eliminación.