Resumo

  • O rascunho NFSv4.2 aprovado pelo IESG cria um booleano por arquivo que orienta clientes compatíveis a limitar o cache persistente de dados; o atributo é consultivo e não é obrigatório para todo servidor.
  • Um valor true não prova que um OPEN antigo mudou de modo, que um WRITE instável chegou ao COMMIT, que metadados pNFS ficaram visíveis ou que outra aplicação observou os bytes.

O servidor poderá finalmente dizer pelo protocolo: este arquivo não combina com o cache normal de dados no cliente. Para cargas de HPC e arquivos com escritores concorrentes, isso oferece uma alternativa comum a exigir que cada aplicação conheça uma interface local semelhante a O_DIRECT.

Mas escrever a intenção não esvazia o cache.

Em 17 de setembro, o IESG aprovou Adding an Uncacheable File Data Attribute to NFSv4.2 e enviou o documento à fila do RFC Editor. A revisão 16 define fattr4_uncacheable_file_data, atributo 87, como booleano de leitura e escrita para arquivos regulares e atributos nomeados. Ele pertence à categoria NFS RECOMMENDED; esse nome não obriga todos os servidores a implementá-lo.

O suporte é próprio de cada sistema de arquivos exportado. Duas exportações do mesmo servidor podem divergir. O cliente consulta supported_attrs ou faz uma tentativa. Um SETATTR sem suporte falha com NFS4ERR_ATTRNOTSUPP; um GETATTR simplesmente omite o campo. Ausência precisa de contexto antes de virar incidente.

Quando honra o valor verdadeiro, o cliente não pode atrasar o envio de WRITE só para reunir operações ou ganhar eficiência. A regra reduz um risco específico: dois clientes podem alterar intervalos distintos do mesmo bloco e um deles regravar uma cópia antiga por cima da atualização do outro. Transmitir cedo estreita a janela desse write hole.

Durabilidade percorre outra cadeia. O atributo não escolhe stable_how4. O rascunho exige que, quando a chamada de escrita da aplicação retorna com sucesso, os dados já sejam duráveis no servidor. FILE_SYNC4 ou DATA_SYNC4 podem cumprir isso na resposta. Com UNSTABLE4, o COMMIT precisa terminar antes do retorno; se o write verifier mudou, os WRITEs afetados devem ser repetidos enquanto o buffer da aplicação ainda existe.

Reter bytes temporariamente para concluir esse intercâmbio não é o cache persistente que a marca limita. No sentido inverso, o booleano não compensa um COMMIT ausente. “Não cacheável” descreve a política da cópia local; não é recibo de persistência.

A leitura impõe condições próprias. Um cliente que conserva dados lidos não deveria reutilizá-los antes de revalidar o atributo de mudança e o tamanho. Uma delegation pode fornecer outra visão consistente. No pNFS, o atributo vem do servidor de metadados, mas os dados podem ir diretamente a dispositivos de armazenamento. Tornar os bytes duráveis e tornar o layout visível são eventos diferentes. Quando LAYOUTCOMMIT é necessário, adiá-lo permite que outro cliente ainda valide metadados anteriores.

O tempo também impede uma narrativa de um único bit. Se a marca muda depois que o arquivo foi aberto, o cliente pode preservar a escolha feita no OPEN enquanto aquela abertura durar. Expiração de atributos, revalidação e um novo OPEN limitam o atraso. O true de hoje não descreve automaticamente as aberturas de ontem.

O atributo tampouco recebe autoridade de segurança. A política existente do servidor decide quem pode ativá-lo ou limpá-lo. O rascunho não cria autenticação, não altera controle de acesso e não oferece fronteira de segurança. Consistência de cache e integridade continuam sendo mecanismos separados.

A revisão 16 cita um servidor Hammerspace e um cliente Linux prototípicos, com benefícios observados em E/S bem formada. Isso mostra código em funcionamento, não implantação ampla, ativação padrão, interoperabilidade entre produtos ou ganho universal. É preciso observar se o cliente realmente honra a marca e o que muda no trabalho real.

O registro útil, portanto, liga revisão da especificação, suporte da exportação, política do servidor, valor visto por um cliente identificado, momento do OPEN, implementação e versão, estabilidade do WRITE, verifier e COMMIT, eventual LAYOUTCOMMIT, revalidação de leitura e resultado da aplicação. O booleano abre o processo probatório; não o encerra.

Fontes