Danise Víctor Xavier

Departamento de Informática

Universidade Federal de Pernambuco

e-mail: dvx@di.ufpe.br

Recife, 30 de maio de 1996

O NFS (Network File System) é um sistema de arquivo distribuído que provê acesso transparente a discos remotos. Este serviço permite centralizar a administração dos discos, assim como o NIS permite a administração centralizada das informações dos usuários e dos hosts.

Ao invés de duplicação de diretórios comuns como o /usr/local em cada sistema, o NFS oferece compartilhamento de uma única cópia do diretório entre todos os sistemas da rede.

Na visão do usuário, a utilização do NFS significa não ter que se logar em cada sistema para acessar os arquivos. Eles não precisam utilizar o comando rcp ou fitas para transferir arquivos entre sistemas locais. O NFS garante que os arquivos necessários aos usuários são acessíveis de qualquer host da rede.

O NFS é construído sobre um protocolo RPC e impõe o relacionamento cliente/servidor aos hosts que o utilizam. Um servidor NFS é um host que possui um ou mais sistemas de arquivos e os torna disponível pela rede. O cliente NFS monta estes sistemas de arquivos de um ou mais servidores. Um cliente NFS pode ser uma máquina diskless. E este é provavelmente o maior problema que o NFS encontra, pois não é trivial disponibilizar uma máquina sem qualquer recurso local como sendo um membro de uma rede funcionando completamente bem, além da integração desta máquina com outros servidores como o do NIS. Informações de como configurar, inicializar e gerenciar um cliente diskless podem ser vistas em [2].

Existem dois aspectos para a administração de sistemas utilizar o NFS: primeiramente escolher um esquema de nomes para os sistemas de arquivos e montá-lo. O objetivo do esquema de nomes é utilizar a transparência dos dados de modo amplo. E segundo, configurar os servidores e clientes NFS. Um ambiente com muitos servidores NFS e centenas de clientes podem rapidamente se tornar de complexo gerenciamento.

1.1. Características do NFS

• Stateless - O NFS é um sistema de arquivo distribuído que mantêm o estado corrente de um ambiente, mesmo quando diante de um break do sistema. Quando o servidor NFS volta a funcionar corretamente, o estado anterior é restaurado e o funcionamento continua como se não houvesse ocorrido nenhuma pausa.

• Caching - A caching de dados permite que as informações utilizadas mais recentemente, sejam alocados para posterior uso, ou ainda, pode vir a carregar os dados em antecipação a operações futuras. Por exemplo, os dados lidos a partir de um disco podem ser mantidos até uma subsequente escrita destes dados. No NFS a caching de dados significa não ter que enviar requisições RPC através da rede para um servidor. Ou seja, os dados são armazenados na memória do cliente NFS, e quando solicitados são buscados localmente, não executando portanto acesso ao disco remoto.

• File Locking - Esta característica, permite que um processo tenha acesso exclusivo a um arquivo ou parte deste, e força outros processos que estão solicitando acesso ao mesmo arquivo, aguardarem a liberação. Detalhes de File Locking em [2].

2.1. Interface VFS

Além de configurar as máquinas que se comportarão como servidores e clientes NFS, ou ainda definir esquemas de nomes que facilitem a manutenção dos sistemas de arquivos a serem montados ou exportados; é também necessário realizar análises dos padrões de uso no NFS, bem como depurar problemas operacionais, de forma que sejam sugeridas otimizações de performance. Para isto é importante se ter um conhecimento interno do protocolo NFS e dos daemons que o implementam.

Assim como o NIS, NFS é também implementado como um conjunto de procedimentos RPC que utilizam a representação de dados externos (XDR) para passar os argumentos entre clientes e servidores. Este mecanismo possibilita transparência no acesso aos discos remotos, o que é bem vindo no ambiente de sistemas distribuídos NFS.

Um sistema de arquivo montado via NFS apresenta dois níveis de transparência:

• O sistema de arquivo parece residir em um disco acoplado ao sistema local, e todas as entradas deste sistema de arquivo, arquivos e diretórios, são vistas do mesmo modo, tanto local como remotamente.

