Resumo

  • RFC 9737 permite ao cliente usar um stateid anônimo todo zero durante o grace period para relatar erros de I/O ocorridos enquanto o MDS estava indisponível.
  • Um MDS sem a extensão devolve NFS4ERR_BAD_STATEID; o cliente deve recuar para o comportamento antigo, no qual esse erro não entra por esse caminho.
  • O fallback evita uma falsa aceitação, mas converte evidência conhecida pelo cliente em custo conservador de resilvering.

O cliente tinha um fato: a última WRITE não chegou a todos os mirrors. Também tinha os detalhes — device, operação, status e byte range. Quando o servidor de metadados voltou, o cliente enviou o relatório com o stateid anônimo definido por RFC 9737.

O MDS respondeu que aquele stateid era inválido.

Não era uma contradição. Era uma fronteira de versão. O cliente falava uma extensão que o servidor ainda não conhecia. A regra correta não é insistir até uma resposta parecer positiva. É voltar ao comportamento antigo e aceitar que o sistema perdeu um canal de evidência.

O protocolo novo separa relato de autoridade antiga

Em pNFS flexible file layout, o MDS distribui a topologia e o cliente acessa data servers diretamente. No espelhamento pelo cliente, ele deve atualizar todas as cópias e reportar falhas. RFC 8435 usa ff_ioerr4 para descrever o device, a operação, o status, o offset e o comprimento afetados.

Depois de um restart do MDS, os antigos layout stateids já não são válidos. Ainda assim, writes podem ter ocorrido durante a indisponibilidade do plano de metadados. RFC 9737 cria um canal estreito: durante grace, o MDS deve aceitar o all-zero stateid em LAYOUTRETURN para ouvir essas falhas.

O zero não devolve o layout antigo ao cliente. Não autoriza novo I/O. Não aumenta o seqid do estado retornado. Ele permite que uma observação histórica participe da decisão atual sem reativar a credencial expirada.

Interoperabilidade não é só decodificar a mensagem

O MDS novo conhece quatro limites. Dentro de grace aceita zero para esse relatório; rejeita outro stateid com NFS4ERR_GRACE; fora de grace rejeita zero com NFS4ERR_NO_GRACE; e ignora o relatório se o mirror set não corresponder ao atual.

O MDS antigo não conhece essa exceção. Para ele, zero continua sendo um stateid inadequado na operação e a resposta é NFS4ERR_BAD_STATEID. RFC 9737 orienta o cliente a voltar ao comportamento antigo de não relatar o erro dessa forma.

Esse fallback é honesto. O servidor não registra uma evidência que não compreendeu; o cliente não interpreta rejeição como aceite. Mas a organização precisa enxergar a perda. Um contador genérico de “recovery complete” esconderia que a observação permaneceu apenas no cliente e não influenciou a escolha do mirror.

O preço da incompatibilidade é reconstrução conservadora

Sem um relatório compatível, o MDS precisa proteger a consistência por outros sinais. Se o cliente não recupera o arquivo nem reporta erro antes do fim de grace, o servidor deve resilver. O cliente pode ter reiniciado e perdido estado. Ausência de mensagem não vira ausência de problema.

Mesmo com um cliente presente, o caminho antigo pode forçar decisões mais caras porque o MDS não consegue distinguir com precisão quais mirrors receberam as writes do período de outage. O sistema compra segurança com bandwidth, IOPS e tempo de recuperação.

Isso não torna o fallback defeituoso. Torna-o uma dívida mensurável. A taxa de BAD_STATEID, o volume reconstruído por falta de relatório, a duração adicional e o impacto de capacidade mostram onde o conjunto de compatibilidade ainda não incorpora RFC 9737.

Uma versão comum também precisa preservar o contexto

Quando ambos os lados implementam a extensão, ainda não basta aceitar o pacote. O relatório precisa chegar durante grace e estar ligado ao restart epoch correto. O layout devolvido precisa corresponder às mirror instances atuais. Um erro exato sobre uma topologia antiga deve ser ignorado, seguido de resilvering conservador.

O ff_ioerr4 também é um hint, não um atestado integral. Ele prova que o cliente informou uma observação com certos campos. Não prova sozinho que o mirror escolhido como fonte contém todos os bytes corretos, que nenhum outro cliente viu erro, que a cópia terminou ou que a aplicação aceitou o resultado.

A verificação operacional exige observar o comportamento efetivo do par: tentativa, resposta, fallback, comparação de topologia, decisão e resultado. A simples presença da função no release note não é recibo bilateral.

A ordem dos write intents limita a pressa

Um write intent existe quando o cliente obtém LAYOUTIOMODE4_RW. O MDS deve rastrear intents pendentes pelo restart. Se precisa resilver, deve cercar o arquivo, registrar a necessidade, liberar o intent e esperar até não restar nenhum antes de copiar.

O MDS pode bloquear I/O, encaminhá-lo por si ou inserir um proxy durante a reconstrução. São decisões locais, mas não podem violar a consistência do mirror set nem começar a cópia enquanto outra autoridade de escrita permanece ativa.

Depois vêm recibos adicionais: fonte legível, ranges copiados, mirrors convergentes, leitura posterior e validação da aplicação. Compatibilidade do relatório não é compatibilidade do resultado.

Migração precisa de canários assimétricos

Uma implantação segura deve testar pares novo–novo, novo–antigo e antigo–novo. No par compatível, o zero em grace deve ser aceito e não alterar seqid; fora da janela deve receber NO_GRACE. No par incompatível, BAD_STATEID deve produzir fallback visível e uma decisão conservadora, nunca um health verde.

Também é preciso mudar o mirror set entre o erro e o recovery. O relatório pode ser sintaticamente válido e temporalmente correto, mas não aplicável ao conjunto atual. Essa é a diferença entre interoperabilidade de mensagem e interoperabilidade de decisão.

RFC 9737 não elimina o custo da recuperação. Ele permite gastar menos quando existe evidência utilizável. Onde a versão comum não consegue ouvi-la, o sistema deve pagar em cópia — e registrar que pagou por incompatibilidade, não por prova de corrupção.

Fontes