Aula 15 - 3/10/2001

NFS - Network File System

• Lançado em 1985 pela Sun Microsystems junto com o SunOS
• Numa iniciativa pioneira, divullgou também o "protocolo NSF" através do qual qualquer um poderia implementar o seu cliente ou servidor
• Apareceram implementações para todos os tipos de UNIX, DOS, OS/2, MacOS, Windows e até para computadores de grande porte (IBM/VMS)
• Baseado em RPC e XDR
• Objetivo principal do desenho: ser livre de estado
• traz consigo as vantagens e desvantagens que vimos na última aula
• Mensagens são enviadas por UDP/IP. Caso não haja resposta, repete até 3 vezes.
• Se não responde depois da terceira vez, há duas opções:
1. NFS server brucutu not responding, still trying...
2. aborta operação e dá mensagem de erro para o cliente
• Como o protocolo é livre de estado, o servidor não precisa saber o que se passou.
• Solaris usa um serviço diferente para locks: Network Lock Manager
• Montagem do espaço de nomes é feita através do protocolo de montagem : cliente envia pathname, servidor devolve file handle
• Exemplo:
• mount /dev/hd1a /
• mount mafalda:/mailboxes /var/spool/mail
• mount brucutu:/executaveis /usr/bin
• mount limbo.ime.usp.br:/mirror /usr/local/espelho
• /etc/fstab - lista de diretórios a serem montados automaticamente na inicialização da máquina
• /etc/mtab - llista de diretórios montados em um dado instante
• automounter: mecanismo de montagem dinâmica de diretórios
• sistema monta automaticamente quando usuário entra em diretório
• sistema desmonta automaticamente se usuário não usa diretório por muito tempo (e.g., 5 minutos)
• Vantagem: inicialização mais rápida. Principalmente se algum servidor não está disponível
• automounter permite a especificação de vários servidores para o mesmo diretório
• o primeiro a responder ganha
• este é um mecanismo rudimentar para replicação de arquivos read-only com balanceamento de carga
• espera-se que o servidor mais livre responda primeiro mas nada garante isso.

Política de Consistência

• é bem relaxada, assume que haverá muito pouco compartilhamento com escrita.
• primeiramente se usou escrita no fechamento (write-on-close)
• depois modificou-se para escrita retardada (delayed write): envia as escritas só quando blocos de 8KB são preenchidos
  
• Para minimizar as inconsistências, adota a seguinte heurística:
1. verifica com o servidor se a cópia local é a mais recente todas as vezes em que um arquivo é aberto
   