• Os sistemas de arquivos NFS não contêm informações sobre o servidor de arquivos do qual eles foram montados. O servidor de arquivos NFS pode ser de uma arquitetura diferente ou executar um sistema operacional completamente diverso, com uma estrutura de sistemas de arquivos radicalmente diferente. O NFS esconde as diferenças na estrutura de sistemas de arquivos básica e faz o sistema de arquivo remoto apresentar a mesma estrutura do cliente.

O NFS alcança o primeiro nível de transparência através da definição de um conjunto genérico de operações dos sistemas de arquivos que são executadas pelo VFS (Virtual File System). Em um cliente NFS do UNIX, a interface VFS faz com que todos os sistemas de arquivos NFS sejam vistos como sistemas de arquivos UNIX, mesmo que eles tenham sido exportados de servidores IBM MVS ou VAX/VMS. A figura abaixo ilustra esta transparência.

O segundo nível de transparência surgi a partir da definição de virtual nodes, que estão mais relacionados a estrutura dos inodes do UNIX, mas esconde a estrutura real do sistema de arquivo físico abaixo dele. O conjunto de todos os procedimentos que podem ser executados sobre os arquivos, é a definição da interface vnode. A especificação do vnode e do VFS definem o protocolo NFS.

Ações que operam no sistema de arquivos como um todo, tais como informar a quantidade de espaço livre em um sistema de arquivo, são chamadas operações VFS; enquanto que chamadas que atuam diretamente com os arquivos ou diretórios, são operações vnode. Algumas operações vnode não são definidas em certos tipos de sistemas de arquivos. Os sistemas de arquivos DOS, por exemplo, não possui qualquer equivalência a links simbólicos. Sendo assim, um servidor de arquivos NFS executando sobre uma máquina DOS rejeita qualquer tentativa de utilizar uma operação vnode para criar um link simbólico.

Em uma chamada de sistema UNIX local, os objetos definidos na interface são rotulados como descritores de arquivos, o qual identifica unicamente um arquivo dentro do escopo de um processo. A contrapartida dos descritores de arquivos no NFS é handles de arquivos, os quais são ponteiros para sistemas de arquivos remotos. Um handle não tem significado para o cliente, pois ele somente pode ser interpretado no contexto de sistemas de arquivos remotos. Informações mais detalhadas de como funcionam os handles de arquivos veja [2].

O NFS é um protocolo baseado em RPC, com um relacionamento cliente/servidor entre a máquina que possui um sistema de arquivo a ser distribuído e a máquina que aguarda o acesso a estes sistemas de arquivos. O daemon do servidor NFS, nfsd, aceita as chamadas RPC dos clientes. Os servidores NFS também executam o daemon rpc.mountd para tratar das requisições de montagem dos sistemas de arquivos e algumas traduções de caminhos completos. No cliente NFS, o daemon biod está normalmente em execução para melhorar a performance do NFS, apesar de não ser imprescindível.

No cliente, cada processo que está utilizando os arquivos NFS é um cliente do servidor. As chamadas de sistema dos clientes que acessam os arquivos montados via NFS fazem chamadas RPC aos servidores NFS dos arquivos que foram montados. O VFS estende as operações das chamadas de sistema básicas a operações read( ) e write( ). Com o VFS as chamadas de sistema básicas e aquelas orientadas a sistemas de arquivos são modificadas para conhecerem como tratar com sistemas de arquivos não locais.

2.2.1. Procedimentos RPC

O protocolo RPC NFS contêm 16 procedimentos, cada um deles operam ou com arquivos ou sistemas de arquivos. Os procedimentos básico executados no servidor NFS podem ser agrupados em:

• Operações de diretórios - incluem mkdir e rmdir, as quais criam e destróem diretórios como seus equivalentes em UNIX. readdir lê um diretório, utilizando um ponteiro de diretório para executar leituras seqüenciais do mesmo diretório. Outros procedimentos são rename, remove e create. A operação de lookup é de fundamental importância no mecanismo de tradução do caminho completo no handle do arquivo. Ela procura pelo nome do diretório e retorna o handle que aponta para ele.

• Operações de arquivos - estão diretamente associadas as chamadas de sistema do UNIX: read e write movem os dados para e dos clientes NFS, e getattr e setattr configuram ou modificam atributos dos arquivos.

