O projeto base é o TecnicoFS (Técnico File System), um sistema de ficheiros simplificado em modo utilizador. É implementado como uma biblioteca, que pode ser usada por qualquer processo cliente que pretenda ter uma instância privada de um sistema de ficheiros no qual pode manter os seus dados.
O TecnicoFS oferece uma interface de programação (API) inspirada na API de sistema de ficheiros POSIX. No entanto, para simplificar o projeto, a API do TecnicoFS oferece apenas um subconjunto de funções com interface simplificada:
int tfs_open(char const *name, int flags);int tfs_close(int fhandle);ssize_t tfs_write(int fhandle, void const *buffer, size_t len);ssize_t tfs_read(int fhandle, void *buffer, size_t len);
(Nota: o tipo de dados ssize_t é definido no standard POSIX para representar tamanhos em bytes, podendo também ter o valor -1 para representar erro.
É, por exemplo, o tipo do retorno das funções read e write da API de sistema de ficheiros POSIX.)
Além destas funções, existem as funções de inicialização e destruição do sistema de ficheiros, tfs_init e tfs_destroy.
O código fonte do TecnicoFS encontra-se disponível neste repositório. A descrição detalhada de cada função pode ser encontrada na documentação no código fonte do TecnicoFS.
Tal como em FS tradicionais modernos, o conteúdo do FS encontra-se referenciado numa estrutura de dados principal chamada tabela de i-nodes, global ao FS. Cada i-node representa uma diretoria ou um ficheiro no TecnicoFS, que tem um identificador único chamado i-number. O i-number de uma diretoria/ficheiro corresponde ao índice do i-node correspondente na tabela de i-nodes. O i-node consiste numa estrutura de dados que descreve os atributos da diretoria/ficheiro (aquilo que normalmente se chamam os seus metadados) e que referencia o conteúdo da diretoria/ficheiro (ou seja, os dados).
Além da tabela de i-nodes, existe uma região de dados, organizada em blocos de tamanho fixo. Esta região mantém os dados de todos os ficheiros do FS, sendo esses dados referenciados a partir do i-node de cada ficheiro (na tabela de i-nodes). No caso de ficheiros normais, é na região de dados que é mantido o conteúdo do ficheiro (por exemplo, a sequência de caracteres que compõem um ficheiro de texto). No caso de diretorias, a região de dados mantém a respetiva tabela, que representa o conjunto de ficheiros (ficheiros normais e subdiretorias) que existem nessa diretoria.
Para facilitar a alocação e libertação de i-nodes e blocos, existe um vetor de alocação associado à tabela de i-nodes e à região de dados, respetivamente.
Além das estruturas de dados mencionadas acima, que mantêm o estado durável do sistema de ficheiros, o TecnicoFS mantém uma tabela de ficheiros abertos. Essencialmente, esta tabela conhece os ficheiros atualmente abertos pelo processo cliente do TecnicoFS e, para cada ficheiro aberto, indica onde está o cursor atual. A tabela de ficheiros abertos é descartada quando o sistema é desligado ou termina abruptamente (ou seja, não é durável).
Nas aulas teóricas da 2ª semana, o código base será apresentado e discutido. Recomendamos a todos os estudantes que frequentem essas aulas antes de começarem a desenvolver a solução.
Além de uma API simplificada, o desenho e implementação do TecnicoFS adotam algumas simplificações fundamentais, que sumarizamos de seguida:
- Em vez de uma árvore de diretorias, o TecnicoFS tem apenas uma diretoria (a raiz "/"), dentro da qual podem existir ficheiros (e.g., "/f1", "/f2", etc.) mas não outras subdiretorias. O texto entre aspas nos exemplos anteriores é chamado o caminho de acesso ao ficheiro.
- O conteúdo dos ficheiros e da diretoria raiz é limitado a um bloco (cuja dimensão é determinada em tempo de compilação e que é configurada para 1KB, por omissão). Como consequência, o i-node respetivo tem um campo simples que indica qual o índice desse bloco.
- Assume-se que existe um único processo cliente, que é o único que pode aceder ao sistema de ficheiros. Consequentemente, existe apenas uma tabela de ficheiros abertos e não há permissões nem controlo de acesso.
- A implementação das funções assume que estas são chamadas por um cliente sequencial, ou seja, a implementação pode resultar em erros caso uma ou mais funções sejam chamadas concorrentemente por duas ou mais tarefas (threads) do processo cliente. Por outras palavras, não é thread-safe.
- As estruturas de dados que, em teoria, deveriam ser duráveis, não são mantidas em memória secundária. Quando o TecnicoFS é terminado, o conteúdo destas estruturas de dados é perdido.
No 1º exercício pretende-se estender a versão base do TecnicoFS com as funcionalidades que são descritas de seguida.
Pretende-se que seja oferecida e implementada uma nova função:
int tfs_copy_from_external_fs(char const *source_path, char const *dest_path);
Esta função copia o conteúdo de um ficheiro source_path existente no sistema de ficheiros do sistema operativo no qual o TecnicoFs corre, para o ficheiro destPath guardado no TecnicoFS.
Por outras palavras, importa o conteúdo de um ficheiro do sistema de ficheiros nativo para dentro do TecnicoFS (limitado à dimensão de 1 bloco).
Devolve 0 em caso de sucesso, -1 em caso de erro.
Caso o ficheiro identificado por dest_path não exista, este deve ser criado.
Caso contrário, o conteúdo prévio do ficheiro já existente deve ser totalmente substituído pelo novo conteúdo.
Além de implementar esta funcionalidade no TecnicoFS, cada grupo deve desenvolver também pelo menos um programa de teste que demonstre e verifique a correção da solução proposta.
Pretende-se permitir a criação e apagamento de nomes alternativos (hard links) e atalhos (soft links) para ficheiros. Ambos os tipos de links permitem criar ligações alternativas (i.e., pontos de acessos alternativos) para ficheiros pré-existentes no sistemas de ficheiros. Contudo, estes dois tipos de links têm semânticas diferentes, tal como ilustrado de seguida.
Nomes alternativos. Ao criar um hard link "/path_A/hard_link" para um ficheiro "/path_B/file_name", é acrescentada uma entrada na lista do diretório "/path_A" cujo nome é "hard_link" e que aponta para o i-node associado ao ficheiro "/path_B/file_name".
Nesse i-node é também incrementado o contador de hard links.
Um ficheiro é efetivamente apagado só quando o contador de hard links do relativo i-node atinge o valor 0.
Nota: este contador é inicializado com o valor 1 ao criar o ficheiro no sistema de ficheiro (o que corresponde, na prática, à criação de um hard link para o ficheiro).
Atalhos. Ao criar um soft link "/path_A/soft_link" para um ficheiro "/path_B/file_name", é acrescentada uma entrada na lista do diretório "/path_A" cujo nome é "soft_link" e cujo conteúdo é "/path_B/file_name". A diferença de um hard link para um soft link é que este último não aponta para o i-node associado ao ficheiro "/path_B/file_name", mas armazena apenas uma referência para o nome do ficheiro para o qual esse link aponta. Consequentemente, caso o ficheiro "/path_B/file_name" venha a ser apagado após a criação de um soft link para ele, esse ficheiro ("/path_B/file_name") é imediatamente apagado do sistema de ficheiros e, portanto, as aplicações que tentem usar esse soft link irão incorrer em erros.
Para a criação de hard/soft link deverão ser implementadas as seguintes funções:
int tfs_link(char const *target_file, char const *source_file) // cria um hard link
int tfs_sym_link(char const *target_file, char const *source_file) // cria um soft link
Pretende-se também implementar uma função que permite apagar ficheiros e links:
int tfs_unlink(char const *target)
Simplificações/observações:
- Podem ser criados hard links apenas para ficheiros (ou diretorias), e nunca para soft links;
- Os soft links guardam a referência para o target no bloco de dados.
Cada grupo deverá também desenvolver pelo menos um programa de teste que demonstre e verifique a correção da solução proposta para cada função.
É desejável eliminar a restrição do programa cliente ser single thread, permitindo que seja constituído por múltiplas tarefas concorrentes (criadas por pthread_create). Pretende-se rever a implementação das funções do TecnicoFS para as tornar corretas quando executadas concorrentemente (i.e., thread-safe).
Para cumprir este requisito, devem ser usados trincos lógicos (pthread_mutex) ou trincos de leitura-escrita (pthread_rwlock), ficando a sua escolha ao critério dos estudantes.
A solução deve maximizar o paralelismo, recorrendo a sincronização fina. Uma solução baseada em trincos que colocam em exclusão mútua a totalidade ou grande parte das estruturas de dados do TecnicoFS será fortemente penalizada na avaliação.
Caso sintam que a interface de funções que gerem o estado do TecnicoFS (definida em fs/state.h) não é a mais apropriada para resolver este requisito, podem adaptar essa interface para uma alternativa mais apropriada.
Recomendamos que, antes de começarem a implementar, discutam o desenho da vossa solução com o docente de laboratório.
Além da adaptação do TecnicoFS para o tornar thread-safe, cada grupo deve compor uma bateria de, pelo menos, três programas cliente paralelos.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent