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

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.

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!

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.

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.