• Operações de link - incluem link, o qual cria um hard link no servidor, e symlink e readlink que criam e lêem os valores de links simbólicos, respectivamente.

• Operações de sistemas de arquivos - apresenta a operação statfs que retorna informações sobre os sistemas de arquivos montados. Outras operações de sistemas de arquivos incluem montagem e desmontagem de um sistema de arquivo, mas estas são tratadas pelo daemon rpc.mountd ao invés do daemon RPC nfsd. As operações de montagem são separadas do protocolo NFS pois os pontos de montagem envolvem resolução de caminhos completos, e a sintaxe destes é peculiar a cada sistema operacional.

É importante observar que o protocolo RPC NFS e a interface vnode são coisas distintas. A interface vnode define um conjunto de serviços do sistema operacional que são usadas para acessar os sistemas de arquivos, NFS ou locais. Vnodes simplesmente generaliza a interface para objetos de arquivo. Existem muitas rotinas na interface vnode que correspondem diretamente a procedimentos no protocolo NFS, mas ela também contém implementações dos serviços do sistema operacional tal como mapeamento dos blocos de arquivos e gerenciamento de cache.

O protocolo NFS é uma realização específica de uma destas interfaces vnode. É utilizado para executar operações vnode específicas sobre arquivos remotos.

2.2.2. Stateless

O protocolo NFS é stateless, significando que não há necessidade de manter informações sobre o protocolo no servidor. O cliente mantém trilhas de todas as informações necessárias para enviar uma requisição ao servidor, mas o servidor não possui informações sobre requisições prévias, ou como as várias requisições se relacionam.

A escolha de um protocolo stateless vem de uma motivação principal, que é minimizar a sobrecarga quando da recuperação de um estado inativo. E isto implica em várias questões de design e implementação:

• Requisições RPC NFS devem descrever por completo as operações a serem executadas. Por exemplo, a escrita de um bloco de arquivo deve conter o handle do arquivo, o offset, e o comprimento da operação de escrita.

• Muitas requisições NFS são indepotentes, ou seja, um cliente NFS pode enviar mais de uma vez a mesma requisição sem qualquer efeito nocivo. Por exemplo, a leitura de um bloco de dados terá a mesma saída independente do número de vezes que é executada tal operação. Contudo, algumas operações não são indepotentes, como por exemplo, a remoção de um arquivo.

• Pelo fato das requisições poderem ser repetidas e as informações de estado serem proibidas, o NFS utiliza um protocolo de transporte de suas requisições RPC não confiável, o UDP (User Datagram Protocol). O UDP é um protocolo stateless não prometendo qualquer garantia da entrega dos pacotes, nem da ordem da entrega. Os servidores NFS notificam aos clientes quando uma chamada RPC é completada através do envio de um reconhecimento, também utilizando UDP.

2.2.3. Retransmissão de requisições

Requisições NFS são enviadas do cliente ao servidor em qualquer momento. Contudo, um único processo cliente não poderá solicitar outra chamada RPC até que a chamada corrente seja completada e tenha sido reconhecida pelo servidor NFS. Um host cliente pode manter várias chamadas RPC em progresso simultaneamente, vindas de vários processos, mas cada processo garante que suas operações de arquivos são ordenadas através dos reconhecimentos.

Quando um cliente solicita uma requisição RPC, ele inicializa um período de timeout durante o qual o servidor deve servir e reconhecer esta requisição. Se algum problema ocorreu e o servidor não atendeu a requisição dentro do intervalo de tempo determinado, ou por tê-la perdido, ou por sobrecarga no servidor, o cliente retransmite a requisição. Porém, se a operação houver sido executada e o atraso foi o envio do reconhecimento, pelo fato das requisições serem indepotentes, não haverá problemas com a duplicação de requisições (isto se o servidor possuir cache de requisições duplicadas). Quando o cliente receber a segunda confirmação, ele a descarta.

A cache de requisições duplicadas nos servidores NFS normalmente contém poucas centenas de entradas, ou seja, os últimos poucos segundos (no máximo) de requisições NFS em um servidor ocupado. Esta cache é limitada no tamanho da janela na qual requisições NFS não indepotentes sejam consideradas duplicadas, causadas pela retransmissão, ao invés de requisições distintas.

