Sistemas de arquivos

Um arquivo é uma sequência persistente de bytes. O sistema de arquivos armazena esses bytes sem decidir se representam texto, imagem ou código de máquina. Um diretório dá ao arquivo um nome legível; seu número de nó-i o identifica dentro do sistema de arquivos.

Abra um arquivo e verifique o resultado

open(path, flags, mode) retorna um descritor de arquivo, um número inteiro não negativo usado em chamadas posteriores. Um erro retorna -1 e define errno. Escolha O_RDONLY, O_WRONLY ou O_RDWR para o acesso. O_CREAT cria um arquivo inexistente, O_TRUNC esvazia um arquivo existente e O_APPEND coloca cada escrita no fim atual.

Para um novo arquivo, mode solicita permissões e a umask do processo remove bits. Sem uma lista de controle de acesso (ACL) padrão no diretório, o resultado é mode & ~umask. Solicitar 0666 com umask 0022 resulta em 0644, ou rw-r--r--. Esse argumento não altera as permissões de um arquivo já existente.

Descritores pertencem a um processo. Normalmente 0, 1 e 2 são entrada, saída e erro padrão. open escolhe o menor descritor não utilizado, frequentemente 3. No Linux, strace cat notes.txt mostra as chamadas: abrir a entrada, lê-la, escrever no descritor 1 e depois fechar a entrada.

Acompanhe o deslocamento, não a quantidade solicitada

read(fd, buf, n) retorna os bytes realmente lidos, até n. Para uma solicitação diferente de zero em um arquivo comum, zero significa que não restam bytes no fim do arquivo ou além dele; -1 indica um erro. write também retorna uma quantidade efetiva, que pode ser menor que a solicitada. Verifique essa quantidade antes de avançar em um buffer ou decidir que a operação está concluída.

Suponha que log.txt contenha 300 bytes. Quatro solicitações de 100 bytes retornam 100, 100, 100 e 0. O deslocamento, a posição da próxima operação, passa a ser 100, 200, 300 e 300. O fim do arquivo é uma quantidade retornada, não um byte especial armazenado no arquivo.

lseek(fd, 200, SEEK_SET) define o deslocamento como 200. Ler 50 bytes em seguida retorna os bytes 200 a 249 e deixa o deslocamento em 250. SEEK_CUR mede a partir do deslocamento atual; SEEK_END mede a partir do fim do arquivo. Alterar a posição muda um número na memória. Isso não move uma cabeça de disco nem lê dados por si só. pread e pwrite usam uma posição explícita sem alterar esse deslocamento.

Determine quais descritores compartilham um deslocamento

A tabela de descritores do processo aponta para entradas na tabela de arquivos abertos do núcleo. Cada entrada de arquivo aberto contém o modo de acesso, o deslocamento, a referência ao nó-i e a contagem de referências.

Se um filho posicionar um descritor compartilhado no byte 10, a próxima leitura do pai por essa entrada também começará em 10. O nó-i identifica o arquivo, mas a entrada de arquivo aberto contém o deslocamento: dois leitores podem compartilhar um arquivo sem compartilhar sua posição. O redirecionamento do interpretador de comandos usa dup2 para fazer a saída padrão se referir a outra entrada de arquivo aberto. close libera um descritor; a entrada desaparece depois que sua última referência é liberada. Fechar, por si só, não força os dados em buffer para armazenamento estável.

Uma escrita bem-sucedida e uma atualização resistente a falhas respondem a perguntas diferentes. Uma escrita informa que os bytes foram aceitos. A durabilidade diz respeito a eles sobreviverem a uma falha; a atomicidade diz respeito a uma atualização poder ser observada apenas por inteiro.

Force os bytes para armazenamento estável

Sistemas operacionais geralmente mantêm escritas em buffer na memória e enviam blocos modificados ao armazenamento mais tarde, frequentemente em cerca de 5 a 30 segundos. Isso combina escritas pequenas e permite que o programa continue rapidamente. Uma falha pode apagar dados que ainda aguardam nesses buffers.

fsync(fd) força os dados e metadados modificados do arquivo para o armazenamento e espera o dispositivo informar a conclusão. Um programa deve verificar seu resultado antes de informar que o salvamento é durável. close libera o descritor e não substitui essa espera.

Um arquivo também precisa de um nome durável. A entrada que associa o nome ao nó-i é um dado pertencente ao seu diretório, não ao arquivo. Após criar um arquivo, sincronizar apenas o arquivo pode tornar seus bytes duráveis sem garantir que seu novo nome sobreviva. Abra o diretório que o contém e sincronize-o quando o nome precisar persistir.

Substitua um arquivo sem expor uma versão parcial

Sobrescrever um documento no próprio local cria um intervalo em que leitores podem encontrar conteúdo incompleto. O_TRUNC primeiro define seu tamanho como zero. Se uma falha interromper as escritas posteriores, a cópia antiga completa já terá desaparecido.

Em vez disso, escreva o conteúdo substituto sob um nome temporário no mesmo diretório. Depois use rename para substituir o destino. Para um destino existente no mesmo sistema de arquivos, o POSIX torna essa substituição atômica: o nome de destino se refere ao arquivo antigo ou ao substituto, sem um intervalo em que o nome esteja ausente. Leitores não veem uma mistura de seus conteúdos por esse nome.

Para settings.json, a sequência de substituição durável é:

1. Escreva todo o novo conteúdo em settings.json.tmp, verificando escritas parciais e erros.
2. Chame fsync no arquivo temporário e verifique se foi bem-sucedido.
3. Chame rename("settings.json.tmp", "settings.json") e verifique se foi bem-sucedido.
4. Chame fsync no diretório que o contém e verifique se foi bem-sucedido.

O arquivo temporário está completo e durável antes de o nome mudar. A sincronização final do diretório torna essa alteração de nome durável. Uma falha durante a sequência deixa o destino com uma versão antiga completa ou uma versão nova completa; após a última sincronização bem-sucedida, a nova versão é a durável. A substituição atômica do nome, por si só, não garante que uma renomeação não sincronizada sobreviva a uma queda de energia.

rename entre sistemas de arquivos falha com EXDEV. Um comando que responde copiando e excluindo executa várias operações, então essa alternativa não tem garantia de substituição atômica.

Altere o tamanho sem escrever cada byte

truncate(path, length) e ftruncate(fd, length) definem o tamanho do arquivo. Reduzi-lo descarta os bytes além do novo fim. Estendê-lo faz com que a nova região seja lida como zeros. Posicionar-se além do fim e depois escrever também cria uma lacuna lida como zeros.

Um arquivo esparso pode representar essa lacuna sem alocar blocos de dados para ela. Começando com um arquivo vazio, escrever um byte no deslocamento 8192 cria um arquivo de 8193 bytes; a região anterior não escrita é lida como zeros. Seu tamanho lógico pode exceder o espaço fisicamente alocado a ele.

Diretórios separam os nomes usados pelas pessoas dos objetos armazenados pelo sistema de arquivos. Cada diretório tem seu próprio nó-i e blocos de dados; suas entradas associam nomes a números de nós-i.

Siga caminhos pela árvore

Um caminho absoluto começa em /. Um caminho relativo começa no diretório de trabalho atual do processo. A entrada . nomeia o próprio diretório e .. nomeia seu diretório pai; o pai da raiz é a própria raiz. A partir de /home/lee, o caminho relativo ../shared chega a /home/shared.

Uma extensão como .txt faz parte de um nome. Programas podem usá-la para escolher como interpretar os bytes, mas o sistema de arquivos não exige que um arquivo .txt contenha texto.

mkdir cria um diretório que contém . e ... Para listar entradas, um programa usa opendir, chama readdir até não restarem entradas e chama closedir. Um resultado de readdir inclui um nome e um número de nó-i. Programas alteram o conteúdo de diretórios por chamadas como link, unlink e rename, não por chamadas comuns a write. rmdir remove um diretório vazio.

Dê a um arquivo dois nomes equivalentes

link(old, new) cria uma ligação física: outra entrada de diretório que aponta para o mesmo nó-i. Nenhum dos nomes tem privilégio de original. A contagem de ligações do nó-i registra quantos nomes se referem a ele.

Considere estes comandos quando nenhum processo mantém o arquivo aberto:

echo hi > a
ln a b
rm a
cat b
rm b

Criar b aumenta a contagem de ligações de 1 para 2. Remover a a reduz para 1; b ainda acessa os mesmos bytes, então cat b imprime “hi”. Remover b reduz a contagem a 0, permitindo que o nó-i e seus blocos sejam recuperados.

Um descritor aberto acrescenta uma segunda regra de tempo de vida. Se a última ligação for removida enquanto um processo ainda mantém o arquivo aberto, esse processo poderá continuar acessando-o. A recuperação do espaço aguarda tanto a ausência de ligações quanto o fim das referências abertas. Isso explica por que excluir um registro grande aberto pode não liberar seu espaço imediatamente.

Uma ligação física não pode atravessar sistemas de arquivos: o número de nó-i do destino não teria significado na outra tabela de nós-i. A maioria dos sistemas Unix também proíbe ligações físicas para diretórios para preservar uma árvore sem ciclos. Na contagem clássica de diretórios Unix, um diretório vazio tem duas ligações, de sua entrada no diretório pai e de seu próprio .. Cada subdiretório contribui com mais uma por meio de ..; três subdiretórios resultam em uma contagem de 5.

Armazene um caminho em uma ligação simbólica

Uma ligação simbólica é um arquivo separado cujo conteúdo é um caminho de destino. ln -s /home/ana/report.txt r cria r com o caminho de destino de 20 bytes como conteúdo. Segui-la resolve esse caminho. Ligações simbólicas podem atravessar sistemas de arquivos e apontar para diretórios.

Uma ligação simbólica não aumenta a contagem de ligações de seu destino. Manter o objeto de ligação, portanto, não mantém o destino existente.

O conteúdo de um arquivo é apenas parte de seu estado. Os metadados registram quem pode usá-lo, seu tamanho e tipo e quando ele foi alterado. A montagem torna objetos de vários sistemas de arquivos acessíveis por uma única árvore de nomes.

Leia os metadados corretamente

stat(path, &buf) lê metadados por meio de um caminho; fstat(fd, &buf) os lê por meio de um descritor aberto. Os resultados incluem o número do nó-i, tipo, permissões, identificadores do proprietário e do grupo, tamanho, blocos alocados e contagem de ligações. O tamanho do arquivo conta os bytes lógicos; os blocos alocados medem o armazenamento realmente usado, que pode ser menor para um arquivo esparso.

Três registros de horário descrevem eventos diferentes:

ctime não é o horário de criação. Atualizar apenas atime não altera ctime. O stat do Unix clássico não tem campo de horário de criação; o statx do Linux pode disponibilizar um horário de nascimento registrado quando o sistema de arquivos oferece suporte a ele.

Interprete os bits de permissão

Os direitos de leitura, escrita e execução são registrados separadamente para proprietário, grupo e demais usuários. Cada classe é um dígito octal: leitura vale 4, escrita 2 e execução 1. Para rw-r-----, o proprietário recebe 4 + 2 = 6, o grupo recebe 4 e os demais recebem 0. chmod 640 report.txt define esses bits.

As permissões de diretório aplicam-se a nomes e à travessia. Leitura permite listar nomes. Execução permite busca, isto é, o uso do diretório em um caminho. Escrita junto com execução permite criar, excluir e renomear entradas. Conhecer um nome pode bastar para abrir um arquivo em um diretório com permissão de execução, mas sem permissão de leitura, desde que as próprias permissões do arquivo permitam o acesso. Listar esse diretório continua falhando.

Essa diferença importa para a exclusão: remover uma entrada altera o diretório que a contém. O bit de escrita de um arquivo controla a alteração de seus bytes; ele não é a permissão do diretório para remover seu nome. Root ignora a maioria das verificações comuns de permissão. Listas de controle de acesso (ACLs) podem conceder direitos a usuários e grupos identificados além das três classes básicas.

Associe outro sistema de arquivos

mkfs inicializa um sistema de arquivos em uma partição ou outro dispositivo, incluindo seu próprio diretório raiz e metadados. Ele destrói o conteúdo anterior do sistema de arquivos no dispositivo, então execute-o apenas em um dispositivo destinado à inicialização.

mount associa essa raiz a um diretório existente chamado ponto de montagem. Uma unidade montada em /media/usb torna acessível ali o conteúdo de sua raiz. O conteúdo anterior de /media/usb fica oculto enquanto a montagem está ativa; a montagem não o mescla com a árvore montada. Executar mount sem argumentos lista as montagens atuais.

A camada de sistema de arquivos virtual (VFS) do núcleo fornece uma interface comum a sistemas de arquivos ext4, XFS, FAT, baseados em memória e em rede. Programas podem chamar open e read por meio de qualquer um deles. O espaço de nomes combinado não combina suas tabelas de nós-i: números de nós-i iguais em sistemas de arquivos diferentes podem identificar arquivos sem relação entre si. Portanto, ligações físicas e renomeações atômicas permanecem dentro de seus respectivos sistemas de arquivos.

Um sistema de arquivos precisa registrar onde ficam os bytes e qual espaço está disponível. Uma organização simples no estilo Unix torna essas funções visíveis ao separar registros de alocação, nós-i e conteúdos.

Divida a partição em regiões

Um bloco é a unidade básica de alocação do sistema de arquivos. Um bloco de 4 KiB contém 4096 bytes, ou oito setores tradicionais de 512 bytes. Tamanhos binários usam KiB, MiB e GiB; taxas de transferência como MB/s usam milhões decimais de bytes por segundo.

O projeto didático vsfs, o sistema de arquivos muito simples, contém estas estruturas:

Um bit 1 no mapa significa alocado; 0 significa livre. O superbloco informa ao sistema operacional como interpretar o restante da partição ao montá-la. Os dois mapas de bits descrevem recursos diferentes: um arquivo pode ter um nó-i alocado antes de ter qualquer bloco de dados.

Localize um nó-i pelo número

