Por que o servidor Linux NFS é implementado no kernel em oposição ao userspace?

Question

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

Eu sei que existe um daemon NFS userspace , mas não é o método padrão para fornecer serviços de servidor NFS.

Eu acho que rodar o servidor NFS como um aplicativo de espaço de usuário seria a abordagem preferida, já que ele pode fornecer segurança adicional tendo um daemon rodando no espaço do usuário ao invés do kernel. Ele também se encaixaria com o princípio comum do Linux de fazer uma coisa e fazer isso bem (e que os daemons não deveriam ser um trabalho para o kernel). Na verdade, o único benefício que posso pensar em rodar no kernel seria um aumento no desempenho da troca de contexto (e essa é uma razão discutível).

Então, há alguma razão documentada para que seja implementada da maneira como é? Eu tentei googling mas não consegui encontrar nada.

Parece haver muita confusão, por favor, note que não estou perguntando sobre a montagem de sistemas de arquivos, estou perguntando sobre o fornecimento do lado do servidor de um sistema de arquivos de rede . Existe uma diferença muito distinta. Montar um sistema de arquivos localmente requer suporte para o sistema de arquivos no kernel, desde que não (por exemplo, samba ou unfs3).     

Answer 1

unfs3 está morto até onde eu sei; Ganesha é o projeto de servidor NFS do espaço de usuário mais ativo no momento, embora não esteja completamente maduro.

Embora sirva protocolos diferentes, o Samba é um exemplo de sucesso servidor de arquivos que opera no espaço do usuário.

Eu não vi uma comparação recente de desempenho.

Algumas outras questões:

• Aplicativos comuns procuram arquivos por nome de caminho, mas nfsd precisa ser capaz de procure-os pelo filehandle. 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 a partir do userspace, mas kernels mais recentes adicionaram name_to_handle_at(2) e open_by_handle_at(2) chamadas do sistema.
• Parece que me lembro de bloquear o bloqueio de chamadas de arquivos sendo um problema; Não tenho certeza como os servidores do userspace lidam com eles hoje em dia. (Você amarra um thread de servidor esperando na fechadura, ou você pesquisa?)
• Semântica do sistema de arquivos mais recente (alterar atributos, delegações, compartilhar bloqueios) pode ser implementado mais facilmente no kernel primeiro (em teoria - eles ainda não foram ainda).
• Você não precisa ter que verificar permissões, cotas, etc., manualmente; você quer mudar o seu uid e confiar no código vfs do kernel comum para fazer naquela. E o Linux tem uma chamada de sistema ( setfsuid(2) ) que deveria fazer isso. Para razões que eu esqueci, acho que isso se mostrou mais complicado de usar em servidores do que deveria ser.

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

Versão curta: boa pergunta!

    

Answer 2

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

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

Eu acho que uma vez que o servidor NFS foi movido para o kernel para melhorar o desempenho, ninguém viu nenhum motivo para removê-lo novamente.

    

Answer 3

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

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

Há uma série de deficiências em ter o NFS no kernel, e não menos importante que ele não funcione bem com qualquer outra coisa que toque o mesmo sistema de arquivos (há sérios riscos de corrupção), mas na época (1993-4). ) não percebemos que isso se tornaria um problema.

Nós éramos mais jovens e mais tolos, etc etc.