Por que o servidor Linux NFS é implementado no kernel e não no espaço do usuário?


33

Eu só estava me perguntando por que o servidor NFS Linux é implementado no kernel, em oposição a um aplicativo de espaço do usuário?

Sei que existe um daemon NFS no espaço do usuário , mas não é o método padrão para fornecer serviços de servidor NFS.

Eu pensaria que a execução do servidor NFS como um aplicativo de espaço de usuário seria a abordagem preferida, pois pode fornecer segurança adicional com um daemon executado no espaço de usuário em vez do kernel. Também se encaixaria no princípio comum do Linux de fazer uma coisa e fazê-lo bem (e que daemons não deveriam ser um trabalho para o kernel).
De fato, o único benefício que consigo pensar em executar no kernel seria um aumento no desempenho da alternância de contexto (e esse é um motivo discutível).

Portanto, existe algum motivo documentado para que seja implementado do jeito que é? Tentei pesquisar no Google, mas não consegui encontrar nada.


Parece haver muita confusão, observe que não estou perguntando sobre a montagem de sistemas de arquivos, mas sobre o fornecimento do lado do servidor de um sistema de arquivos de rede . Há uma diferença muito distinta. A montagem de um sistema de arquivos localmente requer suporte para o sistema de arquivos no kernel, desde que não seja necessário (por exemplo, samba ou unfs3).


NFS é um sistema de arquivos. Os drivers do sistema de arquivos do espaço do usuário precisam usar o FUSE, que normalmente é ruim para o desempenho.
Jordanm

@ Jordanm não, eles não. Na verdade, você não pode executar sistemas de arquivos de rede (NFS, CIFS / samba, coda, etc.) via FUSE. O FUSE destina-se à montagem de sistemas de arquivos na máquina local, não à sua manutenção.
Patrick

você está certo, minha declaração se aplicaria apenas ao cliente.
Jordanm

@ Jordanm nem isso, infelizmente. Você pode montar sistemas de arquivos sem o FUSE. De qualquer maneira, o FUSE é uma tecnologia relativamente nova; o lado do cliente dos sistemas de arquivos da rede existia muito antes do FUSE :-). FUSE apenas fornece uma maneira de sistemas de arquivos de apoio não fornecidos pelo kernel (não tentando ser média, apenas esperando para esclarecer equívocos :-P)
Patrick

2
@ StarNamer você ainda está falando sobre o cliente. Eu estou falando sobre o servidor. Você pode executar unfs3(que é um servidor NFS) sem qualquer suporte ao kernel.
Patrick

Respostas:


25

unfs3está morto, tanto quanto eu sei; Ganesha é o projeto do servidor NFS com mais espaço para usuário no momento, embora não esteja completamente maduro.

Embora atenda a diferentes protocolos, o Samba é um exemplo de um servidor de arquivos bem-sucedido que opera no espaço do usuário.

Não vi uma comparação recente de desempenho.

Algumas outras questões:

  • Aplicativos comuns procuram arquivos por nome de caminho, mas nfsdprecisam ser capazes de procurá-los por tratamento de arquivos . Isso é complicado e requer suporte do sistema de arquivos (e nem todos os sistemas de arquivos podem suportá-lo). No passado, não era possível fazer isso no espaço do usuário, mas os kernels mais recentes adicionavam name_to_handle_at(2)e open_by_handle_at(2)chamavam o sistema.
  • Lembro-me de que o bloqueio de chamadas de bloqueio de arquivos é um problema; Não tenho certeza de como os servidores do espaço do usuário os lidam atualmente. (Você amarra um encadeamento do servidor aguardando o bloqueio ou faz pesquisa?)
  • A semântica mais recente do sistema de arquivos (alterar atributos, delegações, compartilhar bloqueios) pode ser implementada mais facilmente primeiro no kernel (em teoria - eles ainda não foram).
  • Você não precisa checar permissões, cotas, etc. manualmente - em vez disso, deseja alterar seu uid e confiar no código vfs comum do kernel para fazer isso. E o Linux tem uma chamada de sistema ( setfsuid(2)) que deve fazer isso. Por razões que esqueço, acho que ficou mais complicado usar nos servidores do que deveria ser.

Em geral, os pontos fortes de um servidor kernel são a integração mais próxima com os vfs e o sistema de arquivos exportado. Podemos compensar isso fornecendo mais interfaces do kernel (como as chamadas do sistema de tratamento de arquivos), mas isso não é fácil. Por outro lado, algumas pessoas do sistema de arquivos desejam exportar atualmente (como o gluster) na verdade vivem principalmente no espaço do usuário. Eles podem ser exportados pelo kernel nfsd usando o FUSE - mas novamente extensões para as interfaces do FUSE podem ser necessárias para os recursos mais recentes, e pode haver problemas de desempenho.

Versão curta: boa pergunta!


2
Os leitores devem observar que Bruce é (um? O?) Mantenedor do servidor NFS Linux, então, presumivelmente, ele sabe do que está falando. :)
Dan Pritts

@derfian FYI - você pode comentar aqui dizendo que " unfs3está vivo e se muda para o Github" ?
Ms-ati

Eu comentei o acima porque o @derfian, ou usuário StackOverflow ( unix.stackexchange.com/users/23034/derfian ), é o mantenedor do unfs3 e recentemente anunciou que não estava morto, por exemplo neste comentário do Github
ms-ati

Para escrita por um mantenedor do NFS, essa resposta é bastante vaga.
Torsten Bronger

18

Olaf Kirch originalmente desenvolveu o espaço do usuário e a versão baseada em kernel do servidor NFS. Em seu livro do ano 2000, "Linux Network Administration", ele diz:

O kernel 2.2.0 suporta um servidor NFS experimental baseado em kernel, desenvolvido por Olaf Kirch e posteriormente desenvolvido por HJ Lu, G. Allan Morris e Trond Myklebust. O suporte NFS baseado em kernel fornece um aumento significativo no desempenho do servidor.

Acho que depois que o servidor NFS foi transferido para o kernel para melhorar o desempenho, ninguém viu razão para retirá-lo novamente.


8

Starnamer está correto (eu fui um dos beta testers).

Colocá-lo no kernel foi uma tentativa de melhorar o desempenho abismal (principalmente para clientes PCNFS) e, uma vez resolvido esse problema, ninguém olhou para ele novamente.

Há uma série de deficiências em ter o NFS no kernel, entre os quais o de que ele não funciona muito bem com qualquer outra coisa tocando o mesmo sistema de arquivos (existem riscos de corrupção seriamente desagradáveis), mas naquela época (1993-4), não perceber que isso acabaria sendo um problema.

Éramos mais jovens e mais tolos, etc etc.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.