Resumo

  • LAYOUT_WCC leva ao servidor de metadados atributos pós-operação que o cliente já recebeu ao falar NFSv3 com um servidor de dados.
  • O servidor pode usar o informe para dispensar GETATTR, ignorá-lo ou consultar diretamente; o resultado não acusa quais atributos foram adotados.
  • Atributos corretos não são recibos de persistência dos bytes, convergência dos espelhos, autorização ou consumo pela aplicação.

Um cliente termina uma escrita e recebe do servidor de dados o novo estado aparente do arquivo. Pouco depois, o servidor de metadados precisa responder qual é o tamanho desse mesmo arquivo. Sem um caminho para reaproveitar a observação, a resposta mais segura é perguntar de novo ao servidor de dados. O RFC 9766 cria esse caminho de reaproveitamento.

O protocolo, porém, não decreta que uma observação transportada seja verdade definitiva. Ele preserva o direito do servidor de metadados de avaliar idade, conflito e consequência antes de decidir. Isso transforma o cliente em testemunha eficiente sem torná-lo dono do estado público.

A escala separou dados de metadados

O pNFS permite que o servidor de metadados cuide do namespace, conceda e revogue layouts, enquanto o cliente move dados diretamente para servidores próprios. No flexible file layout, esses servidores podem usar NFSv3. O desvio reduz a presença do servidor de metadados no fluxo pesado de leitura e escrita.

Essa mesma separação cria um atraso possível de conhecimento. Com um layout válido, o cliente pode alterar o arquivo de dados sem que o servidor de metadados participe da operação. O NFSv3 não define uma notificação geral pela qual o servidor de dados anuncie depois toda mudança. Assim, o componente que responde por atributos pode estar atrás do componente em que os bytes acabaram de mudar.

Consultar diretamente resolve a dúvida. Um GETATTR pode obter tamanho, espaço usado, tempos e outros atributos atuais. Mas cada confirmação cria uma operação adicional, e o volume agregado de consultas de metadados pode impor trabalho substancial ao nível de dados. Além disso, no NFSv3 uma escrita e uma leitura de atributos são duas viagens, ao contrário de certas composições do NFSv4.

A operação 77 do NFSv4.2, chamada LAYOUT_WCC, oferece outra fonte. Respostas NFSv3 a READ, WRITE e COMMIT podem incluir dados de Weak Cache Consistency. O cliente mapeia o que recebeu para atributos NFSv4.2 e envia ao servidor de metadados.

A fraqueza é uma informação de qualidade

No RFC 1813, WCC combina alguns atributos anteriores à operação com atributos posteriores. Ao comparar os dois lados, o cliente pode perceber que outra mudança talvez tenha ocorrido e decidir invalidar sua cache. A janela dá mais contexto do que um único retrato posterior.

Ela não produz coerência estrita. O caso mais forte depende de tratar atomicamente o estado anterior, a modificação e o estado posterior. Uma intervenção concorrente dentro dessa janela pode apagar parte da narrativa. E nenhuma fotografia final impede uma escrita seguinte.

Por isso, “weak” não é um aviso cosmético. É a classificação da evidência. O RFC 9766 deixa o servidor de metadados usar o informe quando ele basta e fazer GETATTR quando a política exige maior certeza. Idade máxima, conflitos e importância do atributo permanecem decisões do operador local.

Há discricionariedade simétrica. O cliente pode não usar os dados WCC que recebeu. O servidor pode ignorar atributos presentes em LAYOUT_WCC. Como o cliente não tem como remediar uma rejeição, a resposta não carrega bitmap de aceitação. Sucesso significa que a operação terminou sem aquele erro; não prova que cada campo foi incorporado ao estado autoritativo.

Os oito atributos não são oito conclusões

No flexible file layout, o mapeamento cobre size, space_used, mode, owner, owner_group, time_access, time_modify e time_metadata. Os uid e gid do NFSv3 são convertidos para os valores textuais de proprietário e grupo usados no NFSv4.

O conjunto atravessa capacidade, tempo e controle de acesso. Um novo tamanho é compatível com a escrita observada, mas não explica sozinho a causa. Um tempo de acesso recente pode apontar uma leitura, sem identificar seu consumidor. Uma divergência de modo ou dono ajuda a investigar uma negação de acesso, sem dizer qual sistema guarda o valor certo.

