¿El sistema de archivos puede volverse inconsistente si se interrumpe al mover un archivo?

Tengo dos carpetas en la misma partición (EXT2) Si yo mv folder1/file folder2y alguna interrupción ocurre (por ejemplo, falla de energía) ¿podría el sistema de archivos terminar siendo inconsistente?

¿No es mvatómica la operación?

Actualización: Hasta ahora en IRC obtuve las siguientes perspectivas:

1. es atómico, por lo que no pueden ocurrir inconsistencias
2. primero copia la entrada del directorio en el nuevo directorio y luego borra la entrada en el directorio anterior, por lo que puede tener la inconsistencia de tener un archivo referenciado dos veces, pero el recuento de referencias es 1
3. primero borra el puntero y luego copia el puntero, por lo que la inconsistencia es que el archivo tiene referencia 0

¿Alguien puede aclarar?

Primero, disipemos algunos mitos.

es atómico, por lo que no pueden ocurrir inconsistencias

Mover un archivo dentro del mismo sistema de archivos (es decir, la rename) llamada al sistema es atómico con respecto al entorno del software. Atomicidad significa que cualquier proceso que busque el archivo lo verá en su ubicación anterior o en su nueva ubicación; ningún proceso podrá observar que el archivo tiene un recuento de enlaces diferente, o que el archivo está presente en el directorio de origen después de estar presente en el directorio de destino, o que el archivo está ausente del directorio de destino después de estar ausente en el origen directorio.

Sin embargo, si el sistema se bloquea debido a un error, un error de disco o una pérdida de energía, no hay garantía de que el sistema de archivos se quede en un estado coherente, y mucho menos de que el movimiento no se quede a medio hacer. Linux en general no ofrece una garantía de atomicidad con respecto a los eventos de hardware.

primero copia la entrada del directorio en el nuevo directorio y luego borra la entrada en el directorio anterior, por lo que puede tener la inconsistencia de tener un archivo referenciado dos veces, pero el recuento de referencias es 1

Esto se refiere a una técnica de implementación específica. Hay otros.

Sucede que ext2 en Linux (a partir del kernel 3.16) utiliza esta técnica en particular. Sin embargo, esto no implica que el contenido del disco pase por la secuencia [ubicación anterior] → [ambas ubicaciones] → [nueva ubicación], porque las dos operaciones (agregar nueva entrada, eliminar entrada anterior) tampoco son atómicas a nivel de hardware : es posible que uno de ellos se interrumpa, dejando el sistema de archivos en un estado inconsistente. (Esperemos que fsck lo repare). Además, la capa de bloques puede reordenar las escrituras, por lo que la primera mitad podría comprometerse en el disco justo antes del bloqueo y la segunda mitad no se habría realizado.

Nunca se observará que el recuento de referencia sea diferente de 1 siempre que el sistema no se bloquee (ver arriba), pero esa garantía no se extiende a un bloqueo del sistema.

primero borra el puntero y luego copia el puntero, por lo que la inconsistencia es que el archivo tiene referencia 0

Una vez más, esto se refiere a una técnica de implementación particular. No se puede observar un archivo colgante si el sistema no falla, pero es una posible consecuencia de un bloqueo del sistema, al menos en algunas configuraciones.

Según una publicación de blog de Alexander Larsson , ext2 no garantiza la coherencia en un bloqueo del sistema, pero ext3 sí lo hace en el data=orderedmodo. (Tenga en cuenta que esta publicación de blog no trata sobre renamesí misma, sino sobre la combinación de escribir en un archivo y llamar renamea ese archivo).

Theodore Ts'o, el autor principal de los sistemas de archivos ext2, ext3 y ext4, escribió una publicación de blog sobre el mismo tema . Esta publicación de blog analiza la atomicidad (solo con respecto al entorno de software) y la durabilidad (que es la atomicidad con respecto a los bloqueos más una garantía de compromiso, es decir, saber que la operación se ha realizado). Lamentablemente, no puedo encontrar información sobre atomicidad con respecto a los accidentes solo. Sin embargo, las garantías de durabilidad otorgadas para ext4 requieren que renamesea ​​atómico. La documentación del núcleo de ext4 estados que ext4 con la auto_da_allocopción (que es el valor por defecto en los kernels modernos), así como ext4, ofrece una garantía de durabilidad para una writeseguida de unarename, lo que implica que renamees atómico con respecto a los bloqueos de hardware.

Para Btrfs, una renameque sobrescribe un archivo existente se garantiza que sea atómica con respecto a los accidentes, pero una renameque no sobrescribir un archivo puede resultar en ningún archivo o ambos archivos existentes.

En resumen, la respuesta a su pregunta es que no solo mover un archivo no es atómico con respecto a bloqueos en ext2, sino que ni siquiera se garantiza que deje el archivo en un estado consistente (aunque las fallas que fsckno se pueden reparar son raras): prácticamente nada es, por eso se han inventado mejores sistemas de archivos. Ext3, ext4 y btrfs ofrecen garantías limitadas.

La operación de cambio de nombre es muy rápida en cualquier sistema de archivos, por lo que es poco probable que se interrumpa, pero en un sistema de archivos clásico ciertamente se puede interrumpir; si crea el enlace de destino primero, podría dejar dos enlaces en un archivo, lo cual es legal, pero el archivo cree que solo tiene uno, lo que podría causar problemas si se elimina más adelante. Por otro lado, si primero elimina el enlace de origen, el archivo podría perderse. La ejecución de fsck generalmente detectará y corregirá cualquier condición, aunque si el archivo se pierde, se colocará en un directorio "perdido + encontrado" con un nombre arbitrario en lugar de en la ubicación deseada, y si tiene dos enlaces, el recuento de enlaces simplemente se actualizará, por lo que el archivo existirá en dos ubicaciones si el sistema de archivos lo admite.

Si necesita un sistema de archivos para ser robusto ante fallas de energía, debe usar un sistema de archivos de registro en diario , como NTFS, EXT3 o XFS. La mayoría de los sistemas modernos usarán un sistema de archivos de registro por defecto, aunque debe tener en cuenta que FAT no es un sistema de archivos de registro si lo usa para unidades externas.

Un sistema de archivos de diario utiliza un sistema de "doble entrada": escribe en el archivo de diario el hecho de que tiene la intención de moverlo, luego realiza el movimiento. Cuando se verifica el sistema de archivos al inicio, si fue interrumpido, notará que el movimiento no se completó y lo rehacerá.

Hay dos tipos de sistemas de archivos de diario: diario de metadatos y diario completo. El registro en diario de metadatos significa que no realiza un seguimiento de los cambios en el contenido del archivo en el sistema del diario (por lo tanto, podría terminar perdiendo el contenido si está escribiendo en un archivo), pero aún mantendrá un registro de la información importante del sistema de archivos, como el contenido del directorio , propiedades de archivo, etc.

Cuando la gente habla de que la operación de cambio de nombre es atómica, significa que no puede observarse a mitad de la transición por otro proceso en el sistema, y ​​no puede dejarse a medio completar, por ejemplo, interrumpiendo el mvcomando en sí ^C. El proceso físico de escritura en cada directorio, cuyo espacio de almacenamiento puede estar en ubicaciones muy diferentes en el disco, no puede ser una operación verdaderamente atómica a nivel de hardware.

Para completar, notaré que también hay algunas operaciones de E / S incidentales asociadas con un cambio de nombre, además de crear el nuevo enlace en el directorio de destino y eliminarlo en el antiguo, actualizando el mtime de ambos directorios, posiblemente extendiendo el tamaño de asignación del directorio de destino, cambiando el ..enlace y los recuentos de enlaces de los directorios principales si el archivo es un directorio. Además, no estoy seguro de si el momento del archivo en sí está afectado.

Esta pregunta se ha hecho de una manera ligeramente diferente en Super User. La página de Wikipedia sobre el mvcomando también lo explica bastante bien:

Mover archivos dentro del mismo sistema de archivos generalmente se implementa de manera diferente que copiar el archivo y luego eliminar el original. En las plataformas que no admiten el cambio de nombre de syscall, se agrega un nuevo enlace al nuevo directorio y se elimina el original. No se accede a los datos del archivo.

Linux tiene el cambio de nombre syscall y, por lo tanto, cambiará el nombre del archivo como una operación atómica, es decir, ininterrumpible. Entonces, no, el sistema de archivos no puede volverse inconsistente en la situación que usted describió.