A segurança de sistemas de arquivos tem dois aspectos:

• Controlar o acesso a arquivos remoto - envolve o mapeamento da semântica das operações de arquivos UNIX no sistema NFS, de modo que certas operações sejam proibidas sempre que a verificação das credenciais do usuário remoto falhe.

• Limitar a revelação dos dados - é mais difícil de ser alcançada, pois normalmente envolve a encriptação do conteúdo dos arquivos. A aplicação cliente pode escolher forçar a encriptação de seus próprios dados e armazenar os arquivos no servidor de forma encriptada. Neste caso, as requisições NFS dos clientes trafegam pela rede contendo blocos de dados encriptados. Entretanto, se o arquivo é armazenado e utilizado na forma de texto, as requisições NFS de leitura e escrita irão conter dados no formato texto. É possível prevenir o acesso não autorizado restringindo as permissões de escrita e forçando a autenticação dos usuários, mas existem poucos mecanismos contra a "escuta escondida" sobre a rede.

Cada requisição NFS, incluindo requisições de montagem, contém um conjunto de credenciais de usuários com o UID e uma lista de ID’s de grupos (gid) aos quais o UID pertence. As credenciais do NFS são as mesmas utilizadas em arquivos locais. No servidor NFS, estas credenciais são utilizadas para executar a verificação das permissões que são parte do acesso a arquivos UNIX. Existem três áreas nas quais as credenciais NFS podem não concordar com a estrutura das credenciais locais do usuário: o usuário ser o superusuário, o usuário pertencer a muitos grupos, ou nenhuma credencial ser fornecida (requisição anônima).

Cada implementação NFS possui um número limitado de grupos que podem ser passados na estrutura das credenciais para uma RPC NFS. Este número normalmente é combinado com o número máximo de grupos aos quais um usuário pode pertencer.

Ao superusuário não são dadas permissões de acesso normais a arquivos montados via NFS. A motivação por trás desta restrição é que o acesso de root seja garantido baseado por máquina física. Um usuário que é capaz de se tornar root em uma máquina não deverá necessariamente possuir permissões de modificar os arquivos no servidor de arquivos.

Para forçar as restrições no acesso do superusuário, o UID do root é mapeado para o usuário anônimo nobody na estrutura da credencial RPC NFS. O superusuário freqüentemente possui menos permissões comparado a um usuário sem privilégios para os sistemas de arquivos montados via NFS, uma vez que o grupo nobody normalmente não inclui outros usuários.

Muitos servidores NFS garantem permissão de acesso ao root em sistemas de arquivos exportados do servidor baseado no host, utilizando a opção de exportação root=. O servidor exportando um sistema de arquivo garante acesso ao root para um host ou lista de hosts, através da inclusão deles no arquivo /etc/exports. Por exemplo:

Nos servidores bitatron e corvette o superusuário tem privilégios de root quando acessando o sistema de arquivo /home/work.

As requisições NFS que não possuem credenciais válidas são mapeadas para o usuário anônimo. A estrutura das credenciais não existem nas requisições NFS quando:

• O cliente e o servidor NFS estão utilizando Segurança RPC, mas um usuário no cliente não provê informações de autenticação adequadas ao sistema de segurança;

• O cliente é um PC e está executando PC/NFS, mas o usuário do PC não fornece um nome de usuário e uma senha válida.

• O cliente não é uma máquina UNIX, e portanto, não podem produzir credenciais estilo UNIX.

• As requisições foram fabricadas, não enviadas por um cliente NFS real.

Por default, o usuário anônimo é nobody. A opção de exportação anon permite que um servidor altere o mapeamento das requisições anônimas. Configurando o ID de um usuário anônimo no arquivo /etc/exports, o usuário desconhecido em uma requisição anônima é mapeado para um usuário conhecido localmente. Por exemplo:

Qualquer requisição que chegar sem uma credencial de usuário será executada com o UID 100. Este mapeamento é válido apenas para os sistemas de arquivos exportados com esta opção, no exemplo acima, apenas para /home/engin.

