Resumen

  • Durante el grace period posterior al reinicio del MDS, RFC 9737 obliga a aceptar un stateid anónimo de ceros para que el cliente reporte errores de E/S sufridos mientras el plano de metadatos estaba fuera.
  • Dentro de esa ventana, otro stateid recibe NFS4ERR_GRACE; fuera de ella, el valor cero recibe NFS4ERR_NO_GRACE.
  • La admisión temporal del informe no recupera el layout antiguo ni demuestra que la reconstrucción posterior haya producido datos correctos.

Un paquete llega con el identificador más vacío posible. Si llega a las 10:02, el servidor debe escucharlo. Si llega a las 10:12, debe rechazarlo. Los bits no han cambiado. Ha cambiado la época que les daba sentido.

Ese es el centro operativo de RFC 9737. El documento no presenta el stateid anónimo como credencial universal. Lo reserva para una emergencia muy concreta: el servidor de metadatos de un sistema pNFS ha reiniciado, los clientes pueden haber escrito directamente en los data servers durante la caída y el estado de layout que normalmente acompañaría un LAYOUTRETURN ya no es válido.

La autorización murió antes que la observación

En flexible file layout, el MDS entrega al cliente la descripción de los mirrors. El cliente ejecuta las operaciones directamente contra los servidores de datos y, en mirroring del lado cliente, debe actualizar todas las copias. Si una escritura falla, el cliente posee una observación que el MDS necesita para decidir qué mirror no debe servir como origen de la reparación.

RFC 8435 define ff_ioerr4 para transportar dispositivo, operación, código de estado, offset y longitud. Son indicios estructurados, no una auditoría completa del archivo. Pero sin ellos el MDS sólo sabe que pudo haber actividad durante su ausencia y debe asumir inconsistencia.

El reinicio invalida los layout stateids anteriores. La recuperación permite reclamar aperturas con CLAIM_PREVIOUS, pero el cliente no puede obtener un layout nuevo durante grace para explicar un fallo que ocurrió con el viejo. La información sobrevivió; su canal de autoridad no.

RFC 9737 introduce una autoridad más estrecha. El stateid cero no recupera el derecho anterior. Sólo hace admisible el testimonio en LAYOUTRETURN mientras dura la recuperación.

El reloj forma parte del dato

Durante grace, el MDS debe aceptar el all-zero stateid para este informe. Si el cliente usa un stateid distinto, recibe NFS4ERR_GRACE. Después de grace, el cero recibe NFS4ERR_NO_GRACE. Además, la respuesta a la forma anónima no debe incrementar el seqid del stateid de resultado.

Estas reglas preservan una separación esencial. El servidor procesa evidencia histórica sin fingir que ha revivido estado de layout vivo. El mensaje no entra en la secuencia ordinaria de posesión y devolución; entra en una contabilidad de recuperación.

Por eso un registro que sólo guarde stateid=0 es inútil. Debe conservar el identificador del reinicio, los límites exactos de grace, el cliente, el archivo, el write intent, la topología de mirrors, el contenido de ff_ioerr4, la respuesta y el efecto. La validez no está en un campo; está en la combinación verificable de todos ellos.

Tres ausencias que no significan lo mismo

La decisión de resilver depende de lo que ocurre antes de cerrar la ventana. Si el cliente reclama el archivo y no informa errores, el MDS no debe reconstruirlo. Si informa un error, debe reconstruirlo. Si no reclama ni informa, también debe reconstruir porque el cliente pudo haber reiniciado y perdido su memoria.

Una lista vacía tras un reclaim es evidencia negativa limitada. El cliente participó en la recuperación y no aportó un error. La falta total de participación es evidencia ausente. Un panel que muestre ambas como “0” elimina la diferencia que protege los datos.

Tampoco debe exagerarse la rama limpia. No reportar un fallo no prueba la corrección de todos los bytes. El cliente pudo no observar corrupción silenciosa; otro cliente pudo tener información distinta; la aplicación puede rechazar un contenido que el almacenamiento entregó sin error. La regla de no resilver es una decisión protocolaria bajo un conjunto de observaciones, no una certificación universal.

La topología puede caducar antes que el informe

Antes de utilizar el reporte, el MDS compara el layout devuelto con las instancias de mirror actuales. Si no coinciden, debe ignorarlo y resilver. Un cliente puede decir la verdad sobre el mirror que conocía y aun así no aportar evidencia aplicable a la configuración actual.

La operación necesita entonces dos huellas: topología observada por el cliente y topología vigente en el MDS. Sin esa comparación, una automatización puede excluir la copia equivocada o atribuir al informe una decisión que en realidad fue conservadora por desajuste.

La identidad del conjunto es parte de la prueba. “Error en el dispositivo B” no es suficiente si el conjunto actual ya no contiene el mismo B o ha cambiado la composición de dispositivos y mirrors.

Decidir reconstruir no es reconstruir

RFC 9737 ordena las responsabilidades. Un write intent nace cuando el cliente obtiene LAYOUTIOMODE4_RW. El MDS debe seguir esos intents a través del reinicio. Para resilver, debe cercar el archivo, registrar la necesidad, liberar el write intent y esperar a que no quede ninguno antes de copiar.

El servidor puede bloquear E/S, hacerla pasar por el MDS o introducir un proxy durante la copia. Esas decisiones son locales. Si mantiene acceso, el cliente debe conservar el mismo layout y el proxy debe permanecer hasta el final de grace.

La verificación continúa después: fuente legible, rangos copiados, mirrors convergentes, lecturas posteriores y aceptación por la aplicación. Un reporte válido decide el plan; no demuestra el resultado.

La incompatibilidad se paga con trabajo, no con ficción

Un MDS antiguo puede rechazar el stateid cero con NFS4ERR_BAD_STATEID. El cliente debe volver al comportamiento anterior y dejar de intentar el informe por esa vía. La evidencia conocida por el cliente se vuelve operacionalmente inaudible.

El sistema responde con prudencia: reconstruye cuando carece de un testimonio compatible. El coste aparece en tráfico, IOPS y tiempo. Es preferible a fingir que el error fue recibido, pero debe contabilizarse como fallback, no como éxito de RFC 9737.

La verificación operativa exige comprobar qué versiones intercambiaron qué significado. La norma define el mínimo. El código ejecutado demuestra si la ventana se abrió, si el reporte fue admitido y si la reconstrucción siguió el orden correcto.

El stateid de ceros no es poderoso porque autorice mucho. Es poderoso porque limita con precisión lo único que autoriza: que una observación perdida entre dos planos pueda ser escuchada antes de que termine la recuperación.

Fuentes