Sistema de arquivos Unix - Unix File System

O sistema de arquivos Unix ( UFS ) é um sistema de arquivos compatível com muitos sistemas operacionais Unix e semelhantes ao Unix . É um descendente distante do sistema de arquivos original usado pela Versão 7 do Unix .

Posteriormente, o Berkeley Fast File System (também chamado BSD Fast File System - FFS ) foi usado em Unixes, que não é o mesmo que UFS.

Projeto

Um volume UFS é composto das seguintes partes:

• Alguns blocos no início da partição reservados para blocos de inicialização (que devem ser inicializados separadamente do sistema de arquivos)
• Um superbloco, contendo um número mágico que identifica isso como um sistema de arquivos UFS, e alguns outros números vitais que descrevem a geometria deste sistema de arquivos e estatísticas e parâmetros de ajuste comportamental
• Uma coleção de grupos de cilindros. Cada grupo de cilindros tem os seguintes componentes:
  • Uma cópia de backup do superbloco
  • Um cabeçalho de grupo de cilindros, com estatísticas, listas livres, etc., sobre este grupo de cilindros, semelhantes aos do superbloco
  • Uma série de inodes , cada um contendo atributos de arquivo
  • Uma série de blocos de dados

Os inodes são numerados sequencialmente, começando em 0. O inode 0 é reservado para entradas de diretório não alocadas, o inode 1 era o inode do arquivo de bloco inválido nas versões históricas do UNIX, seguido pelo inode para o diretório raiz , que é sempre o inode 2 e o inode para o diretório perdido + achado que é o inode 3.

Os arquivos de diretório contêm apenas a lista de nomes de arquivos no diretório e o inode associado a cada arquivo. Todos os metadados do arquivo são mantidos no inode.

História e evolução

As primeiras versões dos sistemas de arquivos Unix eram chamadas simplesmente de FS . FS incluiu apenas o bloco de inicialização, superbloco, um grupo de inodes e os blocos de dados. Isso funcionou bem para os pequenos discos para os quais os primeiros Unixes foram projetados, mas conforme a tecnologia avançava e os discos cresciam, mover a cabeça para frente e para trás entre o aglomerado de inodes e os blocos de dados aos quais eles se referiam causava o thrashing . Marshall Kirk McKusick , então um estudante de graduação em Berkeley , otimizou o FFS (Fast File System) do BSD 4.2 inventando grupos de cilindros, que dividem o disco em pedaços menores, com cada grupo tendo seus próprios inodes e blocos de dados.

A intenção do BSD FFS é tentar localizar blocos de dados e metadados associados no mesmo grupo de cilindros e, idealmente, todo o conteúdo de um diretório (dados e metadados para todos os arquivos) no mesmo grupo de cilindros ou próximo, assim reduzindo a fragmentação causada pela dispersão do conteúdo de um diretório em um disco inteiro.

Alguns dos parâmetros de desempenho no superbloco incluem número de trilhas e setores, velocidade de rotação do disco, velocidade do cabeçote e alinhamento dos setores entre as trilhas. Em um sistema totalmente otimizado, a cabeça pode ser movida entre trilhas próximas para ler setores espalhados de trilhas alternadas enquanto espera o prato girar.

À medida que os discos ficavam cada vez maiores, a otimização em nível de setor se tornava obsoleta (especialmente com discos que usavam numeração de setor linear e setores variáveis ​​por trilha). Com discos e arquivos maiores, as leituras fragmentadas se tornaram mais problemáticas. Para combater isso, o BSD originalmente aumentou o tamanho do bloco do sistema de arquivos de um setor para 1 K no 4.0 BSD; e, no FFS, aumentou o tamanho do bloco do sistema de arquivos de 1 K para 8 K. Isso tem vários efeitos. A chance de os setores de um arquivo serem contíguos é muito maior. A quantidade de sobrecarga para listar os blocos do arquivo é reduzida, enquanto o número de bytes representáveis ​​por qualquer número de blocos é aumentado.

Tamanhos de disco maiores também são possíveis, uma vez que o número máximo de blocos é limitado por um número de bloco de largura de bit fixa. No entanto, com tamanhos de bloco maiores, os discos com muitos arquivos pequenos desperdiçarão espaço, pois cada arquivo deve ocupar pelo menos um bloco. Por causa disso, o BSD adicionou fragmentação em nível de bloco , também chamada de subalocação de bloco, mesclagem final ou empacotamento final, onde o último bloco parcial de dados de vários arquivos pode ser armazenado em um único bloco de "fragmento" em vez de vários blocos vazios ( Allen 2005 ).

Implementações

Os fornecedores de alguns sistemas Unix proprietários, como SunOS / Solaris , System V Release 4 , HP-UX e Tru64 UNIX , e sistemas abertos derivados do Unix como o Illumos , adotaram o UFS. A maioria deles adaptou o UFS para seus próprios usos, adicionando extensões proprietárias que podem não ser reconhecidas por versões de Unix de outros fornecedores. Muitos continuaram a usar o tamanho do bloco original e as larguras do campo de dados como o UFS original, portanto, algum grau de compatibilidade de leitura permanece entre as plataformas. A compatibilidade entre as implementações como um todo é irregular, na melhor das hipóteses.