• Acesso a sistemas de arquivos - A uma máquina contendo códigos fonte pode ser dado acesso apenas a um conjunto selecionado de máquinas e não a toda a rede. A lista de hosts que podem acessá-la está incluída no arquivo /etc/exports do servidor através da opção -access. Por exemplo:

• Acesso de somente leitura - Um modo menos grosseiro de restringir acesso a sistemas de arquivos NFS por host é restringir o acesso de escrita pelo host. Por default, os sistemas de arquivos NFS são exportados com acesso de escrita disponibilizado para qualquer host que montá-los. Utilizando a opção rw no arquivo /etc/exports, é possível criar uma lista de hosts que podem montar o sistema de arquivo com permissões de escrita. Por exemplo:

Qualquer host que não pertença a relação, deverá montar o sistema de arquivo utilizando a opção -ro ou a opção de montagem -r. Uma tentativa de montar um sistema de arquivo somente leitura com permissão de escrita será realizada com sucesso. Contudo, surgirão problemas quando um cliente NFS tentar escrever realmente neste sistema de arquivo.

• Verificação da porta - Pelo fato de todos os pacotes UDP/IP conterem tanto o número da porta origem e destino, o servidor NFS pode verificar a origem do número da porta para se assegurar de que se trata de uma porta privilegiada. O monitoramento da porta NFS pode ou não ser disponibilizado por default. É normalmente controlado por uma variável do kernel, que é modificada no momento da inicialização através do script adb:

Disponibilizar um NFS seguro em um sistema de arquivo é muito simples: basta exportar e montar sistemas de arquivos com a opção secure. No servidor NFS, o arquivo /etc/exports possui entradas como:

Quando um sistema de arquivo é exportado com esta opção, os clientes devem montá-lo com a mesma opção. No cliente NFS, o arquivo /etc/fstab deverá possuir a seguinte linha de entrada:

Se um usuário acessar o sistema de arquivo seguro, pode gerar uma chave válida com o servidor, ela é utilizada para encriptar o timestamps enviado junto com as requisições NFS do usuário. Se o servidor decriptar o timestamps com sucesso, a credencial no estilo UNIX apresentada pelo usuário é confiável e é utilizada para garantir permissões normais de arquivo estilo UNIX.

Chaves públicas e chaves privadas (secretas) são mantidas no mapa NIS publickey.byname, o qual é construído a partir do arquivo /etc/publickey no servidor master. Se o NIS não está sendo executado, não é possível criar estas chaves. A única chave que é definida por default é para nobody, que é requerida para o mapeamento de usuários anônimos. O formato da entrada no arquivo /etc/publickey é o seguinte:

As chaves são strings longas de dígitos em hexadecimal, representando os valores das chaves encriptadas. No arquivo /etc/publickey, o campo secretkey contém a chave secreta do usuário encriptada junto a senha de login do mesmo.

Os identificadores no arquivo /etc/publickey possuem uma das duas formas: unix.uid@NISdomain, utilizada para chaves de usuários; ou unix.host@NISdomain, utilizada para criar uma chave de segurança RPC para o superusuário naquele host especificado.

O superusuário pode adicionar chaves de usuários através do comando newkey -u user. Neste caso, a senha do usuário deverá ser fornecida, sendo assim, o superusuário apenas deverá criar as chaves se o usuário estiver disponível para ser informado de sua nova senha. Por exemplo:

Outra alternativa, é o próprio usuário criar seus pares de chaves com o comando chkey. Por exemplo:

As chaves podem ser criadas por qualquer usuário na máquina cliente NIS, provendo a chave nobody já existente. Se esta entrada é removida do mapa publickey, então os usuários poderão utilizar o comando chkey apenas para alterar suas chaves privadas, mas não criar novas chaves.

O único meio de se criar chaves de host (para verificação de superusuário) é através do comando newkey -h como root. Por exemplo:

Para os mapas NIS receberem as atualizações dos comandos newkey e chkey, o servidor master NIS deverá está executando o rpc.ypudated.

Quando um usuário se loga em uma máquina que está executando um NFS seguro, a senha informada no momento do login é utilizada para decriptar a chave privada deste usuário. A chave secreta é dada pelo daemon keyserv (este daemon deve estar em execução nas máquinas que utilizam o NFS seguro), o qual realiza uma cache desta chave para posterior geração da chave de sessão. As chaves de sessão são utilizadas para gerar as chaves de conversão junto aos servidor NFS. O procedimento completo para a geração de uma chave de conversão é dado a seguir:

• Definição da chave pública e privada (chkey);

• A senha do login é utilizada para decriptar a chave secreta;

• Formação da chave de sessão utilizando a chave secreta e a chave pública (realizado automaticamente pelo sistema de RPC seguro[2]);

• Uma vez que a chave secreta fora decodificada com sucesso, a chave de conversão será disponibilizada, e todas as requisições NFS deste usuário irão conter um timestamps encriptado com a chave de conversão. Para validar as requisições o timestamps é decriptado.

4.1. Identificando gargalos na performance NFS

O design stateless do NFS torna simples a recuperação de uma "queda" do sistema, mas ele também torna impossível para um cliente distinguir entre um servidor que está lento e outro que está inativo. Os clientes não podem informar porque um servidor parece lento, ou os pacotes são deixados pela rede e nunca alcançam o servidor, ou o servidor poderá estar sobrecarregado.

Os potenciais gargalos existentes em um relacionamento cliente/servidor são:

• Interface de rede do cliente - O cliente pode não ser capaz de transmitir ou receber pacotes devido a problemas elétricos como suas interfaces de rede.

• Largura de banda da rede - Uma rede congestionada torna lenta a transmissão dos clientes e a resposta dos servidores. Se os retardos causados pela rede congestionada são sérios, eles contribuem com o timeout RPC.

• Carga da CPU do servidor - Uma vez que um servidor tem uma requisição NFS, ele escalona um daemon nfsd para ter uma operação mais apropriada. Se o servidor tem ciclos de CPU adequados, então a CPU não afeta a performance do servidor. Contudo, se o servidor tem poucos ciclos de CPU livres então, a latência do escalonamento pode limitar a performance do NFS.

• Uso da memória do servidor - O NFS utiliza ou a cache de buffer do disco local, ou a memória livre para armazenar as páginas que tenham sido recentemente lidas do disco.

• Largura de banda do disco do servidor - É um gargalo bastante comum: o servidor não pode simplesmente receber dados de, ou enviar dados para discos suficientemente rápidos.

• Efeitos da configuração - Configurações do kernel, pobre balanceamento de discos, e ineficiente esquema de nomes para os pontos de montagem, fazem todos os serviços operarem adequadamente, mas de modo ineficiente.

4.2. Localizando os gargalos

Para localizar os gargalos existentes em um serviço NFS, uma abordagem é iniciar uma análise em um típico cliente NFS, e avaliar sua visão dos serviços oferecidos pela rede. Ferramentas que examinam a interface da rede local, a carga da rede percebida pelo cliente, e o timeout NFS e estatísticas de retransmissão, indicam se os problemas de performance são devido a rede ou aos servidores NFS.

A ferramenta nfsstat executada no cliente compara a retransmissão e taxas de repostas duplicadas. Maiores informações sobre esta ferramenta veja o item 5.2.

4.3. Deamons do servidor NFS

O número default de daemons nfsd é escolhido empiricamente pelo fornecedor do sistema, e provê uma performance média sobre condições médias. O número de daemons é especificado como um argumento para o nfsd quando ele é inicializado pelo script de inicialização:

Em muitos casos variar o número de daemons provê uma melhor performance. Na teoria, o número de daemons nfsd poderia ser incrementado até os limites das tabelas de processo serem alcançados, embora na prática o escalonamento de muitos nfsd decremente a performance antes do limite do processo do servidor ser alcançado.

O daemon nfsd nada mais é que um processo receptor de subrotinas do kernel que executam operações de sistemas de arquivos. Ele existe como um processo separado para provê um escalonamento tratado pelo kernel, permitindo que um servidor aceite mais requisições NFS enquanto outros daemons nfsd estão aguardando que uma operação no disco seja completada.

4.4. Construção de pontos de montagem

