Resumen

  • Para un directorio marcado, un cliente que respeta la revisión 11 no puede reutilizar en una enumeración los resultados READDIR de otra, ni informar para una entrada un atributo recibido antes del READDIR que acaba de devolverla.
  • La obligación describe la salida observable. No prohíbe toda caché, no vuelve actual para siempre el estado del servidor y no desplaza un valor más reciente que posea el cliente con delegación de escritura.
  • El control puede evitar omisiones silenciosas en copias y sincronizaciones, pero añade trabajo al servicio de metadatos y carece de una prueba protocolaria de que todos los clientes lo cumplen.

La revisión corrige la unidad equivocada

draft-ietf-nfsv4-uncacheable-directories-11 apareció el 5 de septiembre de 2026. Es un documento activo del grupo de trabajo NFSv4 y sigue la vía de estándares. Describe prototipos de servidor Hammerspace y cliente Linux, pero continúa siendo un Internet-Draft: no es un RFC, una aprobación del IETF ni un censo de despliegue.

La revisión 10 pedía obtener los metadatos del servidor «en cada READDIR». El problema es lógico: READDIR ya es la operación de red que consulta al servidor. Cumplir esa frase no impedía que, después de recibir nombres nuevos, el cliente presentara un tamaño antiguo guardado en su caché normal de atributos.

La revisión 11 cambia la pregunta. Ya no intenta decir cómo debe organizarse la memoria. Dice qué resultado queda prohibido. Un nuevo recorrido de un directorio marcado no puede servirse con resultados de un recorrido anterior. Si el READDIR más reciente devuelve la entrada a, el cliente no puede informar para a un valor que recibió antes de ese READDIR, sin importar si llegó por otro READDIR, GETATTR o una operación diferente.

El criterio admite una prueba externa: enumerar, modificar el archivo desde otro cliente, enumerar de nuevo y observar con stat. La caché puede seguir existiendo. Lo que no puede sobrevivir como respuesta del segundo recorrido es la medida previa a su READDIR.

Los nombres y sus atributos obedecen relojes distintos

El directorio contiene pares de nombre y fileid. Su atributo change detecta altas, bajas y renombrados. Sin embargo, escribir más bytes en un archivo ya existente no altera ni el nombre ni el fileid ni, necesariamente, el change del directorio. Los atributos del archivo —size, time_modify, time_metadata, time_access— pertenecen a otra capa.

RFC 8881 permite conservar esos atributos durante un intervalo acotado. En un directorio estable, el ahorro es razonable. En salidas de computación de alto rendimiento o zonas de entrada donde muchos productores escriben a la vez, incluso una vida corta puede dejar casi todas las medidas por detrás de los archivos. Verificar cada hijo con GETATTR eliminaría la ventaja de pedir atributos junto a READDIR.

La consecuencia puede ser material. Una copia incremental o una herramienta que decide por tamaño y fecha puede saltarse un archivo modificado. El nuevo atributo permite que el servidor seleccione los directorios donde ese daño esperado justifica pagar por otra observación. No certifica los directorios donde el atributo sea falso.

Un recorrido no equivale a una llamada de red por nombre

La precisión terminológica evita otro exceso. readdir en minúscula es la solicitud de la aplicación. READDIR en mayúscula es la operación NFSv4.2. Una enumeration es un paso por el directorio y puede incluir muchas llamadas de aplicación atendidas por varios READDIR de continuación. Un solo READDIR suele llenar numerosas llamadas readdir.

Por eso la norma no exige una operación de red por entrada. Exige que el paso actual obtenga sus propios resultados de servidor. El cliente debería incluir en attr_request los atributos que mostrará. Puede obtenerlos después, pero entonces pagará un GETATTR por hijo y convertirá la corrección en una tormenta de peticiones.

