Resumo

  • A declaração de recuperação concluída fecha a possibilidade de reivindicar depois os bloqueios antigos ainda não recuperados naquele escopo. Ela não fala em nome dos outros clientes.
  • Um cliente que concluiu sua recuperação ainda pode receber uma resposta de período de carência ao pedir um bloqueio novo.
  • Partições de rede e reinicializações sucessivas podem tornar uma reivindicação antiga aparentemente aceitável, embora sua proteção tenha sido interrompida. O histórico persistente decide até onde o servidor pode aceitar recuperações com segurança.

A pergunta que depende de quem responde

Dois clientes mantinham bloqueios em um servidor de arquivos. O servidor reinicia e perde o estado desses bloqueios. Um cliente consegue voltar imediatamente, reconstituir suas aberturas e recuperar os bloqueios de intervalos de bytes. O outro continua sem comunicação. A recuperação terminou?

Para o primeiro cliente, talvez sim. Para o servidor, falta saber se o segundo ainda pode apresentar uma reivindicação antiga que entraria em conflito com uma concessão nova. O avanço de um participante não elimina a obrigação de considerar o outro.

É uma situação ilustrativa, não um incidente atribuído a um operador. O RFC 8881, nas seções 8.4, 9.11 e 18.51, trata essa diferença como parte do funcionamento do NFSv4.1. Concluir a recuperação e receber NFS4ERR_GRACE ao pedir um novo bloqueio são resultados que podem coexistir. A declaração anterior não precisava ter falhado para a espera continuar.

O período reservado às reivindicações antigas

Depois de perder o estado de bloqueio, o servidor deve oferecer aos clientes uma oportunidade de restabelecer o que possuíam antes. Durante essa oportunidade, concessões novas não podem simplesmente passar à frente de recuperações com as quais entrariam em conflito.

Há operações específicas para recuperar estado. Uma abertura existente é recuperada com OPEN e CLAIM_PREVIOUS, usando o identificador opaco de arquivo atual do alvo. Não é a abertura de um novo nome a partir de um diretório. O bloqueio de intervalo de bytes usa LOCK com o parâmetro reclaim verdadeiro.

Dizer que uma solicitação é antiga não a torna superior às regras de acesso. O servidor continua obrigado a considerar permissões e conflitos. A recuperação não fornece ao cliente uma autorização que ele não teria em operação normal.

Também não se trata de congelar todas as atividades do servidor. A criação da identidade do cliente e da sessão é necessária para a própria retomada. Novos bloqueios ou operações de leitura e escrita podem ser admitidos quando há informação suficiente para excluir incompatibilidade com uma recuperação posterior. Quando essa segurança não pode ser estabelecida, a ausência de um bloqueio na tabela atual não resolve o problema: pode faltar justamente o cliente que ainda não conseguiu declará-lo.

O que se abandona ao declarar o fim

Na forma global de RECLAIM_COMPLETE, o campo rca_one_fs é falso. Após obter uma nova identidade de cliente, essa declaração deve preceder a primeira solicitação de bloqueio novo. A exigência também vale quando não há bloqueios antigos a recuperar. Uma lista vazia precisa ser encerrada perante o servidor, não apenas presumida pelo cliente.

O encerramento tem consequências. Dentro do escopo declarado, os bloqueios antigos ainda não recuperados deixam de poder ser reivindicados como tal. O cliente não pode guardá-los para uma oportunidade posterior na mesma recuperação, em outra instância do servidor ou após a transferência pertinente para outro servidor.

Por isso, a declaração serve como uma fronteira real. Ela permite ao servidor deixar de considerar novas reivindicações antigas daquele participante. É mais do que uma atualização de porcentagem: o cliente abre mão do restante do conjunto.

Essa certeza não inclui os demais. Um cliente que voltou rápido pode encerrar suas pendências, mas não pode renunciar às pendências de quem está ausente. Confundir essas duas coisas transformaria uma obrigação local em poder sobre a recuperação alheia.

A operação tem ainda uma forma por sistema de arquivos associada à migração, que exige um identificador de arquivo atual. Ela não substitui a forma global ligada à nova identidade do cliente. Em um sistema de arquivos fora da condição de migração correspondente, a especificação prevê uma resposta de sucesso sem outro efeito da operação. Este artigo se limita à recuperação após reinicialização; a migração aparece apenas para delimitar o alcance das declarações.

A lista de quem ainda pode voltar

Para concluir que todos os clientes relevantes terminaram, o servidor precisa saber quem poderia ter mantido bloqueios. Um registro estável desse conjunto torna úteis as declarações recebidas. Contar apenas quem já se reconectou não demonstra que ninguém está faltando.

Com informação suficiente, é possível encerrar a carência antes de uma espera indiscriminada. A carência também pode terminar sem que todos tenham concluído, mas isso não torna seu prazo arbitrário. A seção 8.4.2.1 vincula a oportunidade de recuperação ao período da concessão temporária, ou lease: recomenda não encerrar antes desse intervalo e, ao tratar de uma mudança no valor, exige uma carência pelo menos tão longa quanto o lease da instância anterior.

Essas condições não equivalem a uma duração universal em segundos. Elas preservam o contexto no qual os clientes operavam antes da falha. Um servidor recém-iniciado não ganha, só por isso, o direito de reescrever retroativamente a oportunidade de retorno.

Na operação cotidiana, isso produz dois marcos: a conclusão do cliente e a condição de admissão do servidor. Um painel que registra somente o primeiro pode classificar a proteção dos ausentes como atraso inexplicável. Um painel que registra somente o segundo pode esconder clientes que nunca cumpriram sua própria etapa.

Quando o passado não cabe na tabela atual

O problema mais delicado aparece quando o cliente acredita que sua proteção continuou, mas ela terminou enquanto a rede estava dividida.

O RFC apresenta uma sequência em que um cliente não consegue renovar seu lease. O prazo expira e o servidor libera o bloqueio. Outro cliente obtém um bloqueio que teria sido incompatível com o primeiro, realiza trabalho e o libera. Depois disso, o servidor reinicia. A partição termina e o cliente original retorna durante a nova carência para recuperar seu bloqueio antigo.

Naquele momento, a tabela pode estar livre de conflito. Mesmo assim, aceitar a recuperação pode ser um erro. Se o outro cliente modificou o objeto, a continuidade pressuposta pelo primeiro já foi rompida. Ausência de conflito agora não é prova de proteção contínua antes.

Uma segunda situação descrita atravessa duas reinicializações. O cliente não recupera todos os bloqueios durante a primeira carência; outro participante consegue uma concessão conflitante depois; ocorre nova reinicialização; o cliente inicial finalmente retorna. A nova janela não deve apagar o significado da oportunidade anterior que foi perdida.

A especificação, por isso, exige uma de duas estratégias: recusar todas as recuperações com NFS4ERR_NO_GRACE, ou manter em armazenamento estável informação suficiente para detectar as condições perigosas conhecidas envolvendo reinicializações. É aceitável recusar por cautela uma recuperação que, com conhecimento mais completo, poderia ser autorizada. Se o histórico estiver irrecuperavelmente danificado, as reivindicações possivelmente afetadas devem ser negadas.

O documento sugere um exemplo mínimo de registro por cliente, com identidade e indicações de revogação não reconhecida ou recuperação anterior incompleta. Não exige um único esquema de banco de dados. A escolha está entre a precisão das informações mantidas e o grau de severidade que a recuperação terá de impor quando o servidor não puder distinguir histórias.

Voltar a bloquear não resolve o trabalho interrompido

Depois de uma recusa, obter um bloqueio novo por uma solicitação normal não demonstra que ninguém interveio durante a perda de proteção. O bloqueio atual protege uma condição atual. Não cobre retroativamente o intervalo anterior.

O RFC não determina uma resposta universal do cliente a NFS4ERR_NO_GRACE. A estratégia depende do ambiente de execução. Examinar o atributo de mudança de um objeto e avaliar novas aberturas ou bloqueios é uma possibilidade discutida sob condições adequadas, não uma licença para toda aplicação continuar automaticamente.

A ficha oficial identifica o RFC 8881 como Proposed Standard de agosto de 2020, substituindo o RFC 5661. A lista de erratas foi consultada, distinguindo correções verificadas de propostas apenas relatadas. A listagem obtida não altera diretamente as três seções centrais usadas aqui. Isso não certifica a ausência de outros problemas nem a conformidade de produtos atuais.

A Nota 32 de Lu Heng sobre o problema de agência oferece uma pergunta editorial: quem decide e quem arca com a consequência? A Nota 36 sobre realidade, e não defesa de uma causa orienta a descrever a estrutura sem inventar vilões. As regras técnicas vêm do protocolo; a análise de incentivos não é uma medição da intenção de nenhum fornecedor.