Resumo

  • Num diretório marcado, o cliente que honra a extensão não pode atender uma nova enumeração com resultados READDIR de outra nem relatar para uma entrada valor anterior ao READDIR que a devolveu por último.
  • O requisito não apaga toda a memória local. Ele limita a resposta observável, por caminho e por entrada, e preserva o dado mais novo de um cliente que detenha delegação de escrita.
  • Para reduzir arquivos omitidos em backup ou sincronização, o operador aceita mais trabalho de metadados e precisa demonstrar comportamento por versão de cliente, pois a consulta do atributo não prova obediência.

O problema começa quando o nome continua certo

Quando um arquivo muda de nome, entra ou sai do diretório, o atributo change do diretório ajuda o cliente a invalidar a lista. Mas outro nó pode continuar escrevendo no mesmo arquivo sem alterar seu nome nem seu fileid. size, time_modify e outros atributos do arquivo avançam; a fotografia de nomes continua legítima.

READDIR pode trazer esses atributos junto com cada entrada. O cliente os guarda para evitar um GETATTR posterior por arquivo. Em diretórios relativamente quietos, a economia compensa a pequena janela de desatualização admitida pela RFC 8881. Em saídas de HPC ou áreas de ingestão com muitos produtores, qualquer tempo positivo pode ser suficiente para que o tamanho mostrado fique atrás do conteúdo.

Uma rotina incremental que escolhe o que copiar por tamanho e data pode ignorar silenciosamente um arquivo ampliado. O atributo fattr4_uncacheable_dirent_metadata dá ao servidor uma maneira por diretório de dizer que essa troca não é aceitável ali. Ele não transforma a ausência do atributo em garantia para todos os demais diretórios.

A revisão 11 descreve o efeito, não a gaveta

draft-ietf-nfsv4-uncacheable-directories-11 foi enviado em 5 de setembro de 2026. É um documento ativo do grupo NFSv4 no caminho de padronização. A seção de implementação relata protótipos Hammerspace e Linux, mas o texto segue sendo Internet-Draft: não é RFC, aprovação do IETF nem prova de uso em produção.

A revisão 10 mandava obter os metadados do servidor “em cada READDIR”. Como READDIR já é uma operação de protocolo no servidor, a frase não impedia com clareza um cliente de atualizar os nomes e depois servir um tamanho antigo vindo de seu cache comum de atributos do inode.

O novo texto formula duas proibições. Uma enumeração não pode ser satisfeita com resultado READDIR obtido em enumeração diferente. E, para uma entrada devolvida pelo READDIR mais recente, o cliente não pode relatar valor que tenha recebido antes desse READDIR, independentemente de qual operação alimentou o cache.

Isso desloca a conformidade para uma superfície verificável. Faça uma passagem, escreva no arquivo a partir de outro cliente, faça uma segunda passagem e consulte o atributo. A resposta proibida é a que antecede o READDIR da segunda enumeração. A implementação pode excluir, substituir ou manter a cópia velha internamente; o contrato só impede que ela seja atribuída à nova passagem.

Enumeração é a fronteira correta

O documento passou a definir os termos que carregam a regra. readdir, em minúsculas, é a leitura pedida pela aplicação. READDIR, em maiúsculas, é a operação NFSv4.2. Uma enumeration é uma passagem pelo diretório, normalmente composta por várias chamadas da aplicação e por READDIRs de continuação. Uma resposta de rede atende muitas chamadas readdir.

Logo, não existe uma exigência de uma viagem por nome. Existe a exigência de que cada passagem se apoie em READDIRs daquela passagem. O cliente deveria pedir em attr_request os atributos que pretende mostrar. Buscar cada um depois também pode obedecer à idade exigida, porém cria um GETATTR por entrada e perde a vantagem operacional.

Ao terminar a passagem, o cliente pode reter os valores. Entre enumerações, continuam valendo as regras comuns de duração do cache. Quando uma nova passagem devolve a entrada, um valor anterior ao READDIR atual deixa de servir como resposta. O mecanismo governa proveniência temporal, não a existência física de cache.