Considere uma partição de 64 blocos com blocos de 4 KiB. Coloque o superbloco no bloco 0, o mapa de bits de nós-i no 1, o mapa de bits de dados no 2 e a tabela de nós-i nos blocos 3 a 7. Os dados ocupam os blocos 8 a 63. Cinco blocos da tabela de nós-i com nós-i de 256 bytes contêm 80 nós-i, pois cada bloco contém 16. Há 56 blocos de dados. Um mapa de bits de 4 KiB pode descrever 32.768 objetos, então grande parte de cada mapa fica sem uso nessa pequena organização.

Numerando as posições de nós-i a partir de zero, o nó-i 37 começa 37 × 256 = 9.472 bytes após o início da tabela. A tabela começa no byte 12.288, resultando no endereço absoluto de byte 21.760. Dividir por 4.096 resulta no bloco de disco 5 com resto 1.280. Dividir por 512 resulta no setor 42 com resto 256. Leia o bloco ou setor que o contém e depois selecione os bytes do nó-i dentro dele.

O método geral é: início da tabela em bytes mais o número do nó-i multiplicado por seu tamanho. Mantenha o endereço inicial da tabela separado do deslocamento do nó-i dentro dela. Omitir esse endereço base leva ao bloco de disco errado.

Separe nomes, metadados e conteúdos

Um nó-i registra tipo, permissões, propriedade, tamanho, horários, contagem de ligações, blocos alocados e localização dos dados. Ele não contém o nome do arquivo. O nome pertence a uma entrada de diretório, permitindo que vários nomes compartilhem um nó-i.

Um diretório tem um nó-i do tipo diretório e blocos de dados com entradas. Uma entrada simples armazena um número de nó-i, comprimento do registro, comprimento do nome e nome. O comprimento do registro permite que a travessia pule toda a entrada, incluindo o espaço reutilizável deixado pela exclusão. Diretórios grandes se beneficiam de índices: o XFS usa árvores B e o ext4 usa índices de árvore com dispersão.

Criar um arquivo encontra e define um bit livre no mapa de bits de nós-i. A alocação de dados altera de modo semelhante o mapa de bits de dados. Um alocador pode reservar uma sequência de blocos para que o arquivo cresça de forma contígua. O mapa de bits informa se um bloco está livre; o nó-i informa a qual arquivo ele pertence. Essas estruturas devem estar de acordo.

Um programa vê deslocamentos consecutivos em bytes, mas os blocos de dados correspondentes podem estar espalhados pelo disco. O sistema de arquivos precisa de um mapeamento de cada bloco lógico de arquivo para sua localização física.

Siga ponteiros diretos e indiretos

Um ponteiro direto em um nó-i indica um bloco de dados. Com blocos de 4 KiB, o deslocamento de byte 10.000 fica no bloco lógico 2, pois dois blocos completos ocupam 8.192 bytes. O deslocamento dentro desse bloco é 1.808. Os blocos lógicos começam em 0, então o bloco 2 usa o terceiro ponteiro direto.

Um ponteiro indireto indica um bloco que contém endereços de blocos de dados. Um bloco de 4.096 bytes com endereços de 4 bytes contém 1.024 ponteiros. Um ponteiro duplamente indireto indica um bloco cujos ponteiros levam a 1.024 blocos indiretos. A indireção tripla acrescenta outro nível. Esse índice multinível é desbalanceado de propósito: arquivos pequenos usam ponteiros diretos sem leituras extras de blocos de ponteiros, enquanto arquivos grandes pagam pelos níveis adicionais.

Para um nó-i com 12 ponteiros diretos e um ponteiro de cada nível indireto:

Essas são as capacidades dessa organização de ponteiros. Blocos de ponteiros também ocupam armazenamento, mas seus bytes não são conteúdo do arquivo.

Conte os blocos de ponteiros de um arquivo

Um arquivo de 5 MiB ocupa 1.280 blocos de dados de 4 KiB cada. Atribua os primeiros 12 aos ponteiros diretos. Atribua os 1.024 seguintes ao bloco indireto simples. Restam 244 blocos de dados.

Esses 244 precisam de uma raiz duplamente indireta e de um bloco indireto abaixo dela. Ao todo, o arquivo precisa de três blocos de ponteiros: o bloco indireto simples, a raiz duplamente indireta e seu único filho. Contar apenas a raiz duplamente indireta deixa de fora o filho que realmente contém os endereços de dados. Contar todos os 1.024 filhos possíveis desperdiça espaço: apenas o filho necessário é alocado.

Compare extensões e cadeias

Uma extensão registra um bloco de disco inicial e o comprimento de uma sequência. Uma sequência contígua de 1.000 blocos pode usar uma extensão em vez de 1.000 ponteiros separados. Ext4, XFS e NTFS usam extensões. O ext4 pode manter até quatro extensões em seu nó-i, com uma árvore para as demais. A fragmentação divide sequências e aumenta o número necessário de registros de extensão.

A alocação encadeada segue uma cadeia de blocos. A tabela de alocação de arquivos (FAT) armazena as ligações para o próximo bloco em uma tabela separada, geralmente mantida em cache na memória. Uma entrada de diretório identifica o primeiro bloco, e alcançar um bloco mais adiante exige seguir as ligações anteriores. O FAT não usa nós-i do Unix e não oferece suporte a duas ligações físicas para um arquivo.

Deslocamentos consecutivos nunca provam contiguidade física. O alocador escolhe os locais, e o mapeamento registra essas escolhas.

Uma chamada de sistema pode exigir várias operações de disco ou nenhuma. Para acompanhar o trabalho, siga as estruturas que o sistema de arquivos precisa consultar e informe quais delas já estão em cache.

Percorra um caminho antes de ler o conteúdo

No modelo simples sem cache, abrir /docs/plan.txt lê cinco blocos:

1. O nó-i da raiz, cujo número é conhecido.
2. Os dados do diretório raiz, para encontrar docs.
3. O nó-i de docs.
4. Os dados do diretório docs, para encontrar plan.txt.
5. O nó-i do arquivo.

Cada diretório cabe em um bloco, e nenhum bloco necessário está inicialmente na memória. O sistema de arquivos verifica as permissões e cria uma entrada de arquivo aberto. A abertura encontrou os metadados do arquivo; ainda não leu seu conteúdo. O número de nó-i da raiz 2 é usado no ext2 e no ext4.

Em um modelo de leitura deliberadamente sem cache, cada leitura de bloco lê o nó-i do arquivo, lê os dados e escreve o horário de acesso do nó-i. Dois blocos acrescentam seis operações de entrada e saída, totalizando onze, incluindo a abertura. Nesse modelo, fechar não exige entrada ou saída de disco. Essas contagens descrevem as regras explícitas de releitura e registro de horários do modelo; um cache real as altera.

Considere a alocação durante a criação

Criar /docs/log.txt exige mais do que encontrar um nó-i existente. No mesmo modelo simples, são realizadas quatro leituras para os nós-i e dados dos diretórios raiz e docs. Ler e escrever o mapa de bits de nós-i acrescenta duas operações de entrada e saída. Atualizar os dados de docs acrescenta uma escrita. Ler e escrever o novo nó-i acrescenta duas, e atualizar o nó-i de docs acrescenta uma. Total: dez.

Cada bloco de dados recém-alocado acrescenta cinco operações de entrada e saída: ler e escrever o mapa de bits de dados, ler e escrever o nó-i do arquivo e escrever o bloco de dados. Dois blocos resultam, portanto, em vinte operações de entrada e saída, incluindo a criação. Esse acompanhamento conta as estruturas de dados simples antes de acrescentar o tráfego do diário ou o comportamento de um cache real.

