¿Qué operaciones de metadatos del sistema de archivos se registran realmente en ext4 y xfs?

9

No puedo encontrar una respuesta simple y directa sobre qué operaciones de metadatos del sistema de archivos realmente persisten en los diarios del sistema de archivos ext4 y xfs. Nótese que estoy no indagando sobre qué POSIX declara ser "atómica". Me preocupa más qué subconjunto de operaciones de sistemas de archivos atómicos son efectivamente duraderos en virtud de ejecutarse con un diario habilitado sin tener que inclinarse hacia atrás y fsync(2)todo el tiempo.

Operaciones estoy bastante seguro de contar:

  • creat(2)
  • link(2)
  • unlink(2)
  • rename(2)
  • mkdir(2)
  • rmdir(2)

Operaciones de las que no estoy completamente seguro:

  • symlink(2)

El symlink(2)caso es el más problemático, ya que no parece haber una forma directa fsync(2)o fdatasync(2)los bloques de datos subyacentes que almacenan el contenido de un enlace simbólico. Saber que el diario se encarga de esto por mí sería un alivio.

linux filesystems ext4 xfs rboyer
fuente

Respuestas:

1

Por razones de rendimiento, ext4 por defecto solo escribe metadatos del sistema de archivos a través del diario.

Creo que XFS también registra todas las transacciones de metadatos, a menos que haya modificado el sistema de archivos.

John Westlund
fuente
Sí, pero ¿qué son los "metadatos" específicamente? Los bloques de un directorio: seguro. Los inodos mismos: sí. Enlaces simbólicos con un objetivo lo suficientemente pequeño como para caber en el propio inodo: ¿probablemente? Enlaces simbólicos donde el objetivo se desborda en bloques auxiliares: ??????
enlace ayudaría
asdmin
1

Me preocupa más qué subconjunto de operaciones del sistema de archivos atómico es efectivamente duradero en virtud de ejecutarse con un diario habilitado sin tener que inclinarse hacia atrás y fsync (2) todo el tiempo.

Ninguna. Si desea asegurarse de que los cambios persisten después de un bloqueo, debe fsync, punto. El registro en el diario solo garantiza que, en caso de un bloqueo, ninguna de las operaciones que enumeró se realizará a medias .

psusi
fuente
Sé que si me importa, debo sincronizar archivos y directorios para saber con certeza si los bloques han alcanzado la oxidación giratoria, pero no hay ningún método que haya podido encontrar que me permita sincronizar los bloques que retroceden un enlace simbólico si se derrama El inodo. En ese momento, mi único recurso es confiar en el diario o nunca volver a usar enlaces simbólicos para nada importante.
rboyer
@naelyn, un fsync () vaciará todos los bloques relacionados con un archivo, incluido un enlace simbólico no rápido.
psusi
1
¿Cómo abro un descriptor de archivo apropiado para usarlo en una sincronización fsy que eliminaría los bloques de enlaces simbólicos no rápidos?
rboyer
@naelyn, oh sí ... buen punto ... podría tener que preguntar sobre eso en la lista de correo linux-fsdevel ... con enlaces duros, creo que abres y sincronizas el directorio que lo contiene, ¿tal vez los enlaces simbólicos funcionen igual?
psusi
0

Usted sabe que el diario ext4 funciona por número de bloque y no por operación, ¿correcto? Los "metadatos" serían cualquier cosa que no sean los bloques de datos reales para el inodo dado, independientemente de la operación que utilizó para modificar el bloque en cuestión.

Bratchley
fuente
0

xfstests parece afirmar que fsync () en un directorio debe persistir en cualquier enlace simbólico que contenga.

No he verificado esto. Es posible que me haya perdido algo.

xfstests es utilizado por muchos desarrolladores de sistemas de archivos Linux. Esta prueba está en el directorio "genérico". Implica que debería aplicarse a todos los sistemas de archivos de Linux. (O al menos, todos los sistemas de archivos del dispositivo de bloque. La prueba funciona utilizando un dispositivo de bloque virtual especial).

https://github.com/kdave/xfstests/blob/master/tests/generic/348

# Test creating a symlink, fsync its parent directory, power fail and mount
# again the filesystem. After these steps the symlink should exist and its
# content must match what we specified when we created it (must not be empty
# or point to something else).
sourcejedi
fuente