A política leva tempo para chegar ao cliente

Alterar o atributo no servidor não muda um cliente que ainda guarda os atributos antigos do diretório. Ele pode seguir o comportamento anterior até o limite desse cache expirar ou até uma revalidação notar que o change do diretório avançou. A revisão 11 reconhece essa janela em vez de declarar eficácia instantânea.

O registro operacional precisa guardar pelo menos três tempos: a alteração no servidor, a primeira observação em cada classe de cliente e a primeira enumeração cujo resultado visível segue a regra. Um painel que mostra apenas “TRUE desde 12:00” transforma configuração em execução presumida.

Delegações de diretório tornam a transição explícita. Elas permitem servir informações sem voltar ao servidor; a nova regra exige o retorno em cada passagem. Por isso, o servidor deve recolher uma delegação pendente ao ativar o atributo e não conceder outra enquanto ele estiver ativo. Notificação de atributo de filho é opcional, nem sempre implementada e pode crescer conforme clientes multiplicados por mudanças.

O cliente delegado pode ser a fonte mais nova

Um cliente com OPEN_DELEGATE_WRITE pode ter size ou change mais recente do que a cópia mantida pelo servidor. A RFC 8881 prevê CB_GETATTR justamente para o servidor consultar essa autoridade temporária. Substituir esse dado por um valor mais antigo do servidor seria regressão, não atualização.

A revisão 11 protege o caso: a proibição mira valores mais antigos do que o servidor devolveria e não obriga o detentor da delegação a abandonar conhecimento mais novo. A ordem das informações depende da autoridade de escrita, não apenas do sentido da chamada.

Mesmo a resposta atual do servidor é atual apenas no instante em que foi observada. Outra escrita pode chegar logo depois. O atributo reduz a reutilização indevida entre passagens; não cria uma fotografia atômica de dados e metadados distribuídos.

A marca pertence ao diretório percorrido

A regra vale para entradas obtidas por um diretório específico. Se o mesmo arquivo estiver ligado a um diretório marcado e a outro não marcado, o segundo caminho não herda o comportamento. Subdiretórios também não recebem a marca por regra do protocolo; eventual herança é política local que precisa ser inventariada.

O tratamento de tipo mudou. Como o suporte ao atributo é divulgado por sistema de arquivos, GETATTR num objeto que não seja diretório retorna FALSE. SETATTR no tipo errado retorna NFS4ERR_WRONG_TYPE. Reconhecer a extensão e poder aplicá-la a um objeto são fatos distintos.

Não existe recibo de que o cliente honrou

O atributo é consultivo. Ver um GETATTR ou SETATTR mostra que o cliente conhece o campo, não que impõe as duas proibições. O servidor não consegue separar, por essa pista, clientes que honram, clientes conscientes que ignoram e clientes sem implementação. Sua própria correção não pode depender de adesão universal.

Também há uma externalidade de capacidade. Cada nova enumeração marcada volta ao serviço; o caminho de READDIR só com nomes seguido de GETATTRs é mais caro. Se qualquer usuário puder ligar o atributo em uma árvore quente, uma gravação de metadado impõe trabalho a todos os clientes aderentes. Autorização, política de exportação e limite de carga precisam acompanhar a decisão.

As fontes demonstram o texto, a história da revisão, as RFCs de base, as razões públicas nos commits e protótipos declarados. Não demonstram versão Linux distribuída, comportamento comercial da Hammerspace, adoção, medição, incidente ou benefício observado. A proposta separada sobre dados de arquivo trata conteúdo e durabilidade, sem ampliar esta regra.

Pelas camadas de realidade de Heng Lu, o atributo é uma declaração do servidor; o cache é estado privado; READDIR é uma observação; stat é a afirmação entregue à aplicação. A força da revisão 11 está em tornar essas quatro coisas reconciliáveis sem fingir que são uma só.

Fontes