Manter um registro ajuda: liste a estrutura, se ela é lida ou escrita e por quê. Uma escrita de dados também precisa de um registro de alocação e de uma atualização de ponteiro. Uma alteração de diretório também altera seus metadados.

Deixe o cache alterar o acompanhamento

Um acerto de cache usa um bloco que já está na memória. O Linux usa um cache de páginas unificado, compartilhado com a memória virtual, e não um cache de arquivos de tamanho fixo permanentemente separado. Uma nova abertura pode reutilizar os blocos de diretório e de nós-i da travessia anterior. Ler conteúdo em cache não exige leitura do dispositivo. A política usual relatime do Linux também evita uma escrita de atime a cada leitura.

O armazenamento temporário de escritas em buffer adia o envio de blocos modificados ao disco. Duas criações de arquivos próximas no tempo podem atualizar o mesmo mapa de bits de nós-i na memória e escrevê-lo uma vez mais tarde. O sistema de arquivos pode reordenar o trabalho para obter maior vazão. Um arquivo temporário de curta duração pode ser criado e removido antes que seu conteúdo chegue ao armazenamento.

O uso de buffer melhora o desempenho, mas deixa um intervalo sem garantia de durabilidade. fsync fecha esse intervalo para um arquivo ao aguardar suas escritas necessárias. No Linux, O_DIRECT permite que programas adequados contornem o cache de páginas quando gerenciam seus próprios buffers; contornar um cache não é, por si só, a mesma operação que sincronizar o armazenamento durável.

Um disco rígido pode transferir rapidamente uma longa sequência de bytes quando sua cabeça chega até eles. Requisições pequenas e dispersas desperdiçam tempo com busca e espera pela rotação. O Fast File System altera a alocação para que operações comuns de arquivo usem mais da largura de banda de transferência do disco.

Identifique os problemas da antiga organização Unix

A antiga organização Unix colocava todos os nós-i perto do início e todos os dados dos arquivos depois deles. Ler um arquivo podia, portanto, exigir uma longa busca dos metadados até o conteúdo. Uma lista de blocos livres espalhava gradualmente as alocações à medida que arquivos eram criados e excluídos. Até um arquivo sequencial podia resultar em muitos acessos não relacionados ao disco.

Blocos pequenos de 512 bytes pioravam isso. Cada atraso de posicionamento permitia apenas uma transferência curta antes que a próxima requisição precisasse de outra busca ou rotação. Medições históricas mostraram que o projeto antigo entregava apenas 2% da largura de banda do disco em alguns casos. Esse valor descreve o projeto antigo medido, não um limite fixo das interfaces Unix.

O Fast File System (FFS), desenvolvido em Berkeley no início da década de 1980, manteve chamadas conhecidas como open, read e write enquanto alterava a organização e a política de alocação. Blocos maiores, normalmente de 4 KiB, aumentaram os bytes transferidos por requisição. Manter metadados e conteúdo próximos reduziu a distância entre requisições relacionadas.

Construa grupos com recursos próprios

Um cilindro é o conjunto de trilhas no mesmo raio entre as superfícies dos pratos de um disco. O FFS forma grupos de cilindros com cilindros vizinhos. Um arquivo pode ter seu nó-i e seus dados no mesmo grupo, mantendo curta a busca entre metadados e dados.

Cada grupo contém uma cópia do superbloco, seus próprios mapas de bits de alocação de nós-i e dados, parte da tabela de nós-i e blocos de dados. O grupo se parece com um pequeno sistema de arquivos, mas todos os grupos pertencem a um único sistema de arquivos. Uma cópia do superbloco também ajuda na recuperação se uma cópia for danificada. O ext4 mantém cópias em grupos selecionados, em vez de em todos.

Unidades modernas ocultam sua geometria física. Ext2, ext3 e ext4 usam, portanto, grupos de blocos, sequências de endereços de blocos lógicos consecutivos, para buscar o mesmo objetivo de localidade sem depender de cilindros exatos.

Acompanhe a criação de um arquivo pequeno

Criar /docs/a.txt exige um nó-i livre, um bloco de dados, alterações nos mapas de alocação e uma nova entrada de diretório. O FFS tenta colocar o arquivo no grupo de seu diretório pai. O novo nó-i, os dados do arquivo, os mapas de bits e as atualizações do diretório podem então ficar próximos.

A operação ainda exige várias atualizações distintas. O agrupamento economiza tempo de posicionamento; ele não reúne todos os metadados e dados em um bloco. Uma organização sensível ao disco melhora o custo de acesso a essas estruturas sem alterar as operações de arquivo do programa.

O FFS usa nomes como pistas sobre quais arquivos um programa acessará em conjunto. Ele também limita quanto espaço um arquivo grande pode ocupar em um grupo, equilibrando a localidade com espaço para alocações futuras.

Aloque diretórios e arquivos

Um novo diretório vai para um grupo com relativamente poucos diretórios e muitos nós-i livres. Isso distribui diretórios diferentes e deixa espaço para seus futuros arquivos. O nó-i de um arquivo comum vai para o grupo de seu diretório pai, e seus dados ficam próximos do nó-i.

Para /a/b, /a/c e /a/d, os três arquivos são colocados próximos ao diretório /a. Um arquivo /b/f segue seu próprio diretório pai /b, geralmente para outro grupo. Isso aproveita a localidade no espaço de nomes: um compilador trabalhando em um projeto frequentemente abre vários arquivos no mesmo diretório. A relação de diretório prevê padrões de acesso; não é uma garantia para todos os programas.

Abra uma exceção para um arquivo grande

Um arquivo grande poderia consumir os blocos livres de seu grupo e forçar todos os vizinhos posteriores a ficar em outro lugar. O FFS mantém a primeira parte, alcançada por 12 ponteiros diretos, no grupo do nó-i. Com blocos de 4 KiB, isso equivale a 48 KiB. Fragmentos posteriores, cada um alcançado por um bloco indireto que contém 1.024 ponteiros, abrangem 4 MiB de dados e vão para outros grupos pouco utilizados.

Isso sacrifica parte da localidade dentro do arquivo grande para preservar a localidade dos outros arquivos do diretório. O arquivo grande paga um atraso de posicionamento entre fragmentos, então cada fragmento deve ser grande o suficiente para compensar esse custo.

Deduzindo o tamanho do fragmento

Considere que o posicionamento leve T segundos e a taxa de transferência seja R bytes por segundo. Um fragmento C leva C/R segundos para ser transferido. A fração do tempo total gasta em transferência é:

Resolvendo, obtemos:

A 100 MB/s com 10 ms de posicionamento, R vezes T é 1 MB. Um fragmento de 1 MB precisa de 10 ms de transferência mais 10 ms de posicionamento, resultando em 50% da largura de banda máxima. Para 90%, multiplique 1 MB por 0,9/0,1 para obter 9 MB. Para 99%, o multiplicador é 99, resultando em 99 MB. Converta milissegundos em segundos antes de multiplicar por MB/s. O denominador inclui o tempo de transferência e o de posicionamento; dividir apenas pelo tempo de transferência ocultaria a sobrecarga.

