IME-USP. MAC Sistemas de Objetos Distribuídos

(1)

IME-USP

Instituto de Matem´ atica e Estat´ıstica da Universidade de S˜ ao Paulo

Proposta de Projeto – Sistemas de Arquivos no Linux

MAC5759 - Sistemas de Objetos Distribu´ıdos

S˜ ao Paulo, 11 de junho de 2002

M ´arcio Rodrigo de Freitas Carneiro Livio Baldini Soares

Roberto Pires de Carvalho

(2)

1 Introdu¸ c˜ ao

Esse documento visa esbo¸ car o projeto final de MAC 5759 – Sistemas de Objetos Distribu´ıdos. O projeto ser´ a um sistema de arquivos distri- bu´ ıdos para o sistema operacional Linux, cujos servidores ser˜ ao implementados em CORBA.

Na segunda se¸ c˜ ao ser´ a delineado a arquitetu- ra b´ asica que se pretende utilizar para a imple- menta¸ c˜ ao, na terceira se¸ c˜ ao busca-se uma justi- ficativa para a arquitetura adotada juntamente com as dificuldades t´ ecnicas e conceituais encon- tradas, de forma a melhor esclarecer os detalhes da arquitetura. Na quarta se¸ c˜ ao ´ e feito uma bre- ve introdu¸ c˜ ao ao Virtual File System (VFS) do Linux

¹

. Finalmente, na quinta se¸ c˜ ao, descreve-se os objetos utilizados no sistema, juntamente com uma breve descri¸ c˜ ao de suas interfaces (i.e. seus m´ etodos).

2 Arquitetura utilizada

A arquitetura b´ asica ser´ a dividida em duas par- tes, para facilitar a especifica¸ c˜ ao: a parte servi- dora e a parte cliente.

2.1 Arquitetura do Servidor

O servidor do sistema de arquivos distribu´ıdos a ser implementado se baseia essencialmente em CORBA. ´ E esperado que os clientes realizem to- da a comunica¸c˜ ao com o servidor via chamadas remotas do CORBA. Al´ em disso iremos estrutu- rar a hierarquia do sistema de arquivos (i.e. di- ret´ orios e nomes) via um servidor de nomes COR- BA.

A princ´ıpio, apenas quatro classes de objetos ser˜ ao necess´ arias para representar as entidades correspondentes aos objetos do VFS. Entretan- to, precisamos apresentar o VFS para depois es- pecificar os objetos e interfaces necess´ arias. Isso

´

e feito posteriormente, nas se¸ c˜ oes 5 e 6. Apesar

1A palavraLinuxé muitas vezes usada nesse texto com o sentido de “núcleo do Linux”, embora isso não seja ex- plic´ıto, o leitor deve fazer a distin¸cão quando cab´ıvel.

disso achamos que a arquitetura geral do siste- ma pode ser descrita aqui sem esses detalhes, que ser˜ ao apresentados depois.

O uso de um servidor de nomes CORBA pro- porciona uma grande flexibilidade, j´ a que po- demos designar arquivos e diret´ orios diferentes a servidores de arquivos distintos, com trans- parˆ encia ao cliente, o que ´ e incomum nos sis- temas de arquivos distribu´ıdos comumente utili- zados no Linux, como o NFS, em que ´ e necess´ ario especificar o servidor e diret´ orio externo a ser im- portado. Al´ em de n˜ ao haver transparˆ encia, esse tipo de montagem ´ e est´ atica e tem que ser ma- nualmente reconfigurada quando o servidor ou di- ret´ orio mudam.

O servidor de arquivos respons´ avel por certos diret´ orios ou arquivos ser´ a executado como um processo na mesma m´ aquina em que est˜ ao esses arquivos e diret´ orios. Esses arquivos locais po- der˜ ao estar formatados em qualquer tipo de sis- tema de arquivos j´ a que o processo servidor de arquivos far´ a chamadas ao sistema simples como open, close, read, write, flush, etc. Um es- bo¸ co do diagrama da arquitetura do servidor de arquivos pode ser visto na figura 1.

