Resumen

  • NFSv2 hacía que una operación modificadora regresara después de llegar al almacenamiento estable; ese modelo facilitaba la recuperación sin estado, pero obligaba a esperar en cada escritura.
  • NFSv3 introdujo UNSTABLE, DATA_SYNC y FILE_SYNC. La respuesta comunicaba cuántos bytes se escribieron, qué nivel se alcanzó y un verificador opaco de la instancia del servidor.
  • El cliente conservaba los datos hasta un COMMIT o una respuesta suficientemente fuerte. Si cambiaba el verificador, debía asumir que los datos inestables podían haberse perdido y volver a enviarlos.

Un OK que todavía ocupaba memoria

Un bloque cruza la red y llega la respuesta NFS3_OK. La tentación es leerla como una sola frase: «el archivo ya está seguro». Pero la misma respuesta puede contener committed = UNSTABLE. El procedimiento terminó correctamente; la obligación de durabilidad, no.

El contraste se entiende desde RFC 1094. En NFS versión 2, una modificación se consideraba sincrónica. Cuando WRITE volvía, el cliente podía asumir que los cambios estaban en almacenamiento estable y descartar su copia. La regla hacía tolerable un servidor sin estado: si fallaba, el cliente repetía operaciones y no reconstruía una sesión compleja. También convertía la velocidad del soporte persistente en latencia visible para cada escritura.

RFC 1813 presentó las escrituras inseguras como respuesta a ese cuello de botella. La formulación histórica puede engañar: «unsafe write» describe el momento anterior a la persistencia, mientras que el mecanismo completo pretende que la asincronía sea recuperable. No elimina el riesgo; conserva el material necesario para cerrarlo.

La petición y el resultado no eran la misma cosa

NFSv3 permitió que el cliente pidiera tres niveles. FILE_SYNC cubría datos y todos los metadatos del archivo antes de responder. DATA_SYNC cubría los datos y los metadatos suficientes para recuperarlos. UNSTABLE permitía que el servidor confirmara antes de fijar todo, parte o nada en almacenamiento estable.

La respuesta tenía su propio campo committed. Ese detalle evita que una preferencia se convierta en una observación. Un servidor puede hacer más de lo pedido y contestar FILE_SYNC, por ejemplo si dispone de memoria no volátil rápida. No puede hacer menos que la exigencia recibida. Para decidir si el cliente puede olvidar, importa el nivel devuelto.

También importa count. El servidor puede escribir menos bytes de los solicitados y responder con la cantidad efectiva. El resto exige otro WRITE. Por eso una operación exitosa no autoriza dos atajos: no prueba que se aceptó toda la longitud solicitada ni que la parte aceptada ya sea durable.

Esta separación convirtió un booleano seductor en una secuencia verificable. Primero se identifica el rango. Después se conoce su grado de compromiso. Por último se resuelve la deuda pendiente. Cada dato responde a una pregunta diferente.

El verificador señalaba una época, no un contenido

WRITE devolvía además verf, un cookie opaco. Debía ser estable dentro de una instancia del servicio y distinto entre instancias donde pudiera perderse información no comprometida. Un reinicio era el ejemplo normal; cualquier evento que destruyera esa custodia temporal podía exigir el cambio.

No era un hash. No decía qué había dentro del archivo. Tampoco identificaba una versión de objeto, a un usuario o a una transacción de aplicación. Muchas escrituras distintas podían compartirlo mientras pertenecieran a la misma época del servidor. Su autoridad era temporal: permitía comparar la etapa que aceptó datos inestables con la etapa que más tarde intentaba comprometerlos.

El cliente debía conservar los buffers. RFC 1813 describe tres estados: sucio; terminado pero pendiente de commit; terminado. La segunda categoría es el coste intelectual de NFSv3. Una operación puede estar completa desde el punto de vista de envío y seguir abierta desde el punto de vista de supervivencia.

COMMIT y la prueba que podía romperse

COMMIT obliga a vaciar a almacenamiento estable los datos modificados que antes se devolvieron como inestables. Puede cubrir un intervalo; offset cero y count cero significan desde el inicio hasta el final. Se parece a un fsync remoto con rangos, aunque la semejanza no transforma el protocolo en una garantía sobre toda la aplicación.

El servidor responde con otro verificador. Si coincide, el cliente puede vincular el acto de persistencia con la misma instancia que custodiaba los buffers. Si difiere, la continuidad se ha roto. Los datos asociados al verificador anterior y a un resultado inestable deben tratarse como posiblemente perdidos y retransmitirse.

Ese mandato es deliberadamente conservador. Una caída puede haber dejado parte de los bytes en disco; el cliente no dispone de una prueba fina para distinguirlos. Reescribir en los offsets conocidos recupera el estado sin fingir conocimiento. El cambio de cookie no certifica pérdida total; retira la base para confiar en la memoria anterior.

Tampoco la igualdad certifica el archivo. Todavía hacen falta el estado de COMMIT, los recuentos, los rangos y cualquier coordinación frente a otros escritores. La instancia es una dimensión de la verdad, no todas.

Durabilidad no significaba inmortalidad

RFC 1813 describe el almacenamiento estable como capaz de sobrevivir fallos repetidos de alimentación, ciertos fallos de hardware y ciclos repetidos de caída y reinicio de software. Inmediatamente limita la promesa: no cubre el fallo del propio módulo estable. No es una afirmación sobre copias de seguridad, réplicas, integridad lógica o recuperación de desastre.

El documento también niega una consistencia estricta entre cachés. Un rango persistido puede coexistir con una vista obsoleta en otro cliente o con una decisión de aplicación equivocada. COMMIT responde a la permanencia de datos y metadatos bajo el contrato NFS; no decide cuál versión debía ganar.

La idea sobrevivió a la generación que la creó. RFC 3530 llevó el verificador a NFSv4. RFC 7530 conservó la diferencia entre estabilidad solicitada y obtenida. RFC 8881 exige explícitamente que, si cambia el verificador, el cliente suponga perdidos los datos antiguos devueltos como UNSTABLE4 y los recupere. Un protocolo más estatal no volvió inútil esta prueba de encarnación.

La velocidad tenía dueño

NFSv3 ganó tiempo al sacar parte de la persistencia del camino crítico. Pero el trabajo no desapareció. El servidor obtuvo margen para agrupar vaciados; el cliente pagó con memoria retenida, mapas de rangos y capacidad de repetición. Después de un cambio de verificador, una gran cola de datos inestables podía regresar como tráfico de recuperación.

Ese reparto explica por qué «asíncrono» no equivale a «gratis». La latencia normal disminuye a cambio de una obligación contingente. Si el sistema dimensiona discos y red para el caso ordinario pero no la memoria y el ancho de banda de recuperación, ha financiado su rendimiento con una deuda que se hace visible en el peor momento.