2. quando recebe um bloco de dados do servidor, este bloco contém informações sobre a versão do arquivo; neste caso, o cliente a verifica novamente
3. a partir do momento em que um dado é guardado no cache, ele é considerado válido por 3 segundos (no caso de arquivos) ou por até 60 segundos (no caso de diretórios)
• A falta de consistência não permite, por exemplo, que se use um arquivo como LOCK (uma técnica muito comum e conveniente em sistemas centralizados
  

Segurança

• É bem fraca
• Cada servidor guarda no arquivo /etc/exports os nomes dos clientes que estão autorizados a montar cada diretório e se o acesso será só para leitura ou para leitura e escrita
• Requisições contém o uid e o gid do usuário e servior verifica se acesso pode ser feito => servidor confia no cliente totalmente
• Se torna necessário que os uids e gids sejam os mesmos em toda rede => se usa para isso o Network Information Service (NIS)
• Se necessário, é possível fazer autenticação mútua entre cliente e servidor usando DES.
• Não há criptografia dos dados transmitidos via rede

Arquitetura

• Proposta inovadora do NFS: Figura 2.5 de Kon94
• Camada Sistema de Arquivos Virtual é uma abstração de diferentes tipos de sistemas de arquivos.
• v-node pode apontar para r-node (caso do NFS) ou i-node (caso de SA local UNIX)
• tipo real do sistema de arquivos de cada diretório é transparente para o usuário
  

SPRITE Network Operating System

• Um sistema operacional para redes locais
• Seu SAD para redes locais é muito eficiente
  
• Desenvolvido a partir de 1985 na Universidade da California em Berkeley pela equipe de John Ousterhout.
• http://www.cs.berkeley.edu/projects/sprite/sprite.html
• Características interessantes do Sprite:
• 100 mil linhas de código em C escritas desde o início para a criação de um novo SO
• Núcleo multithreaded para dar maior flexibilidade e aproveitar máquinas com vários processadores
• Inovações sob o ponto de vista do serviço oferecido:
• Semântica UNIX em acessos concorrentes a arquivos distriuídos
• Migração de processos transparentemente ao usuário e ao processo
• Espaço de nomes único válido para toda a rede local
  
• Inovações do ponto de vista da implementação
• Grandes caches de tamanho variável através de adaptação
• Resolução de caminhos através de tabelas de prefixos
• Memória virtual implementada através de arquivos comuns no sistema de arquivos distribuído

Migração de Processos

• É muito facilitada pelo fato da memória virtual ser implementada usando o SAD. Passos:
1. bloqueia o processo
2. joga todas suas páginas para o disco
3. envia para outra máquina o conteúdo dos registradores e sua entrada na tabela de processos
4. coloca processo na fila de prontos da nova máquina
   

Espaço de Nomes

• Dividido em domínios
• Cada servidor é responsável por um ou mais domínios
• Idéia inovadora: tabela de prefixos mantidas pelos clientes Tab. 2.3 de Kon94
• Sempre que precisa acessar um arquivo de caminho P, procura o prefixo mais longo na tabela de prefixos que seja um prefixo de P
• Daí envia para o servidor correspondente àquela linha da tabela o índice encontrado na tabela e o resto do caminho
• Dentro do SA do servidor, pode haver um remote link. Se no meio do caminho solicitado pelo cliente há um remote link, o servidor responde ao cliente dizendo que aquele diretório não é de sua responsabilidade
• Neste caso, o cliente envia um broadcast perguntando quem é o responsável por aquele caminho e ao obter a resposta, atualiza a sua tabela de prefixos

• Tabelas de prefixos inicialmente são vazias e crescem dinamicamente
• Se um servidor responsável por um diretório presente na tabela de um cliente não responde, o cliente envia um novo broadcast
• Isso facilita muito a migração de domínios: administradores podem rearranjar os domínios entre os servidores sem a necessidade de reconfigurar os clientes. A reconfiguração é feita posteriormente automaticamente quando necessário.
• Esse mecanismo é mais eficiente do que o NFS porque são feitas menos traduções de caminho para file handle
• Se servidores no meio do caminho estiverem fora do ar em um dado instante, o cliente conseguirá acessar os arquivos da mesma forma desde que o servidor final esteja funcionando e a entrada na sua tabela de prefixos estiver atualizada

• Pode-se configurar os servidores para replicação de arquivos read-only e para que servidores diferentes sirvam arquivos binários de clientes de plataforma diferentes.
• Problema: se há uma falha de energia e todos os clientes voltam a funcionar no mesmo instante, pode haver um congestionamento da rede com os broadcasts. Com algum cuidado (e uma tese de doutorado mais tarde) é possível resolver esse problema.
  

Política de Consistência

• Através de dados coletados durante 8 dias numa rede com 52 usuários e 40 máquinas, observaram:
• a política de consistência do NSF levaria a 20% dos usuários acessarem algum dado inconsistente em algum instante
• Isso levaria a algum problema sério? Não sei. Os pesquisadores do Sprite provavelmente também não.
• O problema maior é que como usuários (e programadores) que usam NFS sabem que não se pode confiar nele, quando uma aplicação precisa de consistência, ela usa algum outro mecanismo, que não o NFS, para garantir isso.
• Se o próprio SAD garantir a consistência, seria possível implementar um monte de coisas interessantes usando o SAD
• Exemplo: aplicação de bate-papo via Internet implementada no WebOS
• Enfim um cache consistente
• semântica UNIX (consistência perfeita) aliada a um alto desempenho
  
• cache dos clientes armazenam tanto leituras quanto escritas (delayed-write )
• a cada 30 segundos, todos os blocos sujos que estão há mais de 30 segundos sem alteração são enviados para o servidor
• cada escrita é enviada para o servidor em no máximo 60 segundos e daí em no máximo 60 segundos para o disco
• quando um usuário salva um arquivo, ele pode demorar até 2 minutos para chegar ao disco
• vantagem: bom ganho no desempenho médio
• desvantagem: dados podem se perder se cliente ou servidor caem; se o servidor cae e os dados são perdidos, pode nem ser possível informar isso ao cliente
• Diferentemente do NFS, os servidores guardam a informação de qual cliente está usando qual arquivo e se o uso é só para leitura ou não
  
• Situações possíveis:
1. um ou mais clientes lendo simultaneamente, nenhum escrevendo: cache habilitado
2. apenas um cliente lendo e escrevendo: cache habilitado
3. acesso concorrente com escrita: cache desabilitado
• como o último ítem é muito raro, o ganho médio de desempenho é muito significativo
• ainda é preciso tomar alguns cuidados com acesso seqüencial com escrita. Como servidor possui todo o estado, não é problema.
• Conclusão: é mais eficiente do que o NFS e ainda por cima garante a consistência.
• Pergunta: por que não se tornou o padrão ao invés do NFS

Referências

• Tanenbaum, seção 5.2.5; Galli, seção 8.4; Silberschatz 5a ed. cap 17.6; monografia sobre SAD na página de leituras recomendadas.
• Quem preferir uma referência em português pode dar uma olhada no capítulo 2 da minha tese de mestrado. Mas, por favor, não gaste papel à toa imprimindo a tese toda ou o capítulo todo.