Resumo

  • O valor fattr4_uncacheable_file_data comunica o tratamento preferido pelo servidor, mas não revela o conteúdo nem o momento do cache de cada cliente.
  • Um arquivo já aberto pode continuar temporariamente sob o comportamento anterior; por isso, mudança no servidor e observação no cliente precisam de horários distintos.
  • Leituras exigem prova de revalidação e escritas exigem uma sequência de estabilidade, COMMIT e verificador antes do sucesso para a aplicação.

O servidor publica uma intenção

O cache é parte do contrato de desempenho de um sistema de arquivos em rede. O cliente conserva dados perto da aplicação e usa regras do protocolo para decidir quando pode reutilizá-los. Há arquivos, porém, em que previsibilidade de visibilidade ou do instante de persistência vale mais do que o ganho obtido com leitura local e write-behind.

O draft-ietf-nfsv4-uncacheable-files-13 cria um atributo booleano por arquivo para que o servidor expresse esse julgamento. É uma melhoria concreta: hoje falta uma maneira padronizada de dizer que certos dados não combinam com a política usual de cache. O problema começa quando um painel transforma a intenção publicada pelo servidor em uma afirmação sobre toda a frota de clientes.

Um valor verdadeiro não inspeciona páginas de memória. O cliente precisa implementar o atributo, verificar se o sistema de arquivos exportado o oferece, ler o valor corrente e convertê-lo em decisões de leitura e escrita. Essas etapas ocorrem em momentos diferentes. Se o arquivo já estava aberto quando o valor mudou, a proposta permite que o cliente mantenha o comportamento anterior até observar a novidade pelos caminhos normais e aplicá-la às operações seguintes.

Assim, o horário em que o administrador fez a alteração e o horário em que o cliente passou a agir não são versões concorrentes da mesma verdade. São dois fatos necessários. A diferença entre eles mede propagação, não erro de relógio.

O mapa de capacidades termina no sistema de arquivos

O atributo 87 é de leitura e escrita e aparece como RECOMMENDED na tabela de atributos NFS. Nesse contexto, a palavra indica uma categoria, não uma obrigação de implementação universal. O suporte é próprio do sistema de arquivos exportado. Dois volumes atendidos pelo mesmo servidor podem ter capacidades distintas.

A aplicabilidade também é estreita. O valor faz sentido para arquivos regulares e atributos nomeados. Uma consulta em outro tipo devolve falso; uma tentativa de definir o valor no tipo inadequado falha. Sem guardar o tipo do objeto e a lista de atributos suportados, o falso pode ser interpretado de maneira errada como uma escolha deliberada por cache comum.

Há ainda a decisão administrativa. O servidor pode permitir alterações, recusá-las segundo sua política ou atribuir o valor por uma regra local, como uma opção de montagem aplicada a novos arquivos. A autorização normal continua valendo. O histórico precisa mostrar a identidade do servidor e da exportação, a origem da regra, quem podia agir e se uma tentativa recusada preservou um valor anterior.

Esses campos parecem detalhes até que duas equipes comparem resultados de volumes diferentes. Sem eles, a ausência de suporte, a não aplicabilidade e uma decisão de política acabam misturadas na mesma célula.

Uma escrita só termina no ponto de durabilidade

Para um cliente que respeita a marca, o rascunho proíbe atrasar WRITE apenas para combinar chamadas e ganhar eficiência. A exigência que realmente define o resultado vem depois: quando a aplicação recebe sucesso, os dados precisam estar duráveis no servidor.

O cliente pode pedir uma escrita estável. Também pode fazer uma escrita instável e concluir COMMIT antes de devolver o controle à aplicação. Se o verificador de escrita do servidor mudar, as operações afetadas precisam ser reenviadas a partir dos dados que o cliente ainda mantém. Essa retenção transitória, indispensável a uma escrita em curso, não é tratada como o cache que o atributo pretende limitar.

Por isso, uma auditoria que busca “zero bytes retidos” pode punir a implementação correta e ainda deixar de verificar o que importa. O recibo deveria ordenar o modo de estabilidade pedido e recebido, o resultado de COMMIT, o verificador anterior e posterior, qualquer reenvio e o instante em que a aplicação viu sucesso. Diante de uma falha, essa cadeia responde se uma escrita específica recebeu a durabilidade esperada.

O booleano no servidor não contém nenhum desses eventos. Ele orienta o comportamento; não substitui a observação do comportamento.

A leitura precisa mostrar sua base de confiança

No caminho de leitura, a proposta não exige eliminar toda cópia local a cada chamada. Ela orienta o cliente a não reutilizar dados em cache sem revalidá-los. A verificação mínima cobre o atributo de mudança do NFS e o tamanho do arquivo. Outros atributos podem completar a decisão.

Essa lógica já faz parte do modelo de coerência do NFSv4.1, no qual a validade do cache se articula com OPEN, reservas de compartilhamento, bloqueios e delegações. Uma delegação pode fornecer ao cliente uma visão coerente e tornar apropriado conservar dados de leitura, mesmo quando o novo atributo está verdadeiro.

A pergunta certa não é “havia uma página em memória?”, e sim “qual garantia permitiu o uso dessa página nesta operação?”. Um recibo de leitura pode guardar os valores de mudança comparados, os tamanhos, o horário da revalidação, a delegação ou o bloqueio aplicável e a ação final: reutilizar, invalidar, buscar novamente ou falhar. Trata-se de evidência que outra pessoa consegue revisar, em vez de um rótulo de conformidade.

Duas trilhas de auditoria ligadas por uma operação

A trilha do servidor identifica servidor, sistema de arquivos exportado, suporte ao atributo 87, arquivo, valor, fonte da política, autoridade e horário de observação. Ela responde qual tratamento o servidor publicou para aquele arquivo naquele momento.

A trilha do cliente identifica implementação, versão, montagem, identificador do arquivo e época de abertura. Ela registra quando o valor foi visto e se a abertura já existia. Para leitura, acrescenta mudança, tamanho, delegação e ação de cache. Para escrita, acrescenta estabilidade, COMMIT, verificador, reenvio e retorno à aplicação.

As trilhas devem ser ligadas, não fundidas. Se o servidor muda o valor às 9h e um cliente com um arquivo aberto o percebe às 9h12, os doze minutos são parte do fato. Um campo único de “vigência” apaga a distância entre controle administrativo e execução distribuída.

Essa separação também melhora a responsabilidade. Uma política correta no servidor pode coexistir com um cliente antigo sem suporte. Uma versão compatível pode demorar a observar a mudança por causa de uma abertura ativa. E uma operação pode falhar apesar de ambos os lados estarem configurados. Cada situação exige uma resposta diferente.

A adoção voluntária deve aparecer no relatório

O mecanismo de RFC 8178 permite ampliar o NFSv4.2 sem tornar inválida a especificação de base em RFC 7862. A nova função é opcional, e o cliente conserva liberdade de implementação dentro das garantias propostas. Isso pede um relatório de distribuição, não uma declaração de universalidade.

Um inventário útil separa exportações sem suporte, exportações com suporte e valor falso, arquivos marcados ainda não observados, clientes que já aplicam a orientação a novas operações e operações com recibos verificados. Essa sequência mostra a fronteira real da adoção.

A seção de implementação do rascunho descreve um protótipo de servidor Hammerspace e um cliente Linux com comportamento semelhante a E/S direta para arquivos de um ponto de montagem configurado. Os benefícios relatados de desempenho, memória e CPU em cargas adequadas são evidência de viabilidade. Não são garantia de que todos os clientes usarão o mesmo desenho ou alcançarão o mesmo resultado. Semelhante não quer dizer idêntico.

O bit não cria segurança

O texto afirma que o atributo não acrescenta autorização nem controle de acesso e não deve orientar decisões de segurança. Uma alteração autorizada pode afetar o desempenho e a visibilidade percebida por outros clientes, portanto a identidade de quem a realizou merece registro. Ainda assim, o valor não é selo de integridade, mecanismo de confidencialidade ou prova de que dados antigos não existem em lugar algum.

É possível fazer afirmações menores e verificáveis. O servidor solicitou limitação de cache. Um cliente medido observou o valor. Uma leitura foi revalidada. Uma escrita ficou durável antes do sucesso. Cada frase precisa de sua própria evidência; a primeira não produz automaticamente as demais.

O ganho institucional da proposta está justamente nessa precisão. O protocolo passa a transportar uma preferência que antes dependia de arranjos locais. Ao manter ao lado dela o recibo do cliente, a operação consegue descobrir onde a preferência virou comportamento e onde permaneceu apenas como intenção.

Fontes