NFS caché: el contenido del archivo no se actualiza en el cliente cuando se modifica en el servidor

11

Aquí está mi configuración: una máquina servidor NFS (v4), varias máquinas cliente NFS.

Cuando una máquina cliente escribe archivos en el soporte NFS, los otros clientes ven el nuevo contenido al instante: no hay problema.

Pero, cuando la máquina del servidor modifica el contenido del archivo, este nuevo contenido no se muestra en el cliente hasta que haga una parte lsdel directorio desde el cliente.

Estoy absolutamente perplejo con esta inconsistencia ... ¡cualquier ayuda sería muy apreciada!

Informaciones:

nfs 1.2.3-r1 tanto en el cliente como en el servidor
acregmin, acregmax, acdirmin, acdirmax, lookupcache: valores predeterminados

nfs

— numberxiii
fuente

1

¿Puedes hacer un pequeño experimento para obtener más información ?: Haz una copia ls -ien el cliente antes de editar el archivo en el servidor y luego nuevamente. Vea si los números cambian. Si lo hacen porque el servidor está reemplazando el archivo y el cliente no lo nota hasta que vuelve a escanear el directorio. Si es así, intente configurar la opción de montaje lookupcache=noney vea si el comportamiento cambia.

— Patrick

2

Perdón por el retraso. El inodo cambia efectivamente. He agregado la opción lookupcache, parece funcionar. Comprobaré de nuevo mañana.

— numberxiii

11

Agregar como respuesta en función de su comentario.
La solución es agregar lookupcache=nonea sus opciones de montaje nfs.

Lo que sucede es que la primera vez que su cliente lee el archivo, realiza una búsqueda NFS para obtener el ID de archivo NFS. Luego almacena en caché el ID de archivo NFS, y cuando regresa para abrir el archivo, usa el caché. Normalmente esto no es un problema, ya que cuando el archivo se actualiza su fileid permanece igual. Pero por alguna razón, el archivo antiguo se está eliminando y se crea uno nuevo (o se le cambia el nombre, o algo que no es el mismo archivo).
Ahora normalmente esto no es un problema, ya que cuando su cliente intenta abrir un fileid que no está allí, recibirá un error del servidor y realizará otra búsqueda para obtener el nuevo fileid. Pero por alguna razón, el servidor NFS está permitiendo que el cliente abra ese fileid antiguo. Quizás otro cliente tenga el archivo abierto y, por lo tanto, aún no se haya eliminado, no lo sé.

En cualquier caso, la forma de resolverlo es decirle al cliente que siempre haga una búsqueda nfs antes de abrir un archivo utilizando la opción de montaje nfs lookupcache=none. La desventaja de esto es que puede ser costoso si abre archivos con frecuencia, ya que agrega más tráfico al servidor NFS.

— Patricio
fuente

Gracias por tu explicación. En el servidor NFS, la pila del directorio exportado es DRBD / LVM / ext4. Puede ser que esté causando el "error". Tengo el problema en varios clientes, pero no en algunos otros ... Rehaceré todas mis pruebas y te diré si todo va bien con esta opción.

— numberxiii

0

Cambie la opción de montaje a hard,intr. Creo que el valor predeterminado puede ser suave en su sistema. esto ayudará.

— johnshen64
fuente

desafortunadamente, agregar estas opciones de montaje no cambió nada :(

— numberxiii

Para mi primera prueba, hago un montaje. Luego hice una prueba de otro cliente, con un montaje limpio. El problema parece ser corregido: esperamos 30 años para ver el nuevo contenido

— numberxiii

He creado un nuevo cliente (vm) para verificar: ¡no hay problema con el contenido!

— numberxiii

1

@ johnshen64 ¿por qué crees que resolvería el problema? Hard / soft solo importa cuando se trata de la interrupción de la conexión, no tiene nada que ver con el almacenamiento en caché.

— Patrick

0

También puede actualizar manualmente el caché NFS con

sudo mount /nfs-mount -o remount

... en caso de que no desee agregar opciones de montaje que degraden el rendimiento.

— Janne
fuente