Por dentro do CORBA File System for Linux

O serviço de nomes é um serviço especificado no CORBA, e disponibilizado pela maioria das implementações. A hierarquia dos nomes é bastante parecida com a hierarquia de sistemas de arquivos do Unix. Os nomes podem ser associados a contextos (análogo a diretórios) ou a objetos (análogo a arquivos). A estrutura forma uma árvore, inicada por uma raiz (no caso do serviço de nomes, um contexto inicial é inicializado com um nome dado pela linha de comando).
O servidor CFS registar um objeto no espaço de nomes, e é através dele que todas as operações para aquele diretório, e todos os que estiverem abaixo dele, serão executadas. Outras operações podem ocorrem dentro do espaço de nomes. Maiores detalhes poderão ser encontrados na seção Navegação no espaço de nomes.

Cada servente é então colocado no espaço de nomes na sua posição correspondente de exportação, em que os nomes do caminho são procurados como contextos. Se não houver na árvore os contextos necessários para o caminho dos objetos Superblock alocados, então o servidor se encarregará de criá-los.

Para a recepção de requisições aos serventes dos objetos, o servidor, após a configuração, criação dos objetos e registro dos mesmos no serviço de nomes, inicia o POA, através do ORB. A partir daí, todas as operações são realizadas pelos métodos públicos disponíveis nos objetos que representam os arquivos e diretórios em disco, exportados para o espaço de nomes. O servidor só termina quando solicitado pelos sinais TERM, KILL, ou ABORT. Os objetos são retirados do serviço de nomes, no caso de uma finalização correta do servidor.

O cliente é um daemon que realiza a comunicação do módulo com o servidor CORBA.

O funcionamento básico do cliente é verificar (polling) algum dos dispositivos criados pelo módulo cfs (no diretório /dev, o módulo cria o diretório cfs e cinco dispositivos nele, de 0 a 4, utilizando-se o sistema de dispositivos devfs) e tratar as requisições pedidas (upcalls) e enviar as respostas recebidas (downcalls). A comunicação entre o espaço de usuário e de núcleo é feita portanto atravaés de dispositivos de caracteres.

Entre a requisição e a resposta, o cliente acessa o espaço de nomes em busca do caminho pedido, e tenta pegar uma referência para um objeto Superblock.
Se for possível encontrar um objeto desse tipo, ele realiza a operação pedida em cima dele, e a operação é realizada no servidor que disponibilizou o objeto. Se não, temos um objeto qualquer, ou um contexto no espaço de nomes.

No caso de ser um contexto, ele cria um ContextSB, que é uma implementação da interface Superblock, e realiza a operação pedida de forma um pouco diferente da que conhecemos quando acessamos um sistema de arquivos real: ele realiza as operações de um diretório, mas no espaço de nomes. Pode-se criar novos diretórios (que serão novos contextos), listar o conteúdo de um contexto, e até criar arquivos. No caso da criação de arquivos, um objeto da classe VirtualSB é criado, que funciona como um arquivo, mas na memória do daemon local. Esse objeto pode responder a acessos remotos, de outros clientes, se o ORB no cliente estiver executando e aceitando requisições.

Os objetos VirtualSB também são criados para representar objetos no espaço de nomes que não implementam a interface Superblock. Nesse caso, o objeto apenas responde a leituras, com a IOR do objeto encapsulado.

O módulo tem a responsabilidade de interpretar os pedidos feitos pelo sistema operacional para o sistema de arquivos.
Através do módulo é que o sistema de arquivos é acessado de forma transparente pelos usuários do sistema operacional.

O módulo trata os pedidos realizados pelo sistema operacional e os coloca numa fila. Essa fila tem seus elementos removidos e tratados pelo daemon, que os lê através de um dispositivo especial, instalado no /dev/cfs/0 (podem haver até 5 dispositivos: 0, 1, 2, 3, 4 e 5).

O módulo também lê desse dispositivo, a fim de obter as respostas retornadas dos pedidos. Cada resposta é colocada numa outra fila, que é lida pelo próprio módulo para dar uma resposta à chamada de sistema que estiver aguardando.

Chamadas de sistema implementadas

Os processos dos usuários realizam chamadas de sistema no kernel que são retransmitidas ao módulo do CFS. De todas as chamadas existentes no VFS que poderiam ser implementadas, foram implementadas somente as mais importantes, que seguem.

1. STATFS: Mostra estatísticas do sistema de arquivos.
2. READDIR: Obtem a listagem dos inodes que compõe o diretório.
3. READPAGE: Lê uma página de um arquivo. A página é especificada por um offset.
4. COMMIT_WRITE: Escreve uma página em um arquivo. A página é especificada por um offset.
5. MKNOD: Cria um inode.
6. SYMLINK: Cria uma ligação simbólica.
7. UNLINK: Remove a ligação simbólica.
8. RENAME: Altera o nome de um inode.
9. READLINK: Lê os dados de uma ligação simbólica.
10. SETATTR: Altera os atributos de um inode.

A representação da hierarquia de diretórios do CFS é feita usando-se contextos do espaço de nomes e diretórios dos sistemas de arquivos remotos exportados.

Dessa forma é possível acessar tanto os diretórios reais do sistema de arquivos remoto (acessando através do caminho informado pelo segundo argumento do arquivo cfs.exports) como os vários contextos que estiverem registrados no espaço de nomes. Isso é possível devido à duas implementações da interface Superblock: uma para os objetos dos servidores do lado do sistema de arquivos exportados, e outra para o daemon local.

Assim, com os comandos comuns do Unix, como ls, cd, cat, mkdir, etc, podemos navegar pelo espaço de nomes CORBA, criar e remover contextos, e até imprimir a IOR de objetos que não estejam representando arquivos ou diretórios exportados por servidores CFS.

Autores:

• Livio Baldini Soares
• Márcio Rodrigo de Freitas Carneiro
• Roberto Pires de Carvalho

Last modified: Thu Jun 6 00:31:45 EST 2002