Resumen

  • La RFC 1094 afirma que un servidor NFS sin estado no puede preservar el caso en que un proceso mantiene abierto un archivo cuyo nombre ya se quitó del directorio.
  • El memorando sugiere una salida del lado cliente: renombrar el archivo al borrarlo y retirar ese nombre provisional al cerrar. No fija una implementación común ni explica cómo debe recuperarse un cliente que falla antes del cierre.

El directorio ya no lo mostraba; el proceso todavía lo usaba

Un programa abre un archivo y comienza a leerlo. Después, otra acción elimina su nombre del directorio. En algunos sistemas locales, quitar la entrada no cancela la referencia que el proceso ya tiene: el nombre deja de aparecer, mientras el proceso puede seguir trabajando hasta cerrar.

En un sistema de archivos remoto, esa diferencia se reparte entre máquinas. La aplicación ve un árbol montado dentro de su sistema operativo. El servidor recibe procedimientos de red independientes. Para decidir si puede liberar el objeto, tendría que saber si algún proceso de un cliente conserva una apertura.

La RFC 1094, publicada en marzo de 1989 para NFS versión 2, no convierte esa convención local en una garantía del protocolo. Dice que un servidor sin estado no puede proporcionar el comportamiento de un archivo abierto que se elimina del directorio y sigue utilizable. Como alternativa, propone que el cliente renombre el archivo al eliminarlo y lo quite una vez cerrado.

Esa observación desplaza la pregunta: no solo importa qué operación salió por la red, sino qué máquina tiene el dato necesario para decidir cuándo terminó la vida útil del archivo.

NFSv2 no enviaba una sesión remota de apertura

La interfaz de NFSv2 ofrece procedimientos como LOOKUP, READ, WRITE, CREATE, REMOVE y RENAME. REMOVE actúa sobre un nombre dentro de un directorio. No existe una operación NFSv2 OPEN o CLOSE que informe al servidor del comienzo y el final de la última apertura de un cliente.

El cliente sí presenta file handles emitidos por el servidor para operaciones sobre archivos. Pero el identificador no es un aviso de que un proceso local haya abierto el archivo ni de que siga usándolo. El sistema cliente puede resolver open() dentro de su núcleo y su implementación NFS sin crear un registro de apertura en el servidor.

Así, el servidor puede recibir la retirada de un nombre sin conocer el vínculo que todavía mantiene un proceso remoto. La RFC no dice que el cliente no pueda imitar esa semántica; dice que el servidor stateless no puede hacerlo por sí mismo. La adaptación recae en el lado que conoce la apertura local.

El renombrado aplazaba la eliminación real

La propuesta altera el orden de las operaciones. En vez de borrar de inmediato la entrada, el cliente la renombra a un nombre temporal. El proceso deja de ver el nombre original, pero el cliente recuerda que el nombre provisional debe quitarse cuando se cierre la referencia. El servidor conserva una entrada que puede representar mientras el cliente sostiene el comportamiento local.

El espacio de nombres y la ocupación del almacenamiento dejan de coincidir en el tiempo. Para el usuario, el nombre puede haber desaparecido; en el servidor, el objeto puede seguir reservado. Un unlink que parece una sola acción se convierte en dos momentos: ocultar el nombre original ahora y limpiar el nombre temporal más tarde.

La RFC 1094 no prescribe cómo nombrar la entrada provisional, cómo evitar colisiones, ni qué hacer si el cliente se reinicia antes del cierre. Tampoco establece cómo deben verla otros clientes. Es un truco de compatibilidad, no una transacción distribuida completa. No demuestra que un producto concreto de la época lo implementara de una manera determinada.

Una consecuencia operativa posible es que la eliminación visible y la recuperación de espacio se separen. La entrada temporal podría durar más de lo esperado o una limpieza tardía podría fallar. Esas posibilidades se desprenden del trabajo diferido, pero el memorando no documenta su frecuencia ni una incidencia concreta.

La falta de estado era de protocolo, no del sistema de archivos

El objetivo de NFS era que el servidor no necesitara mantener el estado de protocolo de cada cliente para operar correctamente. Tras una interrupción, el cliente podía repetir solicitudes en vez de reconstruir una conversación de apertura. Los datos, atributos y entradas de directorio seguían teniendo estado en el sistema de archivos y el almacenamiento.

La vida de una apertura local no encajaba en el modelo mínimo del servidor. NFS exponía operaciones de archivo a través de la red, sin convertir todas las convenciones de un núcleo local en parte del contrato remoto. El bloqueo de archivos y registros también quedaba fuera del protocolo de esta RFC y pertenecía a servicios separados.

Las versiones posteriores repartieron ese trabajo de otro modo. NFSv3 mantiene procedimientos de archivo sin OPEN y CLOSE remotos; NFSv4, descrito en la RFC 7530, sí incorpora esas operaciones y stateids. Esto no prueba una migración universal ni el mismo comportamiento en todas las instalaciones. Muestra que es posible convertir el estado de apertura en una obligación del protocolo, con una coordinación mayor.

La compatibilidad necesita un responsable

El servidor administra el directorio exportado y ejecuta REMOVE. El cliente conoce el estado de los procesos que todavía mantienen abierto un archivo. Si el servidor nunca recibe ese hecho, no puede decidir cuándo suprimir el objeto sin arriesgarse a quebrar la conducta local. El renombrado propuesto conecta ambas capas aplazando la eliminación.

La adaptación requiere una convención de nombres, seguimiento local y una regla de limpieza. Una aplicación que depende de leer o escribir tras quitar el nombre debe verificar ese comportamiento en el par cliente-servidor que usa. El operador del servidor puede necesitar entender por qué sigue existiendo una entrada después de desaparecer su nombre visible. El RFC no define a fondo la política de ninguna de las dos partes.

La limitación no convierte a NFSv2 en un error de diseño. Mantener sencillo el servidor tenía valor; el texto también identificó la semántica que quedaba fuera y una posible adaptación en el cliente. El coste se repartía: menos estado en el servidor, más trabajo en el cliente y pruebas específicas para las aplicaciones que dependían de la convención local.

Fuentes y límites de la evidencia

Las RFC documentan interfaces y decisiones de diseño. No miden cuánto se usó el renombrado provisional, cómo lo recuperaba un cliente específico tras una caída ni con qué frecuencia ocurría el problema.