Geraldo Braz Junior

Unix: Sistema de Arquivos

Arquivos Um arquivo é visto pelo SO apenas

como uma seqüência de bytes: nenhuma distinção é feita entre arquivos ASCII, binários, etc.;

Muitos programas esperam que nomes de arquivo sejam constituídos por um nome básico seguido de um ponto e uma extensão;

A extensão informa o tipo do arquivo;

Um arquivo pode ter várias extensões: prog.java.Z;

As extensões não são exigidas pelo SO.2

Diretórios Arquivos podem ser agrupados em

diretórios;

O sistema de arquivos é hierárquico e o diretório raiz é chamado /;

Caminho absoluto e relativo (diretório de trabalho);

Quando um diretório é criado duas entradas são inseridas automaticamente: . e ..

3

Diretórios Importantes

4

Ligação(link) de Arquivos e Diretórios

5

Referência a Múltiplos Discos

Uma solução é usar um sistema de arquivos independente em cada um devendo o usuário especificar tanto o dispositivo quando o arquivo quando necessário:

Exemplo: cp a:/x /a/d/x

Estratégia adotada pelo MS-DOS, Windows e VMS;

Outra solução é permitir que um disco seja montado em uma árvore de arquivos de outro disco (adotado pelo Unix).

6

Referência a Múltiplos Discos

7

Impedimento (locking)

A utilização de um arquivo por dois ou mais processos pode gerar situações de disputa;

Uma solução é programar a aplicação com regiões críticas;

É possível associar um semáforo a cada diretório ou arquivo e implementar a exclusão mútua;

No entanto, o arquivo ou diretório todo fica impedido, mesmo que somente um arquivo deva ser acessado;

8

Impedimento (locking) POSIX oferece um mecanismo flexível e de

granularidade fina;

O programador deve especificar o arquivo, byte inicial e o número de bytes seguintes que ficarão impedidos de serem acessados por outros processos;

Tipos de impedimento: Compartilhado

Exclusivo

9

Impedimento (locking)

10

(a) Arquivo com um lock

(b) Adição de um segundo lock

(c) Um terceiro lock

Chamadas ao SistemaGerenciamento de Arquivos

11

• s : código de erro

• fd : descritor do arquivo

• position : offset no arquivo

Chamada stat

12

Campos retornados pela chamada stat

Chamadas ao SistemaGerenciamento de Diretórios

13

• s : código de erro

• dir : identificador do diretório

• dirent : uma entrada no diretório

ImplementaçãoEsquema do Disco

14

Esquema de uma partição de disco no Unix clássico

ImplementaçãoEsquema do Disco

Bloco 0 (boot): não utilizado pelo Unix

Bloco 1 (superbloco): Nº de i-nodes

Nº de blocos do disco

Ponteiro para lista de blocos livres

I-nodes Possui 64 bytes

Cada i-node descreve um arquivo

Blocos de dados Armazenam arquivos e diretórios

15

Estrutura do i-node

16

Estrutura de um i-node no System V

Diretórios e Abertura de Arquivos

O diretório consiste em um conjunto desordenado de entradas de 16 bytes: Nome do arquivo: 14 caracteres

Nº do i-node do arquivo

Abrindo arquivos: No diretório corrente

Utilizando um caminho absoluto: /usr/ast/file (i-node 2 aponta para o diretório raíz. O i-node 0 é utilizado para tratamento de blocos danificados)

I-node de arquivos abertos são mantidos na tabela de i-nodes do kernel.17

Leitura de Arquivon = read(fd, buffer, nbytes)

Dado o descritor de arquivos o sistema deve localizar o i-node correspondente;

Cada processo possui sua tabela de descritores de arquivos abertos;

Como vimos anteriormente, quando um processo abre o arquivo, o Unix inclui seu i-node na tabela de i-nodes do kernel;

A solução parece simples...

18

Leitura de Arquivo Onde deve ser mantido o ponteiro para

próxima leitura/escrita no arquivo?1. Na tabela de i-nodes

• Se dois ou mais processos não relacionados abrirem o arquivo eles devem ter ponteiros independentes

2. Na tabela de descritores• Problemas com o compartilhamento de

arquivos: considere um shell script constituído de 2 comandos p1 e p2, executados em ordem e que o script foi executado assim: s>x

Solução: tabela de descrição de arquivos abertos

19

Leitura de Arquivo

20

Sistema de Arquivos de Berkeley O limite do nome de arquivos passou a ser

de 255 caracteres; As chamadas opendir, closedir, readdir e rewinddir foram introduzidas;

Cache de nome: agiliza a localização de entradas em diretórios;

Divisão do disco em grupos de cilindros, cada um com seu próprio suberbloco, i-nodes e blocos de dados;

A idéia é manter próximos os blocos de dados e o i-node de um arquivo a fim de evitar longos posicionamentos.

21

Sistema de Arquivos de Berkeley Introdução de dois tamanhos de bloco:

Para armazenar arquivos grandes é mais eficiente ter um número pequeno de blocos grandes;

Por outro lado, muitos arquivos do Unix são pequenos e blocos grandes gerariam desperdício de espaço.

22

Sistema de Arquivos de Berkeley

23

• Um diretório BSD com três arquivos

• O mesmo diretório depois da remoção do arquivo voluminous

NFS: Sistema de Arquivos de Rede

Desenvolvido pela Sun Microsystems;

