Resumen

  • La declaración de recuperación completa cierra las reclamaciones antiguas que un cliente todavía no ha recuperado dentro de su ámbito. No renuncia a los derechos de recuperación de otros clientes.
  • Un cliente que ya ha terminado puede seguir recibiendo un error de periodo de gracia cuando solicita un bloqueo nuevo.
  • Las particiones de red y los reinicios sucesivos pueden ocultar una interrupción real de la protección. El servidor necesita un historial persistente suficiente para reconocer los peligros conocidos o debe rechazar las recuperaciones de forma conservadora.

Una respuesta distinta desde cada extremo

Imaginemos que dos clientes mantenían bloqueos en un servidor de archivos. El servidor se reinicia y pierde el estado de esos bloqueos. Uno de los clientes vuelve enseguida, restablece sus aperturas y recupera sus bloqueos de rangos de bytes. El otro permanece aislado por una avería de red.

El primero puede afirmar que su recuperación ha terminado. Sin embargo, el servidor no sabe todavía si el ausente volverá con una reclamación anterior que chocaría con un bloqueo concedido ahora. Haber terminado antes no da al cliente la facultad de responder en nombre del que falta.

La escena es ilustrativa, no un incidente observado. Las secciones 8.4, 9.11 y 18.51 del RFC 8881 explican por qué NFSv4.1 permite que un cliente complete su recuperación y, después, reciba NFS4ERR_GRACE al pedir un bloqueo nuevo. No son necesariamente respuestas contradictorias: una cierra una obligación individual; la otra mantiene una condición de admisión del servidor.

El trabajo antiguo no compite como si fuera nuevo

Cuando el servidor pierde el estado de bloqueo, debe ofrecer una oportunidad para recuperar los estados anteriores sin que concesiones nuevas e incompatibles se adelanten a ellos. El periodo de gracia protege esa oportunidad. No es simplemente un retraso general destinado a que todas las máquinas terminen de arrancar.

Las operaciones distinguen ambos propósitos. Para recuperar una apertura existente se utiliza OPEN con CLAIM_PREVIOUS y el identificador opaco de archivo actual del objeto. No se abre un nombre nuevo desde un directorio. Para recuperar un bloqueo de un rango de bytes se usa LOCK con reclaim verdadero.

Presentar una petición como recuperación no elimina los controles normales. El cliente sigue sujeto a permisos y conflictos. El pasado que invoca no le permite obtener un acceso que no estaría autorizado en condiciones equivalentes de funcionamiento ordinario.

Tampoco queda prohibida cualquier actividad durante la gracia. Establecer la identidad del cliente y la sesión forma parte de la recuperación. El servidor puede admitir nuevos bloqueos o determinadas lecturas y escrituras si dispone de información suficiente para excluir incompatibilidades con reclamaciones posteriores. Cuando no la tiene, una tabla actual vacía no demuestra que nadie conserve una reclamación recuperable. Puede faltar precisamente el cliente que aún no ha podido enviarla.

La declaración que reduce lo que queda por reclamar

La forma global de RECLAIM_COMPLETE utiliza rca_one_fs falso. Tras establecer un identificador de cliente nuevo, debe enviarse antes de solicitar el primer bloqueo nuevo. La obligación también existe si no había bloqueos antiguos. No tener nada que recuperar no equivale a dejar que el servidor lo suponga.

Esa declaración tiene un efecto definitivo sobre las reclamaciones pendientes de su ámbito. Los bloqueos antiguos todavía no recuperados ya no podrán reclamarse como tales durante esa recuperación, en otra instancia posterior del servidor o después de la transferencia correspondiente a otro servidor.

Por tanto, no es una simple cifra de avance. Permite al servidor dejar de reservar una posibilidad para nuevas reclamaciones antiguas de ese cliente. El cliente obtiene un cierre al precio de abandonar lo que no ha recuperado.

La certeza no se extiende a otros participantes. El servidor puede descontar al declarante de su incertidumbre, pero no a quienes siguen pendientes. Una declaración local puede reducir el conjunto que falta sin vaciarlo.

La operación también dispone de una forma por sistema de archivos vinculada a la migración. Requiere un identificador de archivo actual y no sustituye la declaración global asociada al nuevo identificador de cliente. En un sistema de archivos ajeno a la situación de migración correspondiente, la especificación contempla una respuesta satisfactoria sin otro efecto. Aquí se analiza el reinicio del servidor; la migración aparece solo para no mezclar los ámbitos de finalización.

Hace falta saber quién podría faltar

Si el servidor conserva de manera estable qué clientes podrían haber tenido bloqueos, puede determinar cuándo todos los pertinentes han terminado. Así, las declaraciones recibidas se comparan con un conjunto conocido, no solo con quienes ya lograron volver.

Esa información puede permitir un cierre anticipado de la gracia. También es posible que el periodo termine antes de que todos hayan completado la recuperación. Pero no se trata de una licencia para acortar arbitrariamente la oportunidad de retorno.

La sección 8.4.2.1 vincula el periodo al plazo de la concesión temporal, o lease. Indica que no debería concluir antes de ese plazo y, al tratar un cambio del valor, exige que la gracia dure al menos lo que duraba el lease de la instancia anterior. No establece un número universal de segundos para todas las instalaciones. Conserva una relación con las condiciones bajo las cuales los clientes operaban antes del fallo.

Hay, pues, dos momentos que observar: el cierre propio del cliente y la posibilidad del servidor de admitir una petición nueva concreta. Un cliente listo que todavía espera puede estar viendo el coste de proteger reclamaciones ajenas, no el fracaso de su propio cierre.

La ausencia de conflicto puede ser engañosa

El RFC plantea un caso que muestra por qué el presente no basta. Un cliente no consigue renovar su lease durante una partición de red. El plazo vence y el servidor libera su bloqueo. Un segundo cliente obtiene un bloqueo que habría entrado en conflicto con el primero, trabaja y lo libera. Después se reinicia el servidor.

Cuando desaparece la partición, el primer cliente vuelve durante la nueva gracia y pretende recuperar su bloqueo antiguo. Ya no tiene por qué existir un bloqueo contrario en la tabla. Aun así, aceptar la recuperación puede ser incorrecto: el segundo cliente pudo modificar el objeto durante el intervalo en que el primero había perdido su protección.

El problema no es necesariamente conceder dos bloqueos incompatibles a la vez. Es tratar como continua una protección que dejó de existir. Una tabla presente sin conflictos puede ocultar ese hecho.

Un segundo ejemplo atraviesa dos reinicios. El cliente no completa sus recuperaciones durante la primera gracia; otro obtiene después un bloqueo incompatible; se produce un nuevo reinicio; el primero regresa por fin. La apertura de una nueva ventana no elimina la importancia de haber perdido la anterior.

La especificación obliga al servidor a elegir entre rechazar todas las recuperaciones con NFS4ERR_NO_GRACE o guardar suficiente estado estable para detectar las situaciones peligrosas conocidas relacionadas con reinicios. Es admisible una negativa conservadora que un historial más completo habría evitado. Si la información persistente está dañada de forma irrecuperable, deben rechazarse las reclamaciones que puedan estar afectadas.

El texto muestra un ejemplo mínimo de registro por cliente con identidad e indicaciones de revocación no reconocida o recuperación previa incompleta. No impone una estructura de base de datos única. El intercambio es más importante que el formato: cuanto menos pueda distinguir el servidor, más severa deberá ser su respuesta ante historias inciertas.

Volver a obtener un bloqueo no repara el intervalo

Después de un rechazo, una solicitud ordinaria puede obtener un bloqueo nuevo. Eso demuestra una concesión actual, no que nadie utilizara el objeto durante la interrupción de la protección anterior. La aplicación debe conservar esa diferencia.

El tratamiento de NFS4ERR_NO_GRACE depende, según el RFC, del entorno del cliente. Se comenta la posibilidad de examinar el atributo de cambio del objeto y valorar una apertura o bloqueo normales, siempre que lo permita la semántica de ese entorno. No se proporciona una garantía universal para continuar cualquier operación de negocio sin revisión.

La ficha oficial del documento identifica RFC 8881 como Proposed Standard de agosto de 2020, que sustituye RFC 5661. La lista de erratas consultada separa correcciones verificadas de propuestas aún comunicadas. En el listado obtenido no aparece una modificación directa de las tres secciones centrales utilizadas aquí. Esto no certifica que el documento carezca de otros problemas ni que todos los productos actuales lo implementen correctamente.

La Nota 32 de Lu Heng sobre el problema de agencia plantea la relación entre capacidad de decisión y exposición a sus consecuencias. Su Nota 36 sobre la realidad frente a la promoción de una causa propone describir estructuras sin convertirlas en una disputa moral. Son referencias editoriales; las reglas técnicas proceden del protocolo, y no constituyen una medición de los motivos de un proveedor.