O RFC menciona ocasiões úteis para o informe: antes de pedir tamanho, espaço, atributo de mudança ou tempos ao servidor de metadados; ao reportar NFS4ERR_ACCESS, junto dos uid/gid vistos; e ao atualizar tempos de acesso e modificação sob uma delegação adequada.

Cada ocasião oferece contexto para uma escolha. Nenhuma autoriza uma correção automática. Diante de um proprietário divergente, pode estar errado o servidor de dados, a expectativa em cache ou o layout que orientou o cliente. Um SETATTR disparado apenas pela discrepância daria poder de alteração a um recibo de diagnóstico.

Espelhos exigem nomes, não posições

O filehandle corrente e lowa_stateid ligam a operação ao layout; lowa_type define a forma de interpretar o conteúdo opaco. O conteúdo do flexible file layout pode incluir espelhos e os servidores de dados de cada um.

As listas não criam identidade por ordem. Com três espelhos, o cliente pode enviar todos e usar máscara vazia para o que permaneceu igual. Também pode enviar somente os dois alterados. Nesse segundo formato, a posição muda. O servidor de metadados precisa identificar um arquivo de dados pela combinação device ID, stateid e filehandle. Os três são indispensáveis porque um mesmo dispositivo pode hospedar vários arquivos do layout.

A regra vale além do NFS: “item dois” é uma referência frágil quando o produtor pode omitir itens. Evidência que sobreviva a reordenação precisa nomear explicitamente o objeto observado.

Erros tornam essa precisão ainda mais importante. Diante de um erro permitido, o servidor de metadados pode desprezar a operação inteira ou, quando o conteúdo específico autoriza, aplicar apenas uma parte. Um log binário de RPC não conta qual arquivo nem quais campos influenciaram a decisão. Para auditoria, é necessário preservar identidade, máscara, valores e resultado de aplicação.

Quatro camadas, quatro recibos

O primeiro recibo é o informe dos atributos. O segundo é o de armazenamento estável. No flexible file layout, uma escrita que não retorna FILE_SYNC precisa ser estabilizada com COMMIT antes de LAYOUTCOMMIT. LAYOUT_WCC não atesta nem substitui essa sequência.

O terceiro recibo diz respeito aos espelhos. No espelhamento realizado pelo cliente, o RFC 8435 o responsabiliza por atualizar cada cópia e só trata a transação de escrita como bem-sucedida quando todas foram atualizadas. O estado de um arquivo de dados não prova o de uma cópia que não foi observada. Um erro pode informar ao servidor de metadados que há reparo a organizar; não prova que o reparo terminou.

O quarto recibo pertence à aplicação. O servidor pode conhecer o tamanho correto e a aplicação ainda ler bytes antigos em outra cache. As cópias podem concordar, mas sobre o arquivo errado para aquela operação de negócio. Atributo, durabilidade, replicação e resultado do usuário são realidades relacionadas, não intercambiáveis.

Ser opcional mantém o sistema evolutivo

O RFC torna LAYOUT_WCC opcional tanto no NFSv4.2 como no flexible file layout. Isso conserva interoperabilidade com clientes e servidores que ainda não implementam a operação 77. O caminho antigo, inclusive a consulta direta, continua possível. O endpoint pode trabalhar mais, mas sua ausência não prova incorreção.

O RFC 8178 disciplina extensões do NFSv4, e os RFCs 7862 e 7863 definem o protocolo e o XDR do NFSv4.2. Eles demonstram a existência e a sintaxe do mecanismo. A negociação e o uso em um ambiente específico só podem ser demonstrados por endpoints em execução.

A segurança vem do flexible file layout. O acoplamento frouxo pode usar uid/gid sintéticos para conter clientes cooperativos, porém não necessariamente um cliente malicioso ou apenas um cliente específico. O acoplamento forte depende de seu protocolo de controle. A comunicação de backend deve resistir a observação e alteração. Autenticar a origem atribui o informe; não garante que o valor ainda seja o mais recente no servidor de dados.

Fontes

  1. RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout
  2. RFC 8435: Parallel NFS Flexible File Layout
  3. RFC 8434: Requirements for pNFS Layout Types
  4. RFC 1813: NFS Version 3 Protocol
  5. RFC 8881: NFS Version 4 Minor Version 1 Protocol
  6. RFC 7862: NFS Version 4 Minor Version 2 Protocol
  7. RFC 7863: NFSv4.2 XDR Description
  8. RFC 8178: Rules for NFSv4 Extensions and Minor Versions
  9. RFC 9754: Extensions for Opening and Delegating Files in NFSv4.2
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile