ReiserFS - ReiserFS

ReiserFS 3.6
Desenvolvedor (s) Namesys
Nome completo ReiserFS
Introduzido 2001 ; 20 anos atrás com Linux 2.4.1 ( 2001 )
Identificador de partição
Estruturas
Conteúdo do diretório Árvore B +
Alocação de arquivo Bitmap
Limites
Máx. tamanho do volume 16 TiB
Máx. tamanho do arquivo 1 EiB (8 TiB em sistemas de 32 bits)
Máx. número de arquivos 2 32 −3 (~ 4 bilhões)
Máx. comprimento do nome do arquivo 4032 bytes, limitado a 255 pelo Linux VFS
Caracteres permitidos em nomes de arquivos Todos os bytes exceto NUL e '/'
Recursos
Datas gravadas Modificação (mtime), mudança de metadados (ctime), acesso (atime)
Intervalo de datas 14 de dezembro de 1901 - 18 de janeiro de 2038
Resolução de data 1 s
Forks Atributos estendidos
Permissões do sistema de arquivos Permissões Unix, ACLs e atributos de segurança arbitrários
Compressão transparente Não
Criptografia transparente Não
Outro
Sistemas operacionais suportados Linux, ReactOS

ReiserFS é um sistema de arquivos com registro em diário de propósito geral, inicialmente projetado e implementado por uma equipe da Namesys liderada por Hans Reiser . ReiserFS é atualmente compatível com Linux (sem suporte de quota) licenciado como GPLv2 . Introduzido na versão 2.4.1 do kernel Linux , foi o primeiro sistema de arquivos de registro em diário a ser incluído no kernel padrão. ReiserFS foi o sistema de arquivos padrão em Novell 's SUSE Linux Enterprise até Novell decidiu se mudar para ext3 em 12 de outubro de 2006, para futuros lançamentos.

A Namesys considerou o ReiserFS versão 3.6 que introduziu um novo formato em disco permitindo tamanhos de arquivos maiores, agora ocasionalmente referido como Reiser3, como estável e completo de recursos e, com exceção de atualizações de segurança e correções de bugs críticos, interrompeu o desenvolvimento para se concentrar em seu sucessor, Reiser4 . A Namesys fechou as portas em 2008 após a condenação de Reiser por assassinato. O produto agora é mantido como código aberto por voluntários. O reiserfsprogs 3.6.27 foi lançado em 25 de julho de 2017.

Recursos

No momento de sua introdução, o ReiserFS oferecia recursos que não estavam disponíveis nos sistemas de arquivos Linux existentes. Um exemplo é o empacotamento da cauda - um esquema para reduzir a fragmentação interna . O empacotamento da cauda pode ter um impacto significativo no desempenho. O Reiser4 pode ter melhorado isso ao empacotar as caudas onde não afetasse negativamente o desempenho.

Projeto

ReiserFS armazena metadados de arquivo ("itens de estatísticas"), entradas de diretório ("itens de diretório"), listas de blocos de inode ("itens indiretos") e caudas de arquivos ("itens diretos") em uma única árvore B + combinada codificada por um ID de objeto universal. Os blocos de disco alocados aos nós da árvore são "blocos internos formatados". Blocos para nós folha (nos quais os itens são embalados ponta a ponta) são "blocos folha formatados". Todos os outros blocos são "blocos não formatados" contendo o conteúdo do arquivo. Os itens de diretório com muitas entradas ou itens indiretos que são muito longos para caber em um nó transbordam para o vizinho folha direito. A alocação de blocos é rastreada por bitmaps de espaço livre em locais fixos.

Por outro lado, o ext2 e outros sistemas de arquivos do tipo Berkeley FFS da época simplesmente usavam uma fórmula fixa para calcular as localizações dos inodes, limitando assim o número de arquivos que eles podem conter. A maioria desses sistemas de arquivos também armazena diretórios como listas simples de entradas, o que faz pesquisas de diretório e atualiza operações de tempo linear e diminui o desempenho em diretórios muito grandes. O design de árvore B + única no ReiserFS evita esses dois problemas devido às melhores propriedades de escalabilidade.

atuação

Comparado com ext2 e ext3 na versão 2.4 do kernel Linux, ao lidar com arquivos abaixo de 4  KiB e com compactação de cauda habilitada, ReiserFS pode ser mais rápido.

Antes do Linux 2.6.33, o ReiserFS usava fortemente o big kernel lock (BKL) - um bloqueio global de todo o kernel - que não se adapta bem a sistemas com múltiplos núcleos, já que as partes críticas do código são executadas apenas por um núcleo de cada vez .

Uso

ReiserFS era o sistema de arquivos padrão no SuSE Linux desde a versão 6.4 (lançada em 2000), até a mudança para ext3 no SUSE Linux Enterprise 10.2 e openSUSE 11, anunciado em 2006.

Jeff Mahoney da SUSE escreveu uma postagem em 14 de setembro de 2006 propondo mudar do ReiserFS para o ext3 para o sistema de arquivos de instalação padrão. Alguns motivos que ele mencionou foram escalabilidade, "problemas de desempenho com atributos estendidos e ACLs ", "uma comunidade de desenvolvimento pequena e cada vez menor" e que " Reiser4 não é uma atualização incremental e requer uma reformatação, o que não é razoável para a maioria das pessoas." Em 4 de outubro, ele escreveu um comentário em um blog para esclarecer alguns problemas. Ele escreveu que sua proposta de troca não estava relacionada ao fato de Hans Reiser estar sendo julgado por assassinato. Mahoney escreveu que "estava preocupado que as pessoas fizessem uma conexão onde não existia" e que "o momento é inteiramente coincidente e a motivação não está relacionada".

Crítica

Algumas operações de diretório (incluindo unlink (2)) não são síncronas no ReiserFS, o que pode resultar em corrupção de dados com aplicativos que dependem fortemente de bloqueios baseados em arquivo (como agentes de transferência de correio qmail e Postfix ) se a máquina parar antes de sincronizar o disco.

Não há programas para desfragmentar especificamente um sistema de arquivos ReiserFS, embora ferramentas tenham sido criadas para copiar automaticamente o conteúdo de arquivos fragmentados, na esperança de que mais blocos contíguos de espaço livre possam ser encontrados. No entanto, uma ferramenta "repacker" foi planejada para o próximo sistema de arquivos Reiser4 para lidar com a fragmentação de arquivos. Com o surgimento dos discos de estado sólido, esse problema se tornou irrelevante.

fsck

O processo de reconstrução da árvore do fsck do ReiserFS atraiu muitas críticas da comunidade * nix: Se o sistema de arquivos ficar tão corrompido que sua árvore interna se torna inutilizável, executar uma operação de reconstrução da árvore pode corromper ainda mais os arquivos existentes ou introduzir novas entradas com conteúdos inesperados, mas esta ação não faz parte da operação normal ou de uma verificação normal do sistema de arquivos e deve ser explicitamente iniciada e confirmada pelo administrador.

As imagens ReiserFS v3 não devem ser armazenadas em uma partição ReiserFS v3 (por exemplo, backups ou imagens de disco para emuladores) sem transformá-los (por exemplo, compactando ou criptografando) para evitar confundir a reconstrução. A reformatação de uma partição ReiserFS v3 existente também pode deixar para trás dados que podem confundir a operação de reconstrução e fazer com que os arquivos do sistema antigo reapareçam. Isso também permite que usuários mal-intencionados armazenem arquivos intencionalmente que irão confundir o reconstrutor. Como os metadados estão sempre em um estado consistente após uma verificação do sistema de arquivos, a corrupção aqui significa que o conteúdo dos arquivos é mesclado de maneiras inesperadas com os metadados do sistema de arquivos contidos. O sucessor do ReiserFS, Reiser4, corrige esse problema.

Problemas anteriores

ReiserFS em versões do kernel Linux anteriores a 2.4.16 eram consideradas instáveis ​​pela Namesys e não eram recomendadas para uso em produção, especialmente em conjunto com NFS .

As primeiras implementações do ReiserFS (antes daquelas no Linux 2.6.2) também eram suscetíveis a riscos de gravação fora de ordem. Mas a implementação de registro no diário atual no ReiserFS está agora no mesmo nível do nível de registro no diário "ordenado" do ext3 .

Veja também

Referências

links externos