Tras terminar el recorrido, el cliente puede conservar las medidas. Hasta la siguiente enumeración siguen rigiendo las reglas normales de vida de caché. En el siguiente recorrido, una medida anterior deja de ser admisible para la entrada que READDIR acaba de devolver. El contrato se refiere a procedencia temporal de la respuesta, no a ausencia física de caché.

La activación también tiene dos tiempos

Cuando el servidor cambia el atributo a verdadero, el cliente puede seguir viendo el valor anterior en los atributos cacheados del directorio. La revisión 11 explica cómo se cierra esa ventana: expira el límite superior de la caché o una revalidación detecta el movimiento de change. No hay obediencia instantánea a una política que el cliente todavía no ha observado.

Esa distinción debe quedar en la evidencia operativa. La hora de SETATTR es la declaración del servidor. La primera lectura del nuevo valor es conocimiento del cliente. La primera enumeración que rechaza el dato viejo es el efecto visible. Colapsar las tres en una marca temporal fabrica certeza.

Las delegaciones de directorio son incompatibles con el retorno obligatorio al servidor. Si el atributo se activa, el servidor debe revocar una delegación pendiente y no conceder otra mientras permanezca activo. Las notificaciones sobre cambios de hijos no son sustituto general: son opcionales, no están disponibles en todas las pilas y su coste puede multiplicarse por clientes y cambios.

A veces el cliente sabe más que el servidor

Existe una excepción que revela por qué «respuesta del servidor» tampoco equivale a verdad absoluta. Un cliente con OPEN_DELEGATE_WRITE puede tener valores de size o change más recientes que la copia del servidor. El servidor recurre a CB_GETATTR para consultarlos porque la autoridad actual reside temporalmente en el cliente delegado.

La revisión 11 no obliga a sustituir esa medida nueva por una más vieja del servidor. La prohibición se dirige a valores anteriores a lo que el servidor devolvería. La frescura depende de la autoridad de escritura y del instante, no solo del número de viajes por la red.

Además, una respuesta recibida ahora puede envejecer un instante después. El mecanismo no forma una instantánea distribuida entre datos y metadatos. Solo garantiza que el cliente que honra el atributo no atribuya al recorrido actual una medida que ya poseía antes de recibir esa entrada.

El directorio gobierna un camino, no el inode completo

El atributo se aplica por directorio. Un archivo con enlaces físicos en un directorio marcado y otro no marcado recibe dos contextos: el segundo camino no hereda el comportamiento del primero. Tampoco existe propagación protocolaria a subdirectorios; la herencia, si la hay, es política local.

La revisión también separa soporte y aplicabilidad. Como el soporte se anuncia por sistema de archivos, GETATTR sobre un objeto que no sea directorio devuelve FALSE; SETATTR sobre el tipo incorrecto devuelve NFS4ERR_WRONG_TYPE. El sistema puede conocer la extensión sin que ese objeto sea un destino válido para activarla.

Conocer el campo no demuestra obediencia

El atributo es consultivo. Un cliente que lo consulta demuestra que entiende el identificador, no que aplica la regla. El servidor no puede distinguir de forma fiable entre un cliente que honra, uno que conoce pero ignora y otro que ni siquiera implementa la extensión. Por eso no debe basar su propia corrección en un cumplimiento universal.

La carga completa el límite. Cada recorrido marcado vuelve al servidor; una ruta pobre que añada GETATTR por entrada cuesta aún más. Si un usuario sin privilegios puede activar el atributo en un árbol caliente, una sola modificación puede imponer trabajo a todos los clientes. La autorización, la política de exportación y el presupuesto de capacidad no son detalles posteriores.

La evidencia pública no establece versiones distribuidas, prevalencia, cifras de carga, incidentes ni resultados de producción. El borrador separado sobre datos no almacenables en caché aborda contenido y durabilidad, no amplía esta regla de metadatos. Como en las capas de realidad de Heng Lu, el bit configurado, el estado privado, la observación del servidor y la respuesta de la aplicación tienen que conservar derecho a discrepar.

Fuentes