Resumo

  • A RFC 1094 diz que um servidor NFS sem estado de protocolo não consegue, sozinho, manter o comportamento em que um processo continua usando um arquivo depois que seu nome sai do diretório.
  • A alternativa sugerida ficava no cliente: renomear na hora da remoção e apagar a nova entrada quando a abertura local terminasse. O RFC não padroniza a implementação nem a recuperação após uma falha do cliente.

Quatro momentos, dois sistemas

Uma aplicação abre um arquivo. O cliente NFS transforma leituras e gravações em chamadas remotas. Em seguida, alguém remove o nome do diretório. Por fim, o processo fecha a referência que já mantinha. Se essas etapas forem resumidas como um único ato de “apagar”, desaparece a pergunta importante: quem sabe que o arquivo ainda está em uso?

Em alguns sistemas locais, a retirada do nome não encerra a referência aberta. O processo pode continuar lendo ou gravando até fechar. Quando o arquivo está em outra máquina, porém, o sistema local da aplicação e o servidor NFS não observam os mesmos fatos.

A RFC 1094, publicada em março de 1989, chama essa diferença pelo que ela é: um servidor stateless não pode implementar essa semântica. O cliente poderia contornar a limitação trocando o nome do arquivo durante a remoção e apagando o novo nome somente no fechamento.

Essa recomendação é pequena, mas precisa. Ela não promete que o protocolo acompanha cada processo remoto. Mostra como uma interface local pode continuar familiar mesmo quando o fio não transmite toda a semântica local.

O servidor recebia REMOVE, não um aviso de OPEN

Na versão 2, há procedimentos NFS para procurar nomes, ler, gravar, criar, remover e renomear. REMOVE recebe uma referência a diretório e um nome. Não existe uma chamada NFSv2 OPEN ou CLOSE que crie e encerre no servidor um registro da última abertura feita por determinado cliente.

Um file handle aparece nos pedidos para identificar o objeto com que a operação trabalha. Ele não conta quantos processos locais ainda o usam. O núcleo do cliente pode concluir uma abertura de arquivo sem enviar ao servidor uma operação correspondente; mais tarde, o servidor pode receber a remoção do nome sem saber que a aplicação ainda tem uma referência local ativa.

O desenho deixa a decisão de compatibilidade com quem consegue observá-la. O servidor não tem a informação de abertura. O cliente tem o contexto do processo e pode representar a remoção de outra maneira. A RFC não diz que todos os detalhes do sistema de arquivos precisam atravessar a rede.

A remoção real ficava para depois

Pelo caminho descrito, o cliente muda o nome em vez de apagar a entrada na hora. Para o usuário, o nome original desaparece. Para o servidor, a entrada temporária continua existindo até que o cliente saiba que a referência foi fechada.

O nome e o espaço ocupado passam a ter calendários distintos. A interface pode dizer “removido” enquanto ainda há uma entrada remota. O comportamento esperado pela aplicação depende de uma cadeia que inclui o kernel local, o cliente NFS e a política do servidor.

A RFC 1094 não escolhe o formato do nome provisório, não define como impedir colisões e não explica o que fazer se o cliente reiniciar antes do fechamento. Tampouco descreve como outro cliente verá a entrada temporária. A sugestão não é uma especificação de commit distribuído, nem uma afirmação sobre qualquer implementação específica.

Do ponto de vista operacional, uma limpeza adiada pode falhar ou permanecer pendente; isso é uma inferência da sequência sugerida, não uma estatística publicada. Para afirmar o que um sistema realmente fazia, seria necessário consultar código, documentação de produto ou testes daquele sistema.

Stateless era uma propriedade da conversa

A motivação era reduzir o estado de protocolo que o servidor precisava manter por cliente. Se a rede ou o serviço parasse, o cliente poderia repetir chamadas sem reconstruir uma sessão de arquivos abertos. Nada disso tornava o armazenamento sem estado: conteúdo, atributos, nomes de diretório e blocos continuavam sujeitos à persistência normal do sistema de arquivos.

Uma abertura é, antes de tudo, uma relação entre processo e sistema operacional local. NFSv2 não tinha as operações remotas que permitiriam ao servidor manter essa relação. A própria RFC tratou travas de arquivo e de registro como serviços separados. O protocolo cobria um conjunto útil de operações, sem assumir toda a autoridade do kernel local.

Mais tarde, NFS fez escolhas diferentes. NFSv3 manteve uma interface sem OPEN e CLOSE remotos; NFSv4, na RFC 7530, incluiu essas operações e stateids. Isso não prova migração geral nem consistência de todas as implementações. Mostra que o estado de abertura pode ser explicitado quando as partes aceitam coordená-lo.

A responsabilidade acompanha a informação

O servidor controla o diretório exportado e executa REMOVE. O cliente sabe quais processos retêm uma abertura. Sem essa informação, o servidor não consegue decidir sozinho quando a remoção deixa de afetar um processo ativo. O renomeamento provisório liga os dois pontos de observação, mas também torna a limpeza uma obrigação do cliente.

Uma aplicação que depende dessa semântica deve validar o par real de cliente e servidor. O operador precisa entender por que um nome temporário pode persistir depois de o usuário remover o nome original. E o registro operacional precisa dizer quem encerrou a abertura e quem confirmou a remoção final. A RFC não define um painel ou procedimento para fazer isso.

O benefício do servidor mais simples foi real para o desenho do protocolo. O custo foi local: implementar a adaptação quando necessária e verificar a sequência em que a aplicação depende. Montar um compartilhamento não demonstra que toda convenção de arquivos locais foi preservada.

Fontes e limite da evidência

Os documentos mostram a especificação e as decisões de projeto, não a prevalência do truque de renomear, o comportamento de recuperação de um cliente específico ou a taxa de falhas observada.