Resumen

  • RFC 3010 separó el nombre estable del cliente de su encarnación en ejecución: el verifier que cambiaba al reiniciar, el clientid negociado y la confirmación autenticada impedían que un nombre heredara por sí solo los bloqueos anteriores.
  • Cuando el servidor perdía estado, un período de gracia normalmente igual al arrendamiento daba prioridad a los reclaims y retenía nuevos bloqueos y E/S conflictivos. La continuidad era una recuperación con fecha límite, no una propiedad perpetua.

La avería no había borrado el archivo. Había borrado la memoria de quién podía impedir que otro lo usara. El cliente seguía guardando un stateid y la convicción de que poseía un bloqueo; el servidor recién arrancado no reconocía ninguno. Aceptar la siguiente petición como si nada hubiera ocurrido premiaría al primero que llegara después del fallo.

La RFC 3010, publicada en diciembre de 2000 como primera especificación completa de NFSv4, diseñó una respuesta para esa discordancia. Al integrar bloqueo y estado de apertura, el protocolo necesitaba definir qué parte de una autoridad sobrevivía, cómo se demostraba y cuándo dejaba de obligar a los demás.

Primero distinguió cliente de encarnación. El cliente aportaba un identificador opaco relativamente estable y un verifier que debía cambiar al inicializarse de nuevo. Un nombre de máquina no distingue la memoria anterior del proceso actual. El verifier hacía visible esa frontera de arranque.

SETCLIENTID presentaba ambos valores bajo el principal autenticado de la llamada RPC. El servidor devolvía un clientid abreviado y otro verifier para confirmar; SETCLIENTID_CONFIRM cerraba el intercambio. El clientid servía para referirse con eficiencia al estado de ese servidor. No era identidad universal, escritura de propiedad ni credencial que autorizara por mera posesión.

La igualdad del nombre podía descubrir un problema. Dos equipos mal configurados o clonados podían usar el mismo identificador. NFS4ERR_CLID_INUSE permitía rechazar la fusión. Que dos afirmaciones lleven la misma etiqueta no demuestra que pertenezcan al mismo actor; a veces demuestra justo lo contrario.

Si el principal correcto volvía con un verifier distinto, el servidor podía inferir un nuevo arranque que ya no conservaba el estado volátil antiguo. Entonces podía liberar los bloqueos ligados al clientid previo. Pero esa declaración debía estar autenticada: sin ese límite, cualquiera podría fingir el reinicio de otro cliente y borrar sus exclusiones legítimas.

Después venía el tiempo. El servidor definía un lease común para el estado del cliente. Operaciones ordinarias renovaban implícitamente el plazo y RENEW cubría períodos de inactividad. La renovación abarcaba todo el conjunto de estado, de modo que mil bloqueos no exigían mil latidos.

El lease protegía temporalmente; no concedía dominio permanente. Sin renovación, el servidor podía recuperar el estado y otorgar conflictos una vez vencido el plazo. Tras una partición larga, el cliente podía recibir NFS4ERR_EXPIRED al usar su viejo stateid. Debía informar a la aplicación de que había perdido exclusión, no actuar como si su recuerdo local siguiera gobernando al servidor.

Un reinicio del servidor invertía el problema. Los clientes mantenían identificadores que parecían válidos, pero el servidor había estrenado época. NFS4ERR_STALE_CLIENTID y NFS4ERR_STALE_STATEID acreditaban esa discontinuidad. El cliente debía negociar otro clientid y recuperar estado, en vez de reenviar trabajo ordinario dentro de un espacio ya muerto.

El grace period establecía la prioridad. Durante aproximadamente un lease, los clientes anteriores enviaban LOCK y OPEN de reclaim, incluido CLAIM_PREVIOUS. La conducta sencilla y segura era devolver NFS4ERR_GRACE a nuevos bloqueos, aperturas, lecturas y escrituras. El servidor estaba disponible, pero aún no ejercía libremente la facultad de crear conflictos.

Esa negativa protegía a quienes todavía no habían regresado. Detectar el reinicio y recomponer el inventario lleva tiempo. Si una petición nueva pudiera ocupar el espacio antes, la latencia posterior al fallo decidiría la titularidad. La gracia concedía una oportunidad finita a las afirmaciones antiguas y, al terminar, evitaba que un cliente muerto mantuviera veto eterno.

El servidor podía trabajar antes si conservaba pruebas suficientes. Necesitaba garantizar que ninguna reclamación posterior chocaría ni sería rechazada por la nueva operación. Registros estables de bloqueos o recuentos podían reducir el ámbito de la pausa. La optimización nacía de evidencia conservada, no de suponer que un proceso activo ya conocía toda la historia.

Fuera de la ventana, un reclaim tardío solo podía triunfar si no se había concedido bloqueo o E/S conflictiva desde el reinicio. Después de crear derechos nuevos, restaurar a ciegas uno antiguo dañaría al otro lado. El límite temporal convirtió una espera potencialmente infinita en un coste previsible.

La RFC 2624 había explicado las tensiones de diseño. RFC 3010 fue sustituida por la RFC 3530, y la RFC 7530 es una formulación posterior de NFSv4.0. Este texto estudia el nacimiento del mecanismo, no prescribe una configuración actual.

NFSv4.1 profundizó la contabilidad. La RFC 5661 añadió EXCHANGE_ID y sesiones; su sustituta, la RFC 8881, muestra con detalle que la tolerancia posterior a un reinicio depende de cuánto estado del cliente se guarde de forma estable. Cuanto mayor la promesa de continuidad, mayor la obligación de custodia.

Leído con Running-Code Primacy de Lu Heng, el derecho real no vive en el nombre del cliente. Aparece cuando el servidor puede ejecutar las comprobaciones: principal, encarnación, lease, modo reclaim, ventana y ausencia de conflicto posterior. La capa mínima común impide que el recién llegado gane solo porque el fallo le dio ventaja de llegada.

La Stability Fallacy confundiría la continuidad del nombre, montaje o dirección con continuidad de autoridad. RFC 3010 hizo lo contrario: declaró stale lo perdido, suspendió nuevos conflictos y exigió reconstruir los recibos. El bloqueo no sobrevivió porque el cliente lo recordara. Tuvo una oportunidad porque el protocolo recordaba en qué orden resolver el olvido.

Sources