Permite que um conjunto de clientes e servidores compartilhe um sistema de arquivo comum;

Cada servidor exporta um ou mais diretórios para serem acessados pelos clientes remotos;

A lista de diretórios exportados é mantida em /etc/exports;

Cada máquina pode ser cliente e servidor ao mesmo tempo.

24

NFS: Sistema de Arquivos de Rede

25

Protocolos NFS Dois protocolos são utilizados:

1. Para a montagem de diretórios

2. Para o acesso a arquivos e diretórios

26

NFS: Protocolo de Montagem Cliente envia um nome de caminho para

um servidor solicitando permissão para montar o diretório localmente;

O local da montagem não é fornecido; Se o caminho for válido, o servidor retorna

um controle de arquivo (file handler) contendo:◦ Tipo do sistema de arquivos;◦ Disco;◦ Número do i-node do diretório;◦ Informações de segurança.

O controle de arquivo deve ser utilizado nas requisições de acesso a arquivos e diretórios.

27

NFS: Protocolo de Acesso Clientes podem enviar mensagens para

manipular diretórios, ler e escrever em arquivos;

Muitas chamadas do Unix são suportadas, menos open e close;

Não é necessário abrir ou fechar arquivos: ◦ Operação lookup retorna um controle para o

arquivo. Essa operação não copia qualquer informação para tabelas internas do servidor;

◦ O controle do arquivo contêm o identificador do arquivo e o número do i-node;

◦ A chamada read contêm o controle do arquivo, o deslocamento e número de bytes desejados;

◦ O servidor, portanto, não armazena estado !

28

NFS: Protocolo de Acesso Como o servidor não armazena estado, seu

processo de recuperação em caso de falha é simplificado;

No entanto, o NFS requer um mecanismo adicional para tratar impedimentos (locking).

29

Implementação do NFS Dividido em três camadas:

1. A camada superior trata as chamadas ao sistema (open, read, close, etc.);

2. A segunda camada (VFS – Virtual File System) mantêm uma tabela com uma entrada para cada arquivo aberto denomida v-node (i-node virtual);

3. A terceira camada é responsável pelo acesso ao arquivo ou diretório.

30

Implementação do NFS

31

V-nodes Informam se o arquivo é local ou remoto;

Para arquivos locais, são registrados o sistema de arquivos e o i-node;

Para arquivos remotos, o v-node aponta para um r-node (i-node remoto);

O r-node possui as informações que permitem o acesso remoto ao arquivo.

32

Implementação do NFSEficiência Transferências entre o servidor e o cliente

são feitas em grandes blocos (8192 bytes) mesmo que poucos bytes sejam requisitados;

Leitura antecipada: geração automática de requisição para leitura do próximo bloco;

Transferências de escrita também devem possuir pelo menos 8KB;

Escritas menores são acumuladas localmente (ou até que o arquivo seja fechado);

São utilizadas caches tanto no servidor quanto no cliente.

33

Implementação do NFS Consistência da Cache Cleinte

Associado a cada bloco da cache existe um temporizador. Quando ele expira, a entrada é descartada;

Para arquivos: 3s; para diretórios: 30s;

Sempre que um arquivo operado na cache é aberto, uma mensagem é enviada ao servidor para descobrir quando o arquivo foi alterado pela última vez;

A cada 30s todos os blocos sujos (modificados) são enviados para o servidor.

34

Segurança no Unix Cada usuário possui um UID;

Usuários são organizados em grupos. Cada grupo possui um GID;

Um usuário pode pertencer a vários grupos;

Arquivos são marcados com o UID e GID de seu proprietário;

Cada processo carrega o UID e GID do seu proprietário (do usuário que solicitou a execução programa).

35

Segurança no Unix Cada arquivo possui também um conjunto

de permissões relativas ao proprietário, grupo do proprietário e restante dos usuários em chaves de 3 bits: rwx.

36

Segurança no Unix Diretórios também possuem chave de

proteção sendo que o x se refere à permissão de busca em vez de execução;

A chave rwxr-xr-w permite apenas leitura e busca de arquivos pelos outros usuários, impedindo-os de adicionar ou remover arquivos do diretório.

37

Segurança no Unix O usuário com UID=0 é chamado de

superusuário ou root;

O root tem o poder de ler e escrever em todos os arquivos do sistema, independentemente de sua chave de proteção;

Processos com UID=0 também podem executar um pequeno número de chamadas ao sistema protegidas;

Arquivos especiais também utilizam chave de proteção.

38

Segurança no Unix O arquivo /dev/lp poderia ser de

propriedade do root ou de um usuário especial (daemon) e ter modo de proteção rw------- para impedir que qualquer um pudesse imprimir;

De forma semelhante, o /etc/passwd não deve ser liberado para escrita;

Então, como usuários comuns podem imprimir ou alterar sua senha?

39

Segurança no Unix Utiliza-se um bit a mais de proteção: o

SETUID;

Quando um programa que tem o bit SETUID ativado é executado, o UID efetivo para aquele processo se torna o UID do proprietário do arquivo executável em vez do UID do usuário que o invocou.

40

Segurança no UnixChamadas ao Sistema

41

As três últimas chamadas são permitidas apenas para o root

Segurança no Unix

Quando um usuário entra no sistema, o login (que tem SETUID de root) solicita o nome de uma conta e uma senha;

Se a conta e senha estão corretas, o login executa um shell utilizando setuid e setgid para definir o proprietário e grupo

corretos.

42