Resumo

  • O caminho ajuda o cliente a localizar um arquivo; o file handle opaco é a referência que o servidor aceita nas operações seguintes. Seus bytes não revelam ao cliente um inode, endereço físico ou identidade universal.
  • O NFSv4 classificou referências como persistentes ou voláteis. As persistentes atravessam reinicialização e migração durante a vida do objeto; as voláteis podem expirar segundo condições anunciadas pelo servidor.
  • NFS4ERR_STALE informa que o objeto foi removido ou ficou indisponível. NFS4ERR_FHEXPIRED pode indicar apenas que uma referência temporária perdeu continuidade, embora o objeto ainda exista. Recuperar é resolver os nomes novamente e validar o resultado.

Uma migração sem mapa interno

Considere um servidor que transfere um objeto para outro sistema de armazenamento. O cliente não deveria precisar saber em qual volume, inode ou tabela interna o arquivo passou a morar. Sua referência precisa de uma semântica visível na rede, não de uma cópia da engenharia do servidor.

Essa divisão começou cedo. O RFC 1094, de 1989, descreveu o NFSv2 com um identificador opaco de 32 bytes. O cliente obtinha um ponto inicial pelo protocolo MOUNT, enviava a LOOKUP o identificador de um diretório e um componente de nome, e recebia o identificador seguinte. GETATTR, READ e WRITE trabalhavam com o resultado, sem percorrer de novo o caminho inteiro.

Opaco não queria dizer criptografado. Queria dizer que o formato interno não fazia parte do contrato do cliente. O servidor podia combinar dados de seu sistema de arquivos, mas um cliente interoperável não podia extrair um número de dispositivo, um inode ou um endereço e passar a depender dessa interpretação.

O RFC 1813 tornou variável o comprimento de nfs_fh3 no NFSv3. O valor continha o que o servidor precisava para distinguir o arquivo e podia ser retornado por LOOKUP, CREATE, LINK e READDIRPLUS. Assim, novas implementações ganhavam espaço para representar objetos sem publicar a representação como uma API permanente.

Igualdade serve ao cache, não governa a verdade

Há uma conclusão válida ao comparar duas referências do mesmo servidor: se os bytes são iguais, o arquivo é o mesmo. A conclusão inversa não é válida. Bytes diferentes não provam arquivos diferentes, pois a relação entre objeto e referência não precisa ser um para um.

O RFC 1813 diz que a comparação é uma otimização de desempenho, não uma base de correção. A regra continua no NFSv4. Dois nomes ligados ao mesmo arquivo devem produzir o mesmo identificador, mas o cliente não pode inventar uma taxonomia própria a partir de cada desigualdade. Muito menos pode comparar valores de servidores distintos como identificadores globais.

O limite é útil porque mantém a autoridade onde existe a informação. O cache pode economizar trabalho quando reconhece igualdade. O servidor continua sendo quem sabe como as referências alcançam seus objetos.

Persistir é manter uma promessa específica

O RFC 3010 introduziu no NFSv4 as categorias persistente e volátil; os RFCs 7530 e 8881 as mantiveram.

Um identificador persistente fica fixo durante a vida do objeto. Deve sobreviver à reinicialização do servidor e à migração. O armazenamento pode mudar de lugar sem obrigar o cliente a interpretar a mudança ou aceitar uma identidade nova sem motivo.

Isso não torna a referência eterna. Se o arquivo for removido ou o sistema de arquivos deixar de estar disponível, o servidor responde NFS4ERR_STALE. A garantia importante é negativa: a referência antiga não passa, em silêncio, a apontar para o novo ocupante de uma posição interna reciclada.

Alguns ambientes não conseguem prometer tanta continuidade. Camadas hierárquicas, limitações do sistema operacional, migração e tabelas reconstruídas após o boot podem produzir referências condicionais. O NFSv4 permite então identificadores voláteis e usa fh_expire_type para expor quando eles podem perder validade.

Os documentos dão um exemplo com horário de inicialização, posição em uma tabela e geração. Uma geração antiga denuncia o reaproveitamento da posição. É só um exemplo: o protocolo padroniza a resposta observável, não obriga todos os servidores a montar os mesmos campos.

Obsoleta não quer dizer a mesma coisa que expirada

NFS4ERR_STALE afirma que a referência não alcança mais o objeto esperado. Ele foi eliminado, ou o sistema de arquivos de uma referência persistente está indisponível.

NFS4ERR_FHEXPIRED fala da continuidade de uma referência volátil. A tabela que a interpretava pode ter sumido no boot, a geração pode ter mudado, ou a migração pode ter ultrapassado sua garantia. O arquivo ainda pode existir; o servidor apenas não aceita os bytes antigos como prova de uma referência atual.

Juntar os dois códigos apagaria informação. Chamar toda expiração de exclusão produz um falso alerta de perda de dados. Tratar toda obsolescência como falha temporária alimenta tentativas intermináveis contra algo removido. O protocolo não sabe tudo, mas evita afirmar mais do que sabe.

O caminho volta como mecanismo de recuperação

No NFSv4, identificadores especiais de raiz e as operações do espaço de nomes substituem parte do antigo ponto de partida de montagem. PUTROOTFH seleciona a raiz; sequências de LOOKUP percorrem os componentes. Se o cliente guardou os nomes, pode obter uma nova referência depois de uma expiração.

Essa resolução ocorre no presente. Outro ator pode ter renomeado o arquivo, removido o objeto ou criado um substituto com o nome antigo. O caminho recomposto pode chegar ao original, a outro objeto ou a nenhum. Por isso é preciso verificar novamente atributos, bloqueios, estado em cache e a intenção de qualquer operação pendente.

A referência também não é uma permissão. O servidor avalia a autorização das operações. Encontrar novamente o arquivo não restaura automaticamente um direito, nem demonstra que repetir uma escrita interrompida é seguro.

A contribuição histórica do NFS foi limitar com precisão o que o identificador dizia. O servidor escolhe o mapa interno e deve declarar quando a continuidade termina. O padrão fornece regras comuns mínimas: opacidade, igualdade limitada, categorias de duração e falha honesta. O cliente preserva nomes suficientes para tentar recuperar e não transforma uma nova resolução em prova retroativa.

O caminho pode mudar e o objeto permanecer. O objeto pode permanecer e o identificador expirar. O identificador pode ser válido e a operação continuar proibida. A segurança está em não comprimir essas três relações em um único token.

Fontes