O cliente do sistema de arquivos distribuídos terá uma arquitetura mais complicada do que a do servidor. Nossa intenção nesse projeto é deixar a comunicação com o servidor CORBA transparente às aplicações do sistema. Para atingir essa transparência, com um desempenho aceitável, a maneira mais adequada é inserir um novo sistema de arquivos dentro do sistema operacional utilizado. Dessa forma as aplicações poderão continuar usando as chamadas ao sistema sem ter ``ciência'' de que estão acessando arquivos remotos.
A fim de atingir essa transparência para as aplicações, o cliente do sistema de arquivos distribuídos será dividido em duas partes: um módulo para o núcleo do Linux, e um cliente CORBA.
O módulo do nosso sistema cliente tem como função disponibilizar um sistema de arquivos para ser montado localmente. Além de registrar o sistema de arquivos (utilizando a chamada register_filesystem do VFS), esse módulo deve disponibilizar ao núcleo todas as operações que um sistema de arquivos precisa implementar (via a estrutura super_block do VFS). Na realidade, a priori, os membros do super_block deveriam ser ponteiros para funções que acessam o servidor CORBA remoto. Essa solução não foi adotada e explicaremos o porquê na próxima seção.
A solução que achamos mais apropriada é fazer com que o módulo do núcleo converse com um cliente CORBA local, via um dispositivo virtual. As funções do super_block na verdade serão então envólucros para escritas ao dispositivo virtual que serão lidas pelo cliente. Assim o cliente CORBA local é um processo em espaço de usuário, externo ao núcleo, que tem a função de se comunicar com o servidor de arquivos CORBA remoto, e servidor de nomes CORBA. Após o recebimento das mensagens do servidor de arquivos, o cliente deve repassar tudo ao módulo do núcleo, que por sua vez disponibiliza à aplicação que estaria requisitando as informações/alterações sobre os arquivos ou diretórios em questão.
A figura 2 graficamente demonstra a estrutura básica que será implementada no cliente do sistema.
