Resumen

  • NFS recorre nombres para localizar un archivo, pero usa después una referencia opaca creada por el servidor. El cliente puede guardarla y devolverla; no puede convertirla en un número de inode, una dirección física ni una identidad válida fuera de ese servidor.
  • NFSv4 hizo explícita la duración. Una referencia persistente conserva su valor durante la vida del objeto a través de reinicios y migraciones; una referencia volátil puede caducar en condiciones que el servidor debe revelar.
  • NFS4ERR_STALE indica que el referente fue eliminado o dejó de estar disponible. NFS4ERR_FHEXPIRED admite que una referencia temporal perdió continuidad aunque el objeto quizá siga existiendo. Recuperar exige recorrer de nuevo el espacio de nombres y volver a comprobar el resultado.

Después del reinicio, el nombre no basta

Un cliente conserva una referencia a un archivo, el servidor reinicia y, entretanto, alguien cambia el nombre del archivo. Repetir la ruta antigua puede fallar; confiar ciegamente en los bytes guardados puede ser peor. El problema contiene tres preguntas distintas: cómo se encuentra el objeto, qué identidad reconoce el servidor y si esa identidad sobrevivió al cambio.

El NFS de 1989 ya separaba las dos primeras. El RFC 1094 describía un recorrido componente a componente. El protocolo de montaje proporcionaba una referencia inicial; LOOKUP recibía la referencia de un directorio y un nombre, y devolvía otra referencia. Operaciones como READ, WRITE y GETATTR utilizaban después esos 32 bytes, no la ruta completa.

La referencia era opaca. No estaba obligatoriamente cifrada ni tenía que ser difícil de adivinar. Opacidad significaba que el cliente no conocía su estructura contractual. Un servidor podía construirla con datos de su sistema de archivos, pero ningún cliente interoperable debía extraer de ella un inode, una ubicación de disco o un formato duradero.

NFSv3, en el RFC 1813, permitió una longitud variable. nfs_fh3 llevaba la información que el servidor necesitaba para distinguir el archivo y aparecía como resultado de LOOKUP, CREATE, LINK o READDIRPLUS, entre otras operaciones. El cambio de tamaño mostró la ventaja del límite: la implementación podía evolucionar sin convertir su representación interna en una dependencia de todos los clientes.

Lo que una comparación sí puede decir

Los bytes opacos todavía pueden compararse. Sin embargo, NFS limita la conclusión. Dos referencias iguales obtenidas del mismo servidor identifican el mismo archivo. Dos referencias distintas no demuestran que haya dos archivos distintos. El servidor no tiene que mantener una relación uno a uno entre objetos y secuencias de bytes.

El RFC 1813 presenta esa comparación como una ayuda de rendimiento y no como una base de corrección. NFSv4 conserva el principio. Los dos nombres de un enlace físico deberían devolver la misma referencia, pero el cliente no puede convertir cada desigualdad en una frontera ontológica. Tampoco puede comparar referencias de servidores arbitrarios como si fueran hashes globales.

La regla impide que una caché usurpe la autoridad del servidor. Puede eliminar trabajo cuando reconoce igualdad. No puede decidir, por su cuenta, que dos operaciones nunca alcanzarán el mismo objeto ni reconstruir la topología del almacenamiento a partir del aspecto de una referencia.

La persistencia se volvió una propiedad observable

El RFC 3010 introdujo para NFSv4 dos clases: referencias persistentes y volátiles. Los RFC 7530 y 8881 mantienen la distinción.

Una referencia persistente debe permanecer fija durante la vida del objeto. Sobrevive al reinicio del servidor. También debe conservar continuidad cuando el objeto migra, de modo que el movimiento del almacenamiento no se convierta en un cambio arbitrario de identidad para el cliente.

Esa promesa termina con el objeto o con su disponibilidad. Si se elimina el archivo, o si el sistema de archivos deja de estar accesible, la respuesta es NFS4ERR_STALE. Persistencia no equivale a eternidad. Equivale a no reutilizar silenciosamente la referencia vieja para otra cosa mientras la promesa está vigente.

Hay servidores que no pueden ofrecerla siempre. Un sistema jerárquico, una tabla reconstruida, ciertas interfaces del sistema operativo o una migración pueden romper la interpretación de una referencia. Para esos casos existen las referencias volátiles. El servidor informa con fh_expire_type en qué circunstancias pueden expirar.

Los RFC muestran una posible construcción con instante de arranque, posición en una tabla y número de generación. Si la posición se reutiliza, la generación vieja deja de ser válida. Es una ilustración, no el formato obligatorio. El estándar regula la conducta visible en la red, no la ingeniería interna escogida por cada servidor.

Obsoleta y caducada no son sinónimos

La diferencia entre NFS4ERR_STALE y NFS4ERR_FHEXPIRED evita una afirmación falsa. La primera respuesta dice que la referencia ya no llega al objeto esperado: este fue eliminado o el sistema de archivos persistente no está disponible.

La segunda dice que una referencia volátil ha perdido su continuidad. Quizá desapareció la tabla que la interpretaba, cambió una generación o la migración superó su garantía. El archivo puede seguir en el servidor. Lo que ya no existe es el derecho del cliente a presentar los mismos bytes como una referencia vigente.

Si una aplicación traduce ambos resultados por “archivo inexistente”, puede anunciar pérdida de datos donde solo perdió una referencia. Si trata ambos como fallos transitorios, puede repetir indefinidamente una operación contra un objeto eliminado. El protocolo no elimina la incertidumbre; evita que una capa inferior invente una certeza para la superior.

Volver a recorrer no equivale a volver al mismo objeto

NFSv4 incorpora referencias especiales de raíz. PUTROOTFH establece el punto de partida y LOOKUP avanza por los componentes. Un cliente que guardó los nombres puede utilizar el mismo recorrido después de FHEXPIRED para obtener una referencia nueva.

Pero el espacio de nombres también cambia. Un tercero pudo renombrar el archivo. Pudo borrarlo y crear otro con el nombre antiguo. Una ruta recompuesta puede conducir al original, a un sustituto o a nada. El cliente debe validar de nuevo atributos, estado, bloqueos y cualquier supuesto asociado a la referencia anterior.

La autorización forma otra frontera. Una referencia válida no es una capacidad que conceda lectura o escritura. El servidor evalúa el acceso de cada operación. Resolver el nombre de nuevo tampoco renueva automáticamente un permiso ni vuelve segura la repetición de una modificación interrumpida.

NFS ganó flexibilidad al reservar la interpretación al servidor. Ganó seguridad semántica al obligarlo a declarar la duración y el fracaso. Y dejó una tarea al cliente: conservar suficiente contexto de nombres para recuperarse, sin fingir que ese contexto demuestra una continuidad que acaba de perder.

La ruta responde dónde buscar. La referencia responde qué reconoce el servidor. El error responde si esa relación sigue viva. Confundir esas respuestas habría hecho el sistema más sencillo solo en apariencia.

Fuentes