Figura 1: Diagrama da arquitetura do servidor

(3)

Numa perspectiva puramente t´ ecnica, o servi- dor de arquivos nada mais ´ e do que um env´ olucro (wrapper ) para as chamadas ao sistema local que manipulam os arquivos e diret´ orios acess´ıveis lo- calmente

²

.

Apesar de ser um modelo simplista para o servi- dor, acredita-se que ser´ a poss´ıvel agregar algumas outras funcionalidades, como autentica¸ c˜ ao do cli- ente, criptografia de dados, compress˜ ao de dados, entre outros. Nenhum desses servi¸ cos existem atualmente para o not´ orio sistema de arquivos distribu´ıdos, o NFS. Ainda n˜ ao est´ a estruturada a forma como ser´ a disponibilizado esses servi¸ cos, mas um dos interesses desse projeto ´ e permitir ao desenvolvedor inserir novas funcionalidades ao sistema de arquivos distribu´ıdos de forma f´ acil, mesmo que n˜ ao seja uma funcionalidade projeta- da de antem˜ ao. Por isso parece que a op¸ c˜ ao mais adequada ser´ a o uso de interceptadores CORBA, por´ em isso ainda est´ a em estudo.

2.2 Arquitetura do Cliente

O cliente do sistema de arquivos distribu´ıdos ter´ a uma arquitetura mais complicada do que a do servidor. Nossa inten¸ c˜ ao nesse projeto ´ e deixar a comunica¸c˜ ao com o servidor CORBA transpa- rente ` as aplica¸ c˜ oes do sistema. Para atingir essa transparˆ encia, com um desempenho aceit´ avel, a maneira mais adequada ´ e inserir um novo sistema de arquivos dentro do sistema operacional uti- lizado. Dessa forma as aplica¸ c˜ oes poder˜ ao con- tinuar usando as chamadas ao sistema sem ter

“ciˆ encia” de que est˜ ao acessando arquivos remo- tos.

A fim de atingir essa transparˆ encia para as apli- ca¸c˜ oes, o cliente do sistema de arquivos distri- bu´ıdos ser´ a dividido em duas partes: um m´ odulo para o n´ ucleo do Linux, e um cliente CORBA.

O m´ odulo do nosso sistema cliente tem co- mo fun¸ c˜ ao disponibilizar um sistema de arqui-

2Nada impede, entretanto, que o sistema de arquivos sendo acessado pelo servidor de arquivos não seja local de fato. Esse fato será transparente ao processo, bastando que o núcleo disponibilize os arquivos desejados.

vos para ser montado localmente. Al´ em de regis- trar o sistema de arquivos (utilizando a chamada register filesystem do VFS), esse m´ odulo de- ve disponibilizar ao n´ ucleo todas as opera¸ c˜ oes 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¸ c˜ oes que acessam o servidor CORBA remoto. Essa solu¸ c˜ ao n˜ ao foi adotada e explicaremos o porquˆ e na pr´ oxima se¸ c˜ ao.

A solu¸ c˜ ao que achamos mais apropriada ´ e fa- zer com que o m´ odulo do n´ ucleo converse com um cliente CORBA local, via um dispositivo virtual. As fun¸ c˜ oes do super block na verdade ser˜ ao ent˜ ao env´ olucros para escritas ao disposi- tivo virtual que ser˜ ao lidas pelo cliente. Assim o cliente CORBA local ´ e um processo em espa¸ co de usu´ ario, externo ao n´ ucleo, que tem a fun¸ c˜ ao de se comunicar com o servidor de arquivos CORBA remoto, e servidor de nomes CORBA. Ap´ os o re- cebimento das mensagens do servidor de arquivos, o cliente deve repassar tudo ao m´ odulo do n´ ucleo, que por sua vez disponibiliza ` a aplica¸ c˜ ao que esta- ria requisitando as informa¸ c˜ oes/altera¸ c˜ oes sobre os arquivos ou diret´ orios em quest˜ ao.

