Gerenciamento de arquivos - Inferno

O Inferno adota uma interface unificada para os sistemas de arquivos, na qual todas as solicitações ao sistema de arquivos são transmitidas por meio de um protocolo chamado Styx.

Papel dos servidores de arquivos.

Todos os serviços relacionados a sistema de arquivos no Inferno são fornecidos por servidores de arquivos, que assumem duas formas.

• Integrado no kernel
• Implementado como programa de aplicação normal

Quer sejam executados como parte do kernel, quer como aplicações independentes, todos os servidores de arquivos aceitam solicitações de processos clientes e fornecem resultados a eles da mesma maneira. Essa interface comum é fornecida pelo protocolo Styx. Além disso, isso acontece se o processo que originou a solicitação está em execução na máquina local ou em outra máquina conectada por rede.

Os servidores de arquivos fornecem seu próprio espaço de nomes na forma de uma pequena arvore de diretório. Usando as chamadas ao sistema bind() e mount(), os processos podem montar vários espaços de nomes fornecidos por uma variedade de servidores em um espaço de nomes completo. Embora a maioria dos processos trabalhe dentro do espaço de nomes que herdaram dos seus pais, eles são livres para construir seu próprio espaço de nomes independente de qualquer outro.

O Protocolo Styx.

O Styx é um protocolo usado entre servidores de arquivos e clientes. É usado universalmente, não importa se o cliente e o servidor residem na mesma máquina ou em máquinas diferentes. Exemplos de mensagens Styx:

• Tcreate/Rcreate: Cria um arquivo
• Tread/Rread: Lê um arquivo
• Twrite/Rwrite: Grava em um arquivo

Em cada um desses pares, a mensagem T é uma solicitação enviada do cliente para o servidor, e a mensagem R é a resposta do servidor após concluir a solicitação.

O servidor de dispositivo raiz.

O primeiro servidor de arquivos que examinaremos é o da raiz “device”. Os arquivos atendidos por esse servidor formam a arvore de diretório no qual todos os outros espaços de nomes são montados e delimitados. É a única parte do espaço de nomes do processo que não é conectada por meio das chamadas mount() ou bind(), pelo próprio processo ou por um de seus ancestrais.

Cada servidor de arquivos integrado ao kernel tem uma entrada em uma tabela de dispositivo (servidores integrados fornecem suporte para acesso e controle de dispositivos.) As primeiras duas entradas são descritivas.

1. Caractere que é usado para identificar esse servidor de arquivos.
2. Uma string de identificação do servidor.

Normalmente, a memória que contém os dados para uma gravação ou a memória onde os dados são postos em uma leitura, já está alocada, e um ponteiro lhe é dado para a função que implementa a leitura ou gravação.(O servidor de arquivos raiz tem sua própria implementação de gerador de diretório.)

Tratador genérico de mensagens Styx.

Temos uma quantidade significativa de código que, de outra forma, seria repetida em diversos servidores de arquivos. Ao reunir, os servidores podem apontar para essas funções nas estruturas Dev simplificando o código para eles.

• Criação de entrada de diretorio
  devdir(): ela constrói de forma eficaz uma entrada de diretório para um arquivo nomeado no terceiro argumento. Essa função determina todos os membros de uma estrutura de entrada de diretório.
• Geração de nomes
  Parecido com um caso de gerador que vimos para o servidor de arquivos raiz, em especial, ele gera uma entrada de diretório para a entrada da tabela com índice i.
• Caminhada pela arvore de diretório
  O remetente da mensagem já precisa ter interpretado o nome do caminho em componentes, que recebemos em name . Se bem-sucedido, queremos retornar um conjunto de Ids, um para cada diretório no caminho e um para o arquivo ou diretório no fim da busca.
  Após configurar o conjunto de resultados, fazemos um loop para cada um dos nomes em name. Para cada um deles, buscamos o diretório relevante. Se o nome existir, vamos para ele e, se for um diretório, continuamos buscando com o próximo nome no caminho

Sistema de arquivos do Inferno nativo.

O sistema de arquivos é conhecido como kfs, “sistema de arquivos do Ken”.No geral, o kfs é estruturado como dois (três se ativarmos a bufferização do bloco de disco) processos e cooperação.

• Um desses processos é uma thread única que leva as mensagens Styx e as processa usando dados do disco.
• O outro processo é uma interface de controle e gerenciamento(fornece arquivos onde podemos iniciar as verificações do sistema de arquivos, desligar o servidor e executar outras operações similares).

Cria-se um novo sistema de arquivos executando o kfs com uma opção de linha de comando que inicializa as estruturas de dados no disco antes de começar sua atividade normal no servidor de arquivos. No Inferno, a criação de um sistema de arquivos é chamada reaming.

No disco, o primeiro bloco, chamado superbloco, contém os metadados que descrevem o sistema de arquivos como um todo. Os blocos de arquivos são gerenciados usando uma alocação hibrida estruturada em lista e uma alocação estruturada em árvore de modo muito similar aos sistemas de arquivos do UNIX.
Porém o Inferno espera que todo os metadados do arquivo estejam em sua entrada de diretório. Isso leva à estrutura de diretório do kfs em que todos os metadados do arquivo são mantidos em sua entrada de diretório em disco. Assim, não existem nós-i, como encontrados nos sistemas de arquivos do UNIX.

Resumo.

O Inferno se destaca como exemplo de sistema operacional que usa a distinção entre gerenciamento de espaço de nomes e de espaço de armazenamento.
Os servidores de arquivos que gerenciam espaços de nomes pequenos fornecem acesso a vários serviços tradicionais de SO, incluindo drivers de dispositivos. Visto que todos os servidores usam o protocolo Styx, eles podem ser acessados na mesma máquina do cliente ou em uma máquina diferente.
O protocolo Styx também possibilita que os servidores sejam incorporados ao kernel ou implementados como processos regulares do usuário.
O sistema de arquivos de armazenamento persistente convencional que examinamos aqui, é um exemplo de servidor de arquivos implementado como processo normal de usuário.

								© UEPG 2019. Ponta Grossa - PR