A escolha de um esquema de nomes para os pontos de montagem podem ter um impacto significante na utilização dos servidores NFS. Duas comuns mas ineficientes construções são "caminho das pedras" dos mounts e links simbólicos residentes nos servidores.

Um caminho da pedras existe quando é montado um sistema de arquivo no topo de outro diretório o qual faz parte de um sistema de arquivo montado via NFS de um servidor diferente. Por exemplo:

É melhor montar todos os subdiretórios do /usr e
/usr/local de um único servidor de arquivos, de forma que não sejam enviadas requisições RPC para outros servidores de arquivos simplesmente pelo fato destes possuírem componentes intermediários no caminho completo.

Links simbólicos são também úteis para impor simetria às convenções de nomes através dos múltiplos sistemas de arquivos; mas eles impõem também uma carga desnecessária no servidor NFS que é regularmente chamado a resolver links. Por exemplo, considere um /usr/local que seja composto de links para vários subdiretórios em outros servidores:

Cada referência a qualquer arquivo no /usr/local deve primeiro seguir até o servidor wahoo para que ele resolva o link apropriadamente.

Se existem um ou mais links simbólicos que estão formando um gargalo na pesquisa do caminho completo no servidor, é melhor removê-los e substituí-los pelo sistema de arquivo, alvo do link, montado diretamente no cliente NFS.

Assim como o NIS, o NFS também possui um conjunto de ferramentas que auxiliam na avaliação das configurações da rede e das possíveis falhas ocorridas. O NFS apresenta um comportamento bem mais estático em suas operações: ou um sistema de arquivo é montado ou não. O NFS é executado corretamente ou simplesmente não funciona.

A saída emitida por estas ferramentas são utilizadas para avaliar a performance dos procedimentos NFS.

5.1. Informações de montagem

As informações de montagem dos sistemas de arquivos são mantidas em três arquivos:

• /etc/xtab - contém uma lista dos sistemas de arquivos exportados e sob condições normais, reflete o conteúdo do arquivo /etc/exports linha por linha. A existência do arquivo /etc/exports determina se um host é servidor NFS e executa o daemon mountd. Uma vez que o mountd está em execução, o conteúdo do /etc/xtab indica as operações de montagem que serão permitidas. Este arquivo é mantido pelo utilitário exportfs, de modo que o tempo de modificação do /etc/xtab indica o último tempo em que as informações do sistema de arquivo foram atualizadas. Se o arquivo /etc/xtab estiver desatualizado, um cliente NFS poderá não conseguir montar um sistema de arquivo mesmo que ele esteja relacionado no /etc/exports. Então, o utilitário exportfs deverá ser executado para disponibilizar o sistema de arquivo no servidor NFS.

• /etc/rmtab - mantém uma relação com os pares host e diretório do cliente que solicitou uma montagem ao servidor NFS. As entradas neste diretório são mantidas até que o cliente NFS execute explicitamente o comando umount sobre o sistema de arquivo.

• /etc/mtab - este arquivo está localizado no host local e mantém informações mais detalhadas sobre a montagem dos sistemas de arquivos. Ele contém uma lista das opções de montagem usadas por cada sistema de arquivo. Exibe também, o estado corrente do sistema. A diferença com relação ao arquivo /etc/fstab, é que este último apresenta os sistemas de arquivos a serem montados por default. O comando mount imprime como saída o conteúdo do arquivo /etc/mtab, enquanto que a opção -p, fornece o conteúdo do arquivo /etc/fstab. Por exemplo:

A ferramenta showmount é usada para visualizar as informações de montagem no lado do servidor NFS. Com a opção -a imprime os pares host e diretório dos clientes que acessam aquele servidor. Já a opção -d, imprime apenas os diretórios montados pelos clientes. Por exemplo:

% showmount -a

% showmount -d

No lado do cliente NFS, as informações de uso dos sistemas de arquivos montados são oferecidas pelo utilitário df. Ele fornece informações dos pontos de montagem e dos correspondentes sistemas de arquivos. Se o ponto de montagem é um link simbólico, o df resolve o link e exibe o sistema de arquivo para o qual o link aponta.

O comando df possui várias opções [man na linha de comando] e [2], dentre elas a opção -t fstype que exibe os sistemas de arquivos que apresentam o tipo especificado em fstype. Por exemplo:

% df -t nfs

5.2. Estatísticas do NFS

O utilitário nfsstat imprime conjuntos de dados estatísticos sobre o comportamento de ambos os elementos cliente e servidor NFS. Com a opção -c, exibe as estatísticas no lado do cliente NFS, enquanto que a opção -s fornece estatísticas do servidor. Por exemplo:

% nfsstat -s

A interpretação dos campos está detalhada em [2]. Alguns destes seriam:

• calls - número total de chamadas RPC NFS para este servidor, a partir de todos os clientes.

• badcalls - requisições RPC que foram rejeitadas pelo servidor, antes de serem passadas ao kernel.

• nullrecv - é incrementado quando um daemon nfsd é escalonado.

• badlen - requisições RPC recebidas pelo servidor foram muito pequenas.

• xdrcall - cabeçalhos XDR no pacote são mal formados.

No lado do cliente, alguns campos são iguais, porém possuem uma interpretação voltada ao cliente NFS; além disso, outros campos são acrescentados. Para uma completa descrição de seus significados veja [2].

Uma vez que o dispositivo de disco tem uma requisição de escrita ou de leitura, apenas uma falha do meio pode causar uma operação que retorne um erro. Qualquer outra falha, tal como problemas de permissão, ou falta de espaço no sistema de arquivo, são detectadas por rotinas de gerenciamento dos sistemas de arquivos antes do drive de disco receber a requisição.

Se ocorre um erro do meio, por exemplo, o disco apresenta um setor danificado, então, o erro será reportado de volta a aplicação durante a próxima chamada similar ou durante uma rotina close( ) do arquivo contendo um bloco com defeito. Quando o drive perceber que um erro ocorreu e que foi retornado a controladora do disco, ele imprime uma mensagem de falha do meio na console.

Um mecanismo similar é utilizado para reportar erros no meio virtual do servidor de arquivos remotos. Quando uma rotina write( ) é chamada sobre um arquivo montado via NFS, os dados do buffer e o offset do arquivo são tratados por rotinas de escrita do NFS, do mesmo modo que a escrita em um sistema de arquivo UNIX chama a rotina de escrita do drive de disco de mais baixo nível. Como o driver do dipositivo de disco, o NFS possui uma rotina de driver para escalonar requisições de escrita: cada nova requisição é colocada no buffer local ou na página de cache. Quando um buffer está completo ou a página tem sido escrita, a requisição é tratada pelo daemon biod, que executa a chamada RPC para o servidor remoto e retorna o código resultante.

Ocasionalmente, um daemon biod pode detectar um erro quando tentar escrever no servidor remoto, o erro é então, impresso na console do cliente. O formato desta mensagem de erro é por exemplo:

Na tabela abaixo temos uma relação dos erro relacionados ao NFS e os respectivos números de erros:

Os erros "Permission Denied" e "No Space" serão detectados no sistema de arquivo local, mas o cliente NFS não tem meios de determinar se uma operação de escrita obteve sucesso em algum tempo futuro.

Uma vez que várias falhas de escrita tem ocorrido devido a sistemas de arquivos cheios ou problemas de permissão, o superusuário pode ocasionar um down no usuário ou processo que está executando as escritas, através da identificação do arquivo que está sendo escrito. O utilitário showfh correlaciona os handles dos arquivos impressos pelo biod com o caminho completo do arquivo no servidor remoto. Por exemplo:

Onde 2 7 b 2 6 f f 7 é o handle do arquivo reportado na mensagem de erro.

Para evitar retardos dos clientes devido a problemas como escrita, devemos ter uma idéia clara das atividades dos clientes e do quanto estão sobrecarregados os servidores. Devemos também determinar a carga que o NFS impõe a rede e otimizar os clientes e servidores para que possam fazer melhor uso dos recursos disponíveis. Para tanto uma análise de performance deve ser realizada assim como descrito no item 4.

1. Hal Stern - Managing NFS and NIS - O’Reilly & Associates, Inc. - 1991.
1. Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein - UNIX System Administration Handbook - Prentice Hall PTR - 1995.