A partir do Solaris 7 , a Sun Microsystems incluiu o UFS Logging, que trouxe o journaling do sistema de arquivos para o UFS, que ainda está disponível nas versões atuais do Solaris e Illumos. Solaris UFS também possui extensões para arquivos grandes e discos grandes e outros recursos.

Em 4.4BSD e sistemas BSD Unix derivados dele, como FreeBSD , NetBSD , OpenBSD e DragonFlyBSD , a implementação de UFS1 e UFS2 é dividida em duas camadas: uma camada superior que fornece a estrutura de diretório e suporta metadados (permissões, propriedade, etc.) na estrutura do inode e nas camadas inferiores que fornecem contêineres de dados implementados como inodes. Isso foi feito para suportar o FFS tradicional e o sistema de arquivos estruturado em log do LFS com código compartilhado para funções comuns. A camada superior é chamada de "UFS" e as camadas inferiores são chamadas de "FFS" e "LFS". Em alguns desses sistemas, o termo "FFS" é usado para a combinação da camada inferior FFS e da camada superior UFS, e o termo "LFS" é usado para a combinação da camada inferior LFS e da camada superior UFS.

Kirk McKusick implementou a realocação de bloco, uma técnica que reordena os blocos no sistema de arquivos antes que as gravações sejam feitas para reduzir a fragmentação e controlar o envelhecimento do sistema de arquivos. Ele também implementou soft updates , um mecanismo que mantém a consistência do sistema de arquivos sem limitar o desempenho da maneira que o modo de sincronização tradicional fazia. Isso tem o efeito colateral de reduzir a necessidade de verificação do sistema de arquivos após um travamento ou queda de energia. Para superar os problemas restantes após uma falha, um utilitário fsck em segundo plano foi introduzido.

No UFS2, Kirk McKusick e Poul-Henning Kamp estenderam as camadas FFS e UFS do FreeBSD para adicionar ponteiros de bloco de 64 bits (permitindo que os volumes cresçam até 8 zebibytes ), blocos de tamanho variável (semelhantes a extensões ), campos de sinalização estendidos, adicionais carimbos de 'hora de nascimento', suporte de atributo estendido e POSIX1.e ACLs. O UFS2 se tornou a versão padrão do UFS a partir do FreeBSD 5.0. O FreeBSD também introduziu soft updates e a habilidade de fazer snapshots do sistema de arquivos para UFS1 e UFS2. Eles já foram portados para o NetBSD, mas eventualmente as atualizações suaves (chamadas de dependências suaves no NetBSD) foram removidas do NetBSD 6.0 em favor do mecanismo de registro de sistema de arquivos menos complexo chamado WAPBL (também conhecido como registro), que foi adicionado ao FFS no NetBSD 5.0. O OpenBSD tem suporte para soft updates desde a versão 2.9 e tem suporte UFS2 (FFS2) (sem ACLs) desde a versão 4.2. O OpenBSD agora tornou o UFS2 a versão padrão do UFS e será incluído na versão 6.7. Desde o FreeBSD 7.0, o UFS também suporta o journaling do sistema de arquivos usando o provedor gjournal GEOM . O FreeBSD 9.0 adiciona suporte para journaling leve em cima de soft updates (SU + J), o que reduz muito a necessidade de fsck em segundo plano e ACLs NFSv4.

FreeBSD, NetBSD, OpenBSD e DragonFly BSD também incluem o sistema Dirhash , desenvolvido por Ian Dowse. Este sistema mantém uma tabela hash na memória para acelerar as pesquisas de diretório. Dirhash alivia uma série de problemas de desempenho associados a grandes diretórios no UFS.

O Linux inclui uma implementação UFS para compatibilidade binária no nível de leitura com outros Unixes, mas como não há implementação padrão para as extensões do fornecedor para UFS, o Linux não tem suporte completo para gravação em UFS. O sistema de arquivos ext2 nativo do Linux foi inspirado no UFS1, mas não oferece suporte a fragmentos e não há planos para implementar soft updates. (Em alguns sistemas derivados do 4.4BSD, a camada UFS pode usar uma camada ext2 como uma camada de contêiner, assim como pode usar FFS e LFS.)

NeXTStep , que era derivado do BSD, também usava uma versão do UFS. Na Apple 's Mac OS X , que era disponível como uma alternativa para HFS + , o seu sistema de arquivos proprietário. No entanto, a partir do Mac OS X Leopard , não era mais possível instalar o Mac OS X em um volume formatado em UFS. Além disso, não é possível atualizar versões anteriores do Mac OS X instaladas em volumes formatados em UFS para o Leopard; a atualização requer a reformatação do volume de inicialização. Havia um limite de arquivo de 4 GB para discos formatados como UFS no Mac OS X. A partir do Mac OS X Lion , o suporte ao UFS foi completamente eliminado.

Veja também

• Comparação de sistemas de arquivos

Referências

Citações

Bibliografia

links externos

• Jeroen C. van Gelderen (2003-04-23). "Little UFS2 FAQ" . FreeBSD . Retirado 2013-04-08 .
• "Filesystems HOWTO: Other filesystems" . O Projeto de Documentação do Linux . 27-01-2007.
• O sistema de arquivos Solaris UFS , consulte também [1]
• Formato USF (sic) / UFS2
• Localidade e o sistema de arquivos rápido