Resumen

  • La versión 12 del borrador del grupo NFSv4 añade una explicación específica de pNFS; continúa siendo un Internet-Draft activo, no un RFC.
  • Refrescar los atributos de una entrada elimina un valor viejo guardado por el cliente, pero no adelanta el momento en que el servidor de metadatos conoce una escritura.

Pensemos en un proceso de sincronización que compara el tamaño y la fecha de modificación de miles de archivos. Otro equipo escribe en uno de ellos, pero no cambia su nombre. El atributo de cambio del directorio puede permanecer igual, porque registra el directorio y sus entradas, no cada escritura sobre los archivos que contiene. Si el cliente responde a la siguiente enumeración con atributos guardados, el proceso puede decidir que no hay nada que copiar.

El borrador introduce una señal por directorio para evitar esa parte del problema: un cliente que la respete hace READDIR en cada enumeración y no presenta, para una entrada, valores retenidos desde antes del READDIR que la devolvió por última vez.

La señal no nació con esta versión. Ya aparecía en el texto del 5 de septiembre. La versión del 26 de septiembre concreta que el deber tiene dos mitades: ir al servidor de nuevo y comunicar los atributos que ese intercambio proporcionó, no una mezcla con la antigua caché local. Pedir pocos atributos en READDIR y rellenar el resto con datos viejos no sirve. El cliente puede solicitar los valores necesarios en la lectura o recuperarlos después; esta segunda opción puede multiplicar las consultas GETATTR. Tampoco se prohíbe guardar los datos del archivo ni se convierte la caché de todo el montaje en una excepción.

La adición más importante para la operación está en el nuevo apartado 5.2. En pNFS, el servidor de metadatos proporciona el directorio y su atributo; otro dispositivo atiende las operaciones de datos. En los diseños donde aquel servidor solo se entera del nuevo tamaño y de time_modify cuando llega LAYOUTCOMMIT, un READDIR anterior al commit aún devuelve las cifras anteriores. El cliente que se limita a informarlas puede estar cumpliendo plenamente el borrador. El desfase ya no está en su caché, sino en la frontera entre el dispositivo que recibió la escritura y la autoridad que responde por los metadatos.

Esa precisión impide vender una promesa mayor que la especificada. «Recién leído» significa reciente respecto de una enumeración previa del cliente; no garantiza una vista atómica de todas las escrituras. El ejemplo del borrador depende del tipo de layout y de su mecanismo de actualización. No describe necesariamente a cada despliegue pNFS ni prueba que se haya producido un fallo real en una instalación concreta.

La revisión también afina la respuesta a quien quiera activar la señal. El atributo booleano puede consultarse y fijarse por directorio, pero la política local del servidor puede negar SETATTR. La negativa debe devolver NFS4ERR_ACCESS o, en el supuesto de propiedad y privilegios indicado, NFS4ERR_PERM. No debe usar NFS4ERR_INVAL, porque una prueba de compatibilidad interpretaría ese código como desconocimiento del atributo. Que el servidor sepa hacerlo y no permita hacerlo son hechos distintos; un panel de control no debería reducirlos al mismo estado.

El Datatracker registra un documento de grupo de trabajo aún en fase «I-D Exists». Su apartado de implementación menciona prototipos de servidor Hammerspace y cliente Linux, no una garantía de interoperabilidad ni un resultado observado en producción. La capacidad propuesta exige comprobar quién la activa, quién la respeta y cuándo llega el dato correcto al servidor que responde.

Fuentes