Resumo

  • A revisão de 26 de setembro continua sendo um Internet-Draft ativo do grupo NFSv4, no estado I-D Exists.
  • Seu novo trecho sobre pNFS delimita o que um READDIR recém-executado pode mostrar quando uma escrita ainda não chegou ao servidor de metadados.

Uma aplicação de sincronização examina o tamanho e o horário de modificação dos arquivos para escolher o que copiar. Em um diretório compartilhado, outro cliente altera um arquivo sem criar ou renomear nenhuma entrada. O atributo de mudança do diretório não precisa refletir a escrita no conteúdo daquele arquivo. Assim, um cliente que reutiliza atributos guardados de uma enumeração anterior pode apresentar um tamanho antigo e induzir uma decisão errada. O projeto de atributo uncacheable_dirent_metadata permite que o servidor marque o diretório: um cliente que respeita o sinal realiza novo READDIR a cada enumeração e não relata atributos de uma entrada a partir de valores mantidos antes do READDIR que a retornou mais recentemente.

Esse mecanismo central não surgiu agora. A versão 11, de 5 de setembro, já o continha. A versão 12 torna explícito que a obrigação tem duas partes. Enviar um READDIR quase vazio e depois completar a apresentação com metadados antigos preservados localmente não resolve o problema. O cliente deve solicitar no próprio READDIR os atributos que pretende expor ou buscá-los depois. A segunda alternativa pode cobrar um GETATTR por entrada; a primeira aumenta o conteúdo pedido na enumeração. Nenhuma delas equivale a proibir cache de dados dos arquivos ou do próprio objeto de diretório.

O fato novo mais relevante está na seção 5.2. No NFS paralelo, o servidor de metadados fornece o diretório e o atributo, enquanto um dispositivo de armazenamento separado pode atender à escrita dos dados. Quando o layout faz o servidor de metadados descobrir o novo tamanho e time_modify apenas após LAYOUTCOMMIT, um READDIR anterior ao commit devolve os valores anteriores. O cliente que informa exatamente o resultado recebido cumpre a proposta, ainda que a aplicação veja um valor ultrapassado em relação à escrita. A causa do atraso não está mais no cache do cliente; está na circulação da informação entre os componentes.

O exemplo é condicionado ao layout. Não se deve atribuir a todos os sistemas pNFS a mesma ordem de atualização. Tampouco o texto promete visão instantânea de todas as escritas ou uma fotografia global consistente do diretório. Ele especifica o que um cliente cooperante não pode reutilizar de seu próprio passado. Chamar isso de “metadados sempre atualizados” amplia a promessa além do que o servidor pode demonstrar naquele instante.

Outra mudança desta versão trata de quem consegue acionar o controle. O atributo é um booleano por diretório, mas o servidor pode recusar SETATTR segundo sua política local. Uma recusa exige NFS4ERR_ACCESS ou, na situação indicada de propriedade e privilégio, NFS4ERR_PERM. Não pode retornar NFS4ERR_INVAL, que levaria um cliente sondando compatibilidade a concluir que o servidor desconhece o atributo. Recusa por autoridade e ausência de suporte pedem intervenções distintas; a falha do comando não deve esconder qual das duas ocorreu.

O Datatracker não registra uma especificação final. A seção de implementação fala em protótipos de servidor Hammerspace e cliente Linux, sem comprovar uso generalizado nem consistência observada em produção. Essa cautela é essencial antes de transformar uma regra proposta de cache em garantia de backup.

Fontes