A figura 2 graficamente demonstra a estrutura b´ asica que ser´ a implementada no cliente do siste- ma.

3 Dificuldades no Cliente

Ao projetar o cliente do sistema encontrou-se uma dificuldade, cuja solu¸ c˜ ao resultou na arquite- tura adotada. O principal problema encontrado foi descobrir como realizar a comunica¸ c˜ ao entre o m´ odulo (ou n´ ucleo em si) e o servidor COR- BA externo. Duas op¸ c˜ oes foram cogitadas para solucionar o problema:

1. Inclus˜ ao de um ORB dentro do n´ ucleo do

Linux. Essa solu¸ c˜ ao, de fato, resolveria o

nosso problema j´ a que o m´ odulo teria um

stub e ORB pr´ oprio e a comunica¸ c˜ ao entre

o cliente e servidor CORBA seria bastante

eficiente.

(4)

Figura 2: Diagrama da arquitetura do cliente 2. ORB cliente como processo “externo”, em es-

pa¸co de usu´ ario. Essa solu¸ c˜ ao ´ e um pouco mais complexa, pois exige mais uma camada separando o m´ odulo/n´ ucleo e o servidor de arquivos. Al´ em do mais, pode acarretar em alguma degrada¸c˜ ao de desempenho.

Apesar da op¸ c˜ ao (1) parecer ser mais simples e mais eficiente infelizmente a solu¸ c˜ ao adotada foi a da op¸c˜ ao (2). As raz˜ oes para n˜ ao adotar a solu¸ c˜ ao (1) s˜ ao basicamente trˆ es. Primeiramente haveria a necessidade de integra¸ c˜ ao de um ORB no n´ ucleo do Linux. Procurou-se um ORB est´ avel e peque- no para o n´ ucleo do Linux e o ´ unico encontrado foi kORBit

³

que aparentemente n˜ ao est´ a est´ avel e cujo desenvolvimento est´ a atualmente parado.

Al´ em disso o m´ odulo a ser desenvolvido n˜ ao fun- cionaria em qualquer n´ ucleo do Linux, apenas naqueles com o patch incluindo esse ORB. Em segundo lugar os ORBs vistos consomem muita mem´ oria, o que ´ e extremamente indesej´ avel para

3http://korbit.sourceforge.net/

inser¸ c˜ ao dentro do n´ ucleo de um sistema operaci- onal. Por fim o tempo h´ abil e energia necess´ aria para viabilizar a integra¸ c˜ ao de algum ORB exis- tente (ou cria¸ c˜ ao de novo) no n´ ucleo do Linux, seria demais para esse projeto.

Com isso, foi decidido utilizar a alternativa (2). Essa alternativa tamb´ em trouxe outro pro- blema que ´ e o de se fazer um upcall, isto ´ e, o n´ ucleo fazer uma chamada a uma fun¸ c˜ ao de um processo em espa¸ co de usu´ ario. O upcall

´ e uma opera¸ c˜ ao atualmente n˜ ao permitida pe- los n´ ucleos padr˜ oes do Linux. Existe um pat- ch que fornece essa funcionalidade, desenvolvi- da por Alessandro Rubini

⁴

, que pode ser vis- ta em: http://www.linux-mag.com/2000-11/- gear 01.html. Entretanto essa nova funciona- lidade exigiria, novamente, muitas mudan¸ cas ao n´ ucleo padr˜ ao do Linux, e tomaria muito tempo e energia.

Uma maneira que se pensou para “simular” os upcalls seria o uso de chamadas RPCs locais pa- ra o processo cliente. Para esse projeto, quase decidiu-se implementar uma solu¸ c˜ ao usando cha- madas RPCs. Era de se esperar que essas chama- das n˜ ao ocasionam muito custo adicional, j´ a que todas as chamadas deveriam ser chamadas locais (na mesma m´ aquina), entretanto n˜ ao se tem co- mo comprovar essas suposi¸ c˜ oes at´ e experimentar- se uma implementa¸ c˜ ao. Outro problema ´ e que a complexidade do c´ odigo deve aumentar, pois se- ria necess´ ario criar mais uma interface e utilizar mais outro protocolo de comunica¸ c˜ ao.