As taxas de transferência melhoraram mais rápido que os atrasos de posicionamento, então alcançar a mesma fração da taxa máxima exige fragmentos maiores à medida que a diferença aumenta.

Acomode arquivos pequenos e preserve a compatibilidade

O FFS também usava sub-blocos de 512 bytes para que arquivos pequenos não desperdiçassem um bloco inteiro de 4 KiB. Arquivos em crescimento eram copiados para blocos inteiros; a biblioteca C armazenava temporariamente escritas em partes de 4 KiB para reduzir movimentações repetidas. A parametrização histórica deixava intervalos de rotação entre blocos consecutivos para que um próximo bloco solicitado ainda não tivesse passado pela cabeça. Buffers de trilha modernos tornam essa técnica desnecessária ao buscar uma trilha internamente.

Nomes longos, ligações simbólicas e rename atômico eram recursos adicionais do FFS. O ganho de velocidade da organização em si não exigia alterar programas existentes.

Um acréscimo parece uma ação única para um programa. No disco, ele altera várias estruturas, e uma falha pode deixar apenas algumas delas atualizadas. A consistência após falhas trata de como esses resultados parciais podem ser evitados ou reparados.

Acompanhe três escritas independentes

Acrescentar um bloco de 4 KiB a um arquivo existente altera:

• Db, o novo bloco de dados que contém os bytes acrescentados.
• I, o nó-i com tamanho maior e um ponteiro para esse bloco.
• B, o mapa de bits de dados que marca o bloco como alocado.

Os três chegando ao armazenamento produzem a atualização consistente pretendida. Nenhum chegando ao armazenamento deixa o estado antigo consistente. O perigo está nas seis combinações parciais. O dispositivo pode reordenar requisições, então enviá-las em determinada ordem sem esperar não estabelece a ordem de conclusão.

Classifique cada resultado parcial

Uma inconsistência ocorre quando os metadados discordam, como um nó-i que reivindica um bloco cujo bit de alocação indica que está livre. O alocador pode então atribuir esse mesmo bloco a outro arquivo. Um vazamento de espaço de armazenamento reserva espaço que nenhum arquivo pode alcançar. Dados residuais inválidos podem ser mais difíceis de detectar: I e B concordam perfeitamente, embora Db nunca tenha chegado.

Db sozinho não causa vazamento de espaço alocado, pois o mapa de bits ainda permite que o bloco seja reutilizado. Escrever bytes em um local livre não é o mesmo que alocá-lo. B sozinho causa vazamento de espaço, pois a alocação sobreviveu sem um ponteiro que indique seu dono.

Separe estrutura de significado

Um verificador pode comparar ponteiros com mapas de bits. Em geral, ele não pode determinar se bytes plausíveis são aqueles que um programa pretendia salvar. O resultado com I e B demonstra esse limite: um arquivo estruturalmente válido pode ter conteúdo incorreto.

A transição desejada é atômica em toda a atualização: recuperar o estado antigo completo ou o novo estado completo. Um modelo simples de armazenamento fornece escritas atômicas apenas para um setor, tradicionalmente de 512 bytes. Vários blocos do sistema de arquivos excedem essa unidade, então o sistema de arquivos precisa construir um protocolo mais forte. As garantias reais de escrita atômica dependem do dispositivo e da interface; o protocolo de diário deve fazer seu registro de confirmação caber na unidade atômica compatível.

O uso de buffer aumenta o número de alterações que podem ser perdidas, mas não é a causa principal. Mesmo enviar cada escrita imediatamente deixa um ponto de possível falha entre conclusões separadas. A criação, a renomeação e a exclusão de arquivos também alteram várias estruturas. Entender seus estados de falha começa com o mesmo exercício: identifique cada bloco alterado e pergunte o que acontece quando apenas parte deles sobrevive.

Um verificador de sistemas de arquivos repara relações entre estruturas armazenadas após a ocorrência de danos. Seu ponto forte é uma visão ampla dos metadados; seus pontos fracos são o custo da varredura e o desconhecimento do conteúdo pretendido dos arquivos.

Reconstrua o quadro de alocação

O fsck, abreviação de verificação do sistema de arquivos, examina um sistema de arquivos após um desligamento incorreto, antes da montagem normal. Ele verifica se o tamanho e as contagens do superbloco fazem sentido e pode usar um superbloco de segurança se a cópia principal estiver danificada.

Em seguida, percorre nós-i e blocos indiretos para determinar a quais blocos de dados os arquivos realmente fazem referência. A partir dessas informações de propriedade, ele reconstrói os mapas de bits de alocação. Se um nó-i válido aponta para o bloco 74 enquanto o mapa de bits indica que 74 está livre, o mapa deve ser alterado para indicar que está alocado. Apenas confiar no mapa de bits poderia permitir que uma alocação posterior sobrescrevesse os dados do arquivo.

A divergência oposta é um bit marcado como alocado no mapa sem um ponteiro de nó-i que indique seu dono. Reconstruir o mapa pode recuperar esse espaço. O reparo escolhe uma relação consistente; ele não pode reconstruir bytes arbitrários de uma aplicação que estejam faltando.

Verifique objetos, nomes e ligações

Todo nó-i alocado precisa de um tipo válido, como arquivo comum, diretório ou ligação simbólica. Um nó-i que não pode ser reparado é limpo e os registros de alocação são ajustados.

Percorrer a partir da raiz permite ao fsck contar referências de diretórios a cada nó-i. Ele compara essas referências observadas com as contagens de ligações registradas e corrige erros. Um nó-i alocado que nenhum diretório alcança pode ser movido para lost+found, dando ao conteúdo recuperado um nome acessível sem conhecer seu caminho original.

Outras verificações incluem:

• Propriedade duplicada: dois nós-i reivindicam um bloco de dados. Um reparo pode limpar um nó-i ou dar a cada arquivo uma cópia separada.
• Endereços inválidos: ponteiros fora do intervalo válido do sistema de arquivos devem ser limpos.
• Estrutura de diretórios: . e .. devem ser válidos e ocupar as primeiras entradas na organização simples de diretórios, as entradas devem se referir a nós-i alocados e diretórios não devem ter vários diretórios pais.

Essas verificações interagem. Limpar um nó-i inválido também altera quais blocos devem estar alocados e quais entradas de diretório continuam válidas. Portanto, um reparo precisa de uma visão coerente dos metadados, não apenas de uma lista de bits individuais suspeitos.

Entenda o que um resultado sem erros estabelece

Suponha que o nó-i e o mapa de bits de um acréscimo tenham chegado ao disco, mas seus dados não. O ponteiro está no intervalo, o bit de alocação está definido e a estrutura de ligações é válida. O fsck não tem divergência de metadados a reparar. O arquivo pode passar pela verificação enquanto contém bytes antigos em sua região recém-adicionada.

O tempo de execução também depende principalmente do tamanho do sistema de arquivos, não da quantidade alterada antes de uma falha. Uma falha durante uma atualização de três blocos ainda pode exigir a varredura de todos os metadados. Em um sistema de arquivos grande, isso pode levar de minutos a horas, mantendo o acesso normal indisponível durante a varredura.

