NFS

Desenho de NFS

Originalmente desenvolvido pela Sun, suporta sistemas Unix e não Unix.

• Baseado num modelo cliente servidor.
• Comunicação via RPC síncrona.
• Cada servidor exporta um ou mais sistemas, para leitura ou leitura-escrita.
• Montagem pode ser hard, tenta até conseguir, ou soft, desiste após um bocado, ou spongy, hard no princípio e depois soft.
• Cliente pode não ser privilegiado, e pode montar o mesmo sistema em vários locais.
• Servidor apenas pode exportar FS locais e não pode atravessar pontos de montagem.

Objectivos de NFS

Os objectivos da Sun eram:

1. NFS não ser restrito a Unix (tanto servidores como clientes).
2. Protocolo não devia depender de hardware.
3. Mecanismo de recuperação simples.
4. Acesso transparente a ficheiros remotos.
5. Manter semânticas de Unix para clientes Unix.
6. Desempenho comparável a disco local.
7. Implementação independente de transporte (UDP, TCP).

Componentes de NFS

Componentes principais:

• NFSv2: protocolo definindo operações e seus argumentos. Pedidos incluem NULL, GETATTR, SETATTR, LOOKUP, READLINK, READ, WRITE, CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR, RMDIR, READDIR, e STATFS. Argumentos podem ser uma fhandle, dirfh, offset.
• RPC: define o formato das interacções entre o cliente e o servidor. Pedido NFS é um pacote RPC.
• XDR: Extended Data representation usada por RPC para codificar dados.
• Código de implementação do servidor NFS.
• Código de implementação do cliente NFS.
• Protocolo de montagem: NULL, MNT, DUMP, UNMT, UNMTALL, EXPORT.
• Processos daemon: nfsd e mountd no servidor, e biod suporta I/O assíncrono no cliente.
• O Network Lock Manager e o Network Status Monitor permitem locking de ficheiros.

Statelessness

Todos os pedidos são independentes:

• não há pedidos para abrir e fechar ficheiros. Registos de pedidos só para estatísticas ou para caching.
• Se um servidor faz reboot, o cliente continua a enviar os pedidos até que o cliente faz reboot, e nessa altura o servidor pode devolver a informação.
• O servidor deve colocar em armazenamento estável todas as alterações antes de responder (dados de ficheiros, dir., inode, etc.)

O Conjunto de Protocolos

Os protocolos mais importantes são:

1. XDR usa uma representação tipo Sun com inteiros, objectos opacos, strings, vectores e estruturas.
2. RPC da Sun é um protocolo síncrono de comunicação entre cliente e servidor. É seguro apesar de habitualmente ser implementado sobre UDP. Campos incluem xid, direcção, rpc_vers, programa e sua versão, informação e autenticação.
3. Autorização pode ser NULL, UNIX, SHORT, usada depois do primeiro pedido Unix, DES, e KERB.

Implementação de NFS

• File Handles: evitam ter sempre que abrir o ficheiro. Incluem o fsid, nó-i e o número de geração.
• Montagem comunica com mountd. Servidor NFS mantém uma lista de directórios exportados, para verificar rápidamente quais as permissões.
• lookup.

Compatibilidade com Unix

• Em Unix, util. pode sempre escrever num ficheiro aberto, mesmo que o dono tenha alterado as permissões. NFS permite ao dono escrever e ler sempre de um ficheiro, é o cliente que segue as operações.
• Ficheiros removidos continuam acessíveis em Unix. Em NFS cliente muda a operaração para um rename, e no fim um remove. Problema: cliente pode crashar.
• Reads e writes podem involver várias operações e não são portanto atómicos entre clientes: usar NLM.

Performance de NFS

• Operações que alteram o servidor são extremamente lentas porque esperam que os writes sejam colocados no armazenamento. Além disso, obter atributos obriga a um RPC por ficheiro: problema com ls -l. Retransmissões podem piorar situação em redes sobrecarregadas.
• Clientes fazem caching de dados. Perigoso: atributos são guardados no máximo de 1 min, e blocos de dados são válidos se a data de alteração não tiver sido mexida.
• Cliente usa writes assíncronos para blocos completos, e writes atrasados para blocos parciais.
• Servidor pode usar NVRAM em vez de disco. Driver pode optimizar transferências de NVRAM para disco.
• Write-Gathering: servidor espera em vez de processar todos os writes de uma vez. Útil se vários biods no cliente.

Retransmissões

• Pacotes perdidos podem acontecer com UDP.
• Podem afectar operações idempotentes, que podem ser executadas várias vezes, ou não idempotentes, como CREATE ou REMOVE.
• Solução: manter uma cache de pedidos que podiam dar problemas. Se pedido falha, verifica se é uma retransmissão e está na cache.
• Solução é incompleta: Digital faz cache de todos os pedidos.

NFS: Extensões

• Existem servidores dedicados, alguns dos quais paralelos e com FS muito diferente de UFS.
• Problemas de segurança: UID e GID devem ser os mesmos em todo o grupo.
• Problemas são limitados com UID remapping.
• Melhoramentos em NFSv3, como writes assíncronos, evita pedidos desnecessários, READDIRPLUS, e > tamanho máximo.