Outra solu¸ c˜ ao para a falta de upcalls no n´ ucleo do Linux, ´ e a solu¸ c˜ ao adotada pelo projeto Coda FS

⁵

, sistema de arquivos distribu´ıdos desenvolvi- do pelo universidade CMU. No Coda FS o proces- so cliente rodando comunica-se com o m´ odulo do n´ ucleo atrav´ es de uma entrada no /dev/. O pro- cesso cliente ´ e um gerenciador de cache (Venus) que se comunica com o servidor (Vice) utilizan- do RPC. O gerenciador escreve o arquivo em um sistema de arquivos local e notifica o m´ odulo no-

4Um dos autores do Linux Device Drivers, dispon´ıvel emhttp://www.oreilly.com/catalog/linuxdrive2/

5http://www.coda.cs.cmu.edu/

(5)

vamente via o dispositivo virtual. Assim o n´ ucleo pode manipular o arquivo com opera¸ c˜ oes em um sistema de arquivos local (como o ext2 ).

Apesar da arquitetura do Coda FS ser extre- mamente avan¸cada, permitindo tolerˆ ancia a fa- lhas e realiza¸ c˜ ao de opera¸ c˜ oes desconectadas, ela n˜ ao ser´ a usada. A desvantagem nesse caso ´ e a dificuldade de implementa¸ c˜ ao de um gerenciador de cache utilizando o disco como meio de tro- ca de informa¸ c˜ oes com o n´ ucleo. Outro grande empecilho ´ e a dificuldade em manter os arquivos consistentes no servidor e entre os cliente; essa opera¸ c˜ ao torna-se mais complicada com o uso de caches locais.

Por fim, ao pesquisar o Parallel Virtual File Sys- tem

⁶

(PVFS), cuja arquitetura foi fortemente ba- seada na do Coda FS, achou-se que essa seria a arquitetura ideal de comunica¸ c˜ ao entre o m´ odulo do n´ ucleo e o cliente local. A comunica¸ c˜ ao usa- da no PVFS entre o m´ odulo e o cliente local (no caso do PVFS ´ e um daemon ao inv´ es de um ge- renciador de cache como ´ e o do Coda FS) ´ e bem parecida com a do Coda FS, s´ o que n˜ ao ´ e feito o uso de algum sistema de arquivos local.

Basicamente, os upcalls s˜ ao implementados uti- lizando o dispositivo virtual /dev/pvfsd. O dae- mon, chamado pvfsd, lˆ e as requisi¸ c˜ oes desse dis- positivo, e quando elas s˜ ao satisfeitas, escreve uma resposta no mesmo dispositivo. O m´ odulo do kernel ent˜ ao, utiliza fun¸ c˜ oes do n´ ucleo como copy from user e copy to user para transferir os dados dos arquivos sendo manipulados entre o n´ ucleo e o cliente local.

4 Virtual File System Layer

O VFS

⁷

´ e uma camada abstrata existente em diversos n´ ucleos Unix que pretende fornecer uma interface bem definida para implementa¸ c˜ ao de sis- temas de arquivos. A interface do VFS ´ e estru- turada em cima de tipos de objetos gen´ ericos, e

6http://parlweb.parl.clemson.edu/pvfs/

7Muitas vezes essa camada do VFS ´e chamada deVno- de

uma s´ erie de m´ etodos que s˜ ao chamados a partir desses objetos.

Dessa maneira ´ e mais f´ acil implementar um sis- tema de arquivos para esses Unices, bastando for- necer uma implementa¸ c˜ ao para os m´ etodos dos objetos do VFS para a cria¸ c˜ ao de um sistema de arquivos novo. Os objetos b´ asicos conhecidos pe- lo VFS s˜ ao: arquivos, sistemas de arquivos, ino- des, e nomes de inodes. Cada um desses objetos possuem um conjunto de m´ etodos especificados nas estruturas super operations (para o siste- ma de arquivos), file operations (para arqui- vos), inode operations para inodes, e dentry - operations para nomes dos arquivos.

A seguir s˜ ao apresentados os m´ etodos ne- cess´ arios para implementar um sistema de ar- quivos usando o VFS do Linux. Note que nem todos esses m´ etodos precisam ser implementados necessariamente, o Linux fornece alguns m´ etodos gen´ ericos para uso geral. As estruturas foram re- tirados da vers˜ ao 2.4.19-pre2 do n´ ucleo do Linux, mas n˜ ao devem apresentar muitas diferen¸ cas en- tre vers˜ oes. Os argumentos dos m´ etodos foram removidos para deix´ a-los mais simples e claros.

Esses m´ etodos s˜ ao extremamente importantes pa- ra podermos definir objetos e interfaces CORBA consistentes com as necessidades do VFS.

struct super_operations { void (*read_inode) ();

void (*dirty_inode) ();

void (*write_inode) ();

void (*put_inode) ();

void (*delete_inode) ();

void (*put_super) ();

void (*write_super) ();

void (*write_super_lockfs) ();

void (*unlockfs) ();

int (*statfs) ();

int (*remount_fs) ();

void (*clear_inode) ();

void (*umount_begin) ();

};

struct file_operations { struct module *owner;

loff_t (*llseek) ();

ssize_t (*read) ();

ssize_t (*write) ();

int (*readdir) ();

(6)

unsigned int (*poll) ();

int (*ioctl) ();

int (*mmap) ();

int (*open) ();

int (*flush) ();

int (*release) ();

int (*fsync) ();

int (*fasync) ();

int (*lock) ();

ssize_t (*readv) ();

ssize_t (*writev) ();

ssize_t (*sendpage) ();

};

struct inode_operations { int (*create) ();

struct dentry * (*lookup) ();

int (*link) ();

int (*unlink) ();

int (*symlink) ();

int (*mkdir) ();

int (*rmdir) ();

int (*mknod) ();

int (*rename) ();

int (*readlink) ();

int (*follow_link) ();

void (*truncate) ();

int (*permission) ();

int (*revalidate) ();

int (*setattr) ();

int (*getattr) ();

};

struct dentry_operations { int (*d_revalidate) ();

int (*d_hash) ();

int (*d_compare) ();

int (*d_delete) ();

void (*d_release) ();

void (*d_iput) ();

};

5 Objetos do sistema

Com o estudo preliminar do VFS, fica intuitivo definir os objetos e interfaces que devem ser pro- jetados nesse sistema. Projetou-se quatro objetos que correspondem, justamente, ` as quatro entida- des do VFS: sistema de arquivo, arquivo, inode e dentry.

As interfaces desses objetos devem correspon- der ` as opera¸ c˜ oes especificadas para cada uma des-

sas entidades do VFS, descritas na se¸ c˜ ao quatro.

Dessa forma deve existir um mapeamento um a um entre as opera¸ c˜ oes do VFS, implementadas no m´ odulo do n´ ucleo, e os m´ etodos dos objetos no servidor de arquivos. As interfaces n˜ ao ser˜ ao explicitadas aqui, j´ a que dever˜ ao ser an´ alogas ` as opera¸ c˜ oes listadas anteriormente.

A intera¸ c˜ ao entre o cliente e esses objetos no servidor se dar´ a basicamente via o servidor de nomes. Cada servidor que deseja exportar um diret´ orio tem que registrar o seu objeto corres- pondente ao super block no servidor de nomes.

Assim, os clientes CORBA pegar˜ ao uma IOR no servidor de nomes para o objeto super block de um servidor de arquivos. Com esse objeto, o cli- ente poder´ a pegar os outros objetos, como um objeto inode, ou dentry.