O registro em diário reduz o trabalho normal de recuperação após falhas ao registrar atualizações recentes. Ele não torna um verificador obsoleto: erros de software ou falhas de hardware podem danificar estruturas além do que a reaplicação do diário pode reparar. O fsck continua sendo uma ferramenta de reparo para esses casos.

Um diário registra uma atualização antes que o sistema de arquivos sobrescreva seus locais normais. Após uma falha, esse registro informa à recuperação quais alterações completas podem ser refeitas. Isso é o registro antecipado de alterações. Ext3, ext4, XFS e NTFS usam registro em diário, embora seus formatos exatos de registro sejam diferentes.

Descreva uma atualização como uma transação

Para um acréscimo, o registro de dados em diário registra cópias do novo nó-i I, do mapa de bits B e do bloco de dados Db. Um registro de início de transação, TxB, contém um identificador e os destinos finais dos blocos. Um registro de fim de transação, TxE, contém o identificador correspondente e marca a confirmação.

Registrar imagens completas dos blocos substitutos é registro físico. Registrar uma descrição da operação é registro lógico. Refazer operações fisicamente tem uma propriedade útil: escrever a mesma imagem no mesmo endereço novamente tem o mesmo efeito. A recuperação pode, portanto, repetir uma consolidação que terminou parcialmente antes da falha.

Confirme depois da área útil

O protocolo básico tem quatro etapas:

1. Escrita no diário: escreva TxB, I, B e Db no diário e aguarde a conclusão durável.
2. Confirmação: escreva TxE e aguarde. A transação está agora confirmada.
3. Consolidação: copie I, B e Db do diário para seus locais finais.
4. Liberação: libere o espaço dessa transação no diário para reutilização posterior.

TxE não deve se tornar durável antes de sua área útil. Se todos os cinco blocos fossem enviados sem garantia de ordenação, um dispositivo poderia concluir TxB e TxE enquanto deixaria Db sem escrever. A recuperação confundiria uma transação incompleta com uma válida. No modelo básico, TxE cabe em uma escrita atômica de setor, então está presente ou ausente como um registro de confirmação completo.

Caches de escrita dos dispositivos também devem respeitar o limite de durabilidade. Descargas de cache ou escritas forçadas impedem que um cache volátil do dispositivo faça o protocolo acreditar que uma área útil está segura quando uma queda de energia ainda poderia apagá-la.

Recupere-se de dois pontos de falha

Uma falha após a área útil, mas antes de TxE, deixa uma transação não confirmada. A recuperação a ignora, mantendo o estado antigo do arquivo.

Uma falha após TxE, mas durante a consolidação, deixa uma transação confirmada. A recuperação escreve todas as suas imagens em seus locais finais em ordem. Algumas escritas podem repetir trabalho já feito, o que não causa dano para essas imagens de blocos. Isso é recuperação por reaplicação. O espaço do diário não pode ser reutilizado até que as imagens confirmadas cheguem aos seus locais finais.

O diário é um registro circular. Seu superbloco controla o intervalo ativo, permitindo que o espaço concluído seja reutilizado. Agrupar várias atualizações em uma transação pode registrar uma vez um bloco de diretório ou mapa de bits compartilhado. O intervalo de confirmação padrão do ext4 é de 5 segundos, então a confirmação não ocorre automaticamente de imediato após cada escrita da aplicação.

Separe somas de verificação de durabilidade

Uma soma de verificação da transação pode revelar blocos de área útil ausentes ou fragmentados mesmo quando há um registro de confirmação. Um protocolo baseado em soma de verificação pode enviar as escritas do diário juntas e aceitar apenas transações cuja validação seja bem-sucedida. Somas de verificação detectam registros incompletos; descargas de cache estabelecem se os bytes confirmados realmente sobrevivem.

Uma escrita de aplicação em buffer e não confirmada ainda pode desaparecer. Um programa que exige conclusão durável usa fsync e verifica se foi bem-sucedido.

O registro de dados em diário escreve o conteúdo dos arquivos no diário e depois em seus locais finais. Registrar apenas metadados em diário reduz esse tráfego, mas a ordem entre dados e metadados ainda determina o que a recuperação pode expor.

Mantenha os dados à frente dos ponteiros confirmados

No registro ordenado de metadados em diário, Db vai diretamente para seu local final. TxB, I e B vão para o diário. Esses dois conjuntos de escritas podem ocorrer em paralelo, mas ambos devem terminar antes de TxE confirmar os metadados. Após a confirmação, I e B podem ser consolidados e o espaço do diário liberado.

A dependência é fundamental: o bloco indicado por um ponteiro deve estar pronto antes que esse ponteiro possa ser recuperado. Se I for confirmado primeiro, a recuperação pode instalar um ponteiro válido para bytes deixados por um usuário anterior do bloco. Os metadados estariam de acordo sem conter os dados pretendidos.

O modo ordenado é o padrão. O registro apenas de metadados em diário não implica o modo ordenado: o modo writeback pode recuperar arquivos estruturalmente íntegros com conteúdo desatualizado. O modo de diário de dados ilustra o protocolo completo, mas custa uma segunda escrita dos dados do arquivo.

Evite que a reaplicação danifique um bloco reutilizado

O conteúdo de diretórios é considerado metadado. Suponha que um bloco de diretório no endereço 1000 seja registrado, depois o diretório seja removido e o mesmo endereço passe a conter dados de um arquivo comum. Esses novos dados do usuário não são registrados no modo que registra apenas metadados. Reaplicar a imagem antiga do diretório após uma falha sobrescreveria os bytes do novo arquivo.

Um registro de revogação confirmado informa à recuperação para ignorar cópias registradas desse bloco em transações até a transação que fez a revogação, inclusive. Ele não proíbe todo uso futuro do endereço. Se uma transação posterior registrar esse bloco novamente, a imagem posterior ainda poderá ser reaplicada. Esse limite de tempo distingue a revogação de marcar permanentemente um bloco como inutilizável.

Compare alternativas

As atualizações suaves impõem dependências entre escritas comuns sem um diário. Escrever dados inicializados antes de um ponteiro evita dados residuais inválidos acessíveis, embora operações interrompidas possam causar vazamento de espaço a ser recuperado por uma verificação posterior em segundo plano. O FFS do FreeBSD usa essa abordagem. Acompanhar todas as dependências dificulta a implementação.

A cópia na escrita (COW) escreve blocos alterados em locais não utilizados e usa uma troca atômica do ponteiro raiz para publicar a nova árvore. A árvore antiga permanece disponível até a troca. ZFS, Btrfs e WAFL usam projetos relacionados; preservar blocos antigos também permite retratos do estado.

Projetos de pesquisa baseados em ponteiros de retorno registram a propriedade dos dados de volta aos nós-i, de modo que atualizações incompletas deixem divergências detectáveis. A consistência otimista após falhas reduz a espera e usa somas de verificação e outras verificações para detectar trabalho incompleto. Cada abordagem equilibra tráfego de escrita, garantias de recuperação e complexidade de implementação. O registro ordenado de metadados em diário mantém a recuperação curta enquanto escreve dados comuns de arquivos uma vez.

Um sistema de arquivos estruturado em registro transforma pequenas atualizações dispersas em grandes escritas sequenciais. Isso ajuda um disco cuja taxa de transferência é alta, mas cujos atrasos de busca e rotação continuam custosos.

Reúna atualizações em um segmento

O LFS de Berkeley, desenvolvido por Rosenblum e Ousterhout e publicado em 1991, partiu de mudanças nas cargas de trabalho. Memórias maiores atendiam a mais leituras pelo cache, fazendo das escritas uma parcela maior do tráfego de disco. A largura de banda sequencial crescia mais rápido que a velocidade de posicionamento. O FFS ainda precisava de várias escritas curtas de metadados e dados para criar um arquivo pequeno, e escritas pequenas também funcionavam mal com RAID de paridade.

O LFS armazena temporariamente dados alterados, nós-i e informações de mapeamento juntos na memória. Ele os escreve em uma região não utilizada do disco como um grande segmento. Atualizar um bloco cria uma nova versão em um novo endereço; a versão anterior permanece fisicamente presente até que a limpeza recupere seu segmento.

Segmentos amortizam o posicionamento assim como grandes fragmentos do FFS. Com taxa R, tempo de posicionamento T e fração desejada F do tempo gasta em transferência, o tamanho em buffer é:

A 200 MB/s e 5 ms, atingir 95% exige 19 MB. A transferência leva 95 ms, o posicionamento leva 5 ms e a taxa efetiva é 19 MB por 0,1 s = 190 MB/s. Uma fração desejada alta pode exigir um segmento maior que o tamanho usual de centenas de kilobytes a vários megabytes. O tamanho necessário depende do dispositivo e da meta, não da palavra “segmento”.

Encontre um nó-i que continua mudando de lugar

A fórmula de tabela fixa de nós-i não funciona mais: cada atualização de nó-i escreve em um novo endereço. O LFS acrescenta um mapa de nós-i, ou imap, que associa cada número de nó-i ao seu endereço mais recente no disco. Partes atualizadas do imap são escritas no registro ao lado dos nós-i que descrevem.

Uma região de ponto de verificação (CR) fixa registra onde estão as partes mais recentes do imap. Ela é atualizada periodicamente, por exemplo a cada 30 segundos, para que a escrita ocasional em local fixo não domine o tráfego.

A sequência de busca é:

1. Leia a CR na montagem para encontrar as partes atuais do imap.
2. Carregue o imap na memória.
3. Procure o número do nó-i solicitado no imap.
4. Leia esse nó-i mais recente e siga seus ponteiros de dados.

Depois que o imap está em cache, leituras comuns de arquivos usam praticamente o mesmo caminho do nó-i aos dados que no FFS. O mapeamento adicional torna viável a movimentação sem alterar a identidade estável do arquivo.

Mantenha estáveis as entradas de diretório

Um diretório armazena nomes e números de nós-i. Se /docs/report.txt for atualizado, seu nó-i muda de lugar, mas mantém seu número. O imap muda; a entrada de diretório não precisa mudar apenas por causa dessa movimentação.

Sem essa indireção, um diretório que contivesse endereços físicos de nós-i precisaria ser reescrito sempre que um nó-i filho mudasse de lugar. Seu próprio nó-i então mudaria de lugar, forçando uma alteração em seu diretório pai, e assim por diante até a raiz. O imap interrompe esse problema da atualização recursiva.

O LFS torna as escritas sequenciais, mas não todas as leituras. Blocos inalterados de um arquivo podem permanecer em segmentos antigos enquanto versões posteriores de outros blocos vão para outro lugar. Ler esse arquivo ainda pode exigir buscas entre segmentos; caches grandes de memória fazem parte da motivação do projeto.

Escrever novas versões em locais não utilizados mantém os bytes antigos fisicamente presentes. O LFS precisa distinguir versões antigas inacessíveis de blocos ativos, recuperar grandes regiões livres e recuperar um mapeamento utilizável após uma falha.

Limpe segmentos inteiros

O limpador de segmentos lê segmentos parcialmente ocupados, copia seus blocos ativos para um número menor de novos segmentos e libera os segmentos antigos. Se quatro segmentos de mesmo tamanho tiverem, cada um, um quarto de dados ativos, seus dados ativos combinados preencherão um novo segmento. Liberar os quatro segmentos antigos após a cópia resulta em um ganho de três segmentos de capacidade utilizável.

Limpar segmentos inteiros preserva grandes regiões contíguas para futuras escritas sequenciais. A cópia tem um custo: blocos ativos são lidos e escritos novamente, embora nenhuma aplicação os tenha alterado. Um disco quase cheio com segmentos predominantemente ativos pode exigir muita cópia para recuperar pouco espaço livre.

Determine se um bloco está ativo

Um resumo do segmento identifica o nó-i proprietário de cada bloco e o deslocamento do bloco lógico de arquivo. Para testar um bloco no endereço A, use o imap para encontrar o nó-i mais recente desse proprietário. Siga seu ponteiro para o bloco lógico registrado. Se o ponteiro ainda for igual a A, essa é a versão ativa. Se apontar para outro lugar, A está obsoleto.

Por exemplo, um resumo associa o endereço 600 ao nó-i 14, bloco lógico 2. O nó-i 14 atual aponta o bloco lógico 2 para o endereço 920. O bloco 600 está inativo mesmo que seus bytes pareçam dados válidos. A condição de ativo depende da acessibilidade atual, não de quão recentemente um bloco foi escrito ou de seu conteúdo parecer útil.

Números de versão aceleram a identificação de blocos inativos. Excluir um arquivo ou truncá-lo a zero aumenta sua versão no imap. Um bloco de segmento que contém uma versão mais antiga pode ser classificado como inativo sem ler o nó-i.

A política de limpeza também considera a mudança esperada. Segmentos quentes contêm blocos sobrescritos com frequência; esperar pode permitir que mais de seus blocos se tornem inativos sem copiá-los. Segmentos frios mudam pouco, então a política original do LFS os limpa mais cedo. A política deve equilibrar fração ativa, idade e espaço disponível; a temperatura de um segmento, por si só, não mede o custo imediato da cópia.

Recupere o mapeamento e o trabalho recente

O LFS mantém duas regiões de ponto de verificação em extremidades opostas do disco e alterna as atualizações. Cada atualização escreve um cabeçalho com registro de horário, o corpo e um registro de horário final correspondente. A recuperação escolhe a região mais recente cujo início e fim correspondem. Uma atualização mais recente interrompida não substitui um ponto de verificação mais antigo e completo.

O ponto de verificação pode não incluir os segmentos concluídos mais recentes. Portanto, a recuperação reaplica as atualizações a partir do fim do registro nele anotado, encontrando atualizações posteriores válidas e aplicando-as para reconstruir o mapeamento atual. Dados que nunca formaram uma atualização válida e recuperável não podem ser recriados a partir da memória após uma queda de energia.

Sistemas relacionados com cópia na escrita preservam blocos antigos para oferecer retratos do estado; ZFS, Btrfs e WAFL compartilham essa ideia geral. Controladores de SSD geralmente usam camadas de tradução flash estruturadas em registro, enquanto o F2FS aplica ideias de estruturação em registro no nível do sistema de arquivos para armazenamento em memória flash. Cada um ainda precisa de uma forma de recuperar o espaço deixado por versões obsoletas.

Um sistema de arquivos distribuído mantém arquivos em um servidor enquanto programas em máquinas clientes usam chamadas de arquivo conhecidas. O cliente traduz essas chamadas em requisições de rede. Atrasos e falhas trazem uma questão que chamadas locais normalmente ocultam: o que um cliente deve fazer quando não consegue saber se uma requisição foi concluída?

Mantenha o estado dos arquivos abertos no cliente

O sistema de arquivos em rede (NFS) da Sun começou na década de 1980. O NFSv2 tornou seu servidor sem estado em relação a arquivos abertos. O servidor armazena arquivos, mas não se lembra dos descritores ou deslocamentos atuais de cada cliente. Cada requisição contém informações suficientes para ser executada sem uma requisição de abertura anterior.

Um identificador de arquivo remoto identifica o volume do servidor, o número do nó-i e a geração do nó-i. A geração muda quando um número de nó-i é reutilizado, impedindo que um identificador antigo nomeie acidentalmente um arquivo diferente nessa posição reutilizada.

Para abrir /home/ana/notes.txt, o cliente começa com um identificador da raiz e envia LOOKUP para home, ana e notes.txt. Ele mantém o identificador resultante em seu próprio estado de arquivo aberto. Ler os primeiros 4 KiB torna-se uma requisição READ que contém esse identificador, deslocamento 0 e quantidade 4096. Fechar o descritor local não exige uma requisição CLOSE do NFSv2 porque o servidor não tem uma entrada de arquivo aberto a liberar.

Tente novamente sem repetir um efeito

Se nenhuma resposta chegar, o cliente não consegue distinguir uma requisição perdida, um servidor indisponível ou uma resposta perdida. Ele reenvia a requisição após um tempo limite.

Uma operação é idempotente quando repeti-la tem o mesmo efeito que executá-la uma vez. READ, LOOKUP e GETATTR não modificam o conteúdo armazenado. Uma WRITE com deslocamento explícito também repete com segurança os mesmos bytes no mesmo local nesse modelo. Repetir uma requisição que diz “acrescente estes bytes ao fim atual” acrescentaria uma segunda cópia; o deslocamento em uma WRITE do NFS evita essa ambiguidade.

Algumas requisições precisam de cuidado extra. Tentar novamente uma MKDIR bem-sucedida após a perda de sua resposta pode retornar “já existe”. O diretório está presente, mas a resposta repetida difere do sucesso original. A recuperação sem estado não transforma toda operação em uma requisição simples que pode ser repetida.

Torne as confirmações confiáveis

O NFSv2 deve tornar uma WRITE durável antes de confirmar o sucesso. Caso contrário, o servidor poderia confirmar um bloco, perdê-lo da memória durante uma falha e depois aceitar blocos posteriores. O cliente acreditaria que todas as escritas foram bem-sucedidas enquanto o arquivo teria uma atualização intermediária ausente.

Respostas estáveis evitam essa falha com um custo de desempenho. O NFSv3 acrescentou escritas instáveis seguidas de COMMIT, permitindo que várias escritas se tornem duráveis em conjunto. O cliente deve distinguir uma confirmação instável de uma conclusão durável.

Diferencie versões do protocolo

Um protocolo com estado precisa de mecanismos para recuperar o estado de arquivos abertos e de travamento após a reinicialização de um servidor e recuperar os recursos associados ao estado de clientes que falharam. O NFSv4 aceita deliberadamente essa complexidade: tem OPEN, CLOSE, travas e concessões temporárias que os clientes renovam. O cliente Linux normalmente tenta primeiro a versão 4.2 e recorre a versões anteriores quando necessário. Portanto, chamar o NFSv2 de sem estado não descreve todas as versões do NFS.

O cache no cliente economiza viagens pela rede, mas cria várias cópias de arquivos compartilhados. A regra de consistência determina quando outra máquina deve parar de usar uma cópia antiga e buscar as alterações de quem escreveu.

Valide caches NFS nos limites de compartilhamento

Na consistência entre fechamento e abertura do NFS, fechar um arquivo modificado descarrega as escritas em buffer para o servidor. Uma abertura posterior em outro cliente verifica se a cópia está atualizada e vê essas alterações. GETATTR ou uma validação relacionada compara atributos do servidor com atributos em cache, descartando dados desatualizados em cache quando uma alteração é detectada.

Verificar a cada acesso sobrecarregaria o servidor. O Linux mantém atributos de arquivos comuns em cache por intervalos padrão de 3 a 60 segundos. Um processo que mantém um arquivo aberto pode, portanto, ler dados desatualizados em cache entre verificações. A abertura é um limite de compartilhamento mais forte que uma leitura qualquer por um descritor já aberto. O comportamento entre fechamento e abertura não promete visibilidade imediata de cada escrita individual.

Reutilize arquivos completos com compromissos de notificação do AFS

O sistema de arquivos Andrew (AFS) foi projetado na Universidade Carnegie Mellon na década de 1980 para atender a muitos clientes por servidor. Quando não existe uma cópia local válida, a abertura busca o arquivo inteiro no disco local. Leituras e escritas usam então essa cópia, e fechar um arquivo modificado envia a nova versão inteira ao servidor. Uma cópia válida em cache pode ser reaberta sem baixá-la novamente.

O AFSv1 verificava a validade a cada abertura e deixava a resolução de caminho para o servidor. O AFSv2 transferiu a resolução para os clientes, que mantêm diretórios em cache, e introduziu compromissos de notificação de alterações. O servidor promete notificar um cliente quando um objeto em cache muda. Até que essa promessa seja invalidada, o cliente reutiliza sua cópia sem verificações repetidas. Seu identificador de arquivo inclui um volume, um identificador de arquivo e um identificador de unicidade.

Acompanhe duas sessões sobrepostas

Suponha que os clientes A e B abram um arquivo. A altera sua cópia local e fecha o arquivo, enviando a nova versão ao servidor. O servidor invalida os compromissos de notificação dos outros clientes. Uma abertura posterior em B busca a nova versão, mas a sessão já aberta de B mantém sua cópia existente até fechar e reabrir.

Se ambas as máquinas modificarem suas cópias, a última a fechar substitui o arquivo inteiro no servidor. Os blocos das duas cópias não são mesclados. Duas edições em deslocamentos diferentes ainda podem perder as alterações de um cliente porque a prevalência do último fechamento escolhe uma versão completa. Processos em uma máquina cliente veem as escritas uns dos outros imediatamente.

Os compromissos de notificação são estado do servidor. Após a reinicialização de um cliente, arquivos em cache são suspeitos porque notificações podem ter sido perdidas. Após a reinicialização de um servidor, os clientes devem detectar a perda das promessas de notificação, por mensagens periódicas de presença ou um aviso do servidor, e revalidar o cache.

Relacione o cache à carga de trabalho

O AFS também oferecia um espaço de nomes global, listas de controle de acesso e volumes gerenciados por administradores. O AFSv2 historicamente aumentou a capacidade de atendimento do servidor para cerca de 50 clientes, de aproximadamente 20 no AFSv1. A regra de cache de nenhum dos projetos substitui coordenação explícita, como travas de arquivo, quando programas precisam de atualizações compartilhadas seguras.