Resumen

  • El borrador de NFSv4.2 aprobado por el IESG define un booleano por archivo que indica a los clientes compatibles que limiten la caché duradera de datos, pero el atributo es consultivo y su implementación es opcional.
  • Ver true no prueba que una apertura anterior haya cambiado, que un WRITE inestable haya llegado a COMMIT, que pNFS haya publicado sus metadatos ni que otra aplicación haya observado los bytes.

Un servidor podrá expresar en el propio protocolo algo que hasta ahora solía quedar en la configuración local: este archivo no es adecuado para la caché normal de datos del cliente. En cargas HPC y escrituras paralelas, la indicación permite buscar un comportamiento parecido a O_DIRECT sin modificar cada aplicación.

La declaración, sin embargo, no vacía la caché por sí sola.

El 17 de septiembre, el IESG aprobó Adding an Uncacheable File Data Attribute to NFSv4.2 y lo remitió a la cola del RFC Editor. La revisión 16 define fattr4_uncacheable_file_data, atributo 87, como un booleano de lectura y escritura aplicable a archivos normales y atributos con nombre. Su categoría NFS es RECOMMENDED, pero eso no obliga a todos los servidores a implementarlo.

El soporte pertenece a cada sistema de archivos exportado. Dos exportaciones del mismo servidor pueden dar respuestas distintas. El cliente consulta supported_attrs o prueba el atributo. Un SETATTR no soportado devuelve NFS4ERR_ATTRNOTSUPP; un GETATTR no soportado sencillamente omite el campo. La ausencia exige contexto antes de convertirse en una alarma.

Cuando un cliente respeta el valor verdadero, no debe retrasar el envío de WRITE para combinar operaciones o ganar eficiencia. La regla ataca un riesgo preciso: varios clientes pueden modificar rangos distintos del mismo bloque y uno de ellos terminar escribiendo una copia antigua encima de la actualización del otro. La transmisión rápida acorta la oportunidad de ese agujero de escritura.

La durabilidad sigue otra cadena. El atributo no determina stable_how4. El borrador fija un invariante distinto: al regresar con éxito la llamada de escritura de la aplicación, los datos deben ser duraderos en el servidor. El cliente puede usar FILE_SYNC4 o DATA_SYNC4. Si usa UNSTABLE4, el COMMIT tiene que finalizar antes de devolver el control. Un cambio en el verificador obliga a repetir los WRITEs afectados mientras el búfer de la aplicación aún existe.

Retener temporalmente esos bytes para completar el intercambio no es la caché duradera que se quiere suprimir. Y el camino inverso también importa: activar el booleano no corrige un COMMIT ausente. “No almacenable en caché” es una política sobre copias de datos, no un recibo de persistencia.

La visibilidad de lectura añade más condiciones. Si el cliente conserva datos leídos, no debería reutilizarlos sin revalidar el atributo de cambio y el tamaño. Una delegación puede ofrecer coherencia por otra vía. En pNFS, el servidor de metadatos entrega el atributo, mientras los datos pueden ir directamente a dispositivos de almacenamiento. Que los bytes sean duraderos allí y que el layout los haga visibles son hechos diferentes. Si se necesita LAYOUTCOMMIT, retrasarlo puede dejar a otro cliente viendo metadatos anteriores.

También hay una frontera temporal. Si el atributo cambia mientras el archivo está abierto, el cliente puede mantener la decisión de caché tomada en OPEN durante toda esa apertura. La expiración de atributos, la revalidación y un OPEN posterior limitan la demora. Un true leído hoy no describe necesariamente las sesiones abiertas ayer.

El atributo tampoco adquiere autoridad de seguridad. La política existente del servidor decide quién puede activarlo o borrarlo. El borrador no añade autenticación, no cambia el control de acceso y no crea una barrera de seguridad. Los mecanismos de coherencia e integridad de NFSv4.2 siguen teniendo sus propias responsabilidades.

La revisión 16 declara un prototipo de servidor Hammerspace y un prototipo de cliente Linux. Se observaron beneficios con operaciones de E/S bien formadas. Es evidencia de que la idea puede ejecutarse, no de despliegue amplio, compatibilidad entre productos, activación predeterminada ni mejora universal. El propio texto exige comprobar en operación qué cambia con el atributo y si el cliente realmente lo honra.

Por eso el registro útil no es un único bit. Debe enlazar la revisión de la norma, el soporte de la exportación, la política del servidor, el valor visto por un cliente identificado, el momento de OPEN, la versión del cliente, el modo de estabilidad del WRITE, el verificador y COMMIT, cualquier LAYOUTCOMMIT, la revalidación de lectura y el resultado de la aplicación. El booleano inaugura el expediente; no lo resuelve.

Fuentes