“arquivo de gravação única”: ext2 vs ext4 ^ has_journal vs

Question

resumo

Suponha que alguém esteja configurando um drive externo para ser um "write-once archive": um pretende reformatá-lo, copiar alguns arquivos que (nunca) serão atualizados, e depois colocá-lo de lado até eu precisar ler algo ( que poderia ser um longo tempo ou nunca) do arquivo de outra caixa linux. Eu também quero ser capaz de obter o máximo de espaço no arquivo possível no arquivo; Ou seja, eu quero que o sistema de arquivos consuma o menor espaço livre possível para seus próprios propósitos.

pergunta específica 1: qual sistema de arquivos seria melhor para este usecase: ext2 ou ext4 sem journaling?

Desde que eu nunca fiz o último antes (eu costumo fazer esse tipo de coisa com GParted ), apenas para tenha certeza:

pergunta específica 2: é "o caminho" para instalar o diário sem ext4 mke2fs -t ext4 -O ^has_journal /dev/whatever ?

pergunta geral 3: existe um sistema de arquivos melhor para este uso? ou algo totalmente diferente?

detalhes

Eu tenho arquivos buncha de projetos antigos em caixas mortas (que, portanto, nunca serão atualizados) salvos em várias unidades externas. Tamanho coletivamente (arquivos) ~ = 250 GB. Isso é muito grande para DVDs (ou seja, exigiria muitos - a menos que esteja faltando alguma coisa), e eu não tenho uma unidade de fita. Por isso, estou configurando uma unidade externa USB2 HFS antiga como arquivo. Eu preferiria usar um sistema de arquivos "real Linux", mas também preferiria um sistema de arquivos que

1. consome o mínimo de espaço na unidade de arquivamento (já que é praticamente grande o suficiente para armazenar o que eu quero colocar nele.
2. será legível a partir de qualquer caixa (supostamente Linux) que eu utilizarei no futuro.

Eu planejei fazer a seguinte sequência com o GParted: [delete partições antigas, crie uma nova partição, crie o sistema de arquivos ext2, redigite]. No entanto, eu li aqui que

recent Linux kernels support a journal-less mode of ext4
which provides benefits not found with ext2

e anotou o seguinte texto em man mkfs.ext4

"mke2fs -t ext3 -O ^has_journal /dev/hdXX"
will create a filesystem that does not have a journal

Então, eu gostaria de saber

1. Qual sistema de arquivos seria melhor para este usecase: ext2 ou ext4 sem registro no diário?
2. Supondo que eu vá ext4-minus-journal, é a linha de comando para instalá-lo mke2fs -t ext4 -O ^has_journal /dev/whatever ?
3. Existe outro sistema de arquivos ainda melhor para este uso?

Answer 1

Eu não concordo com as recomendações do squashfs. Você não costuma escrever um squashf em um dispositivo de bloco raw; pense nisso como um arquivo tar facilmente legível. Isso significa que você ainda precisaria de um sistema de arquivos subjacente.

ext2 tem várias limitações severas que limitam sua utilidade hoje; Portanto, eu recomendaria ext4 . Como isso é destinado ao arquivamento, você criaria arquivos compactados para executá-lo; Isso significa que você teria um pequeno número de arquivos razoavelmente grandes que raramente mudam. Você pode otimizar para isso:

• especifique -I 128 para reduzir o tamanho de inodes individuais, o que reduz o tamanho da tabela de inodes.
• Você também pode jogar com a opção -i para reduzir ainda mais o tamanho da tabela de inodes. Se você aumentar este valor, haverá menos inodes criados e, portanto, a tabela de inodes também será menor. No entanto, isso significaria que o sistema de arquivos desperdiça mais espaço, em média, por arquivo. Isto é, portanto, um pouco de compromisso.
• Você pode, de fato, desligar o diário com -O ^has_journal . Se você seguir esse caminho, no entanto, recomendo que você defina opções padrão para montar o sistema de arquivos somente leitura; você pode fazer isso em fstab , ou você pode usar tune2fs -E mount_opts=ro para gravar um padrão no sistema de arquivos (você não pode fazer isso em mkfs time)
• você deve, obviamente, compactar seus dados em arquivos compactados, para que o desperdício de inodes não seja um problema tão ruim quanto poderia ser. Você poderia criar imagens squashfs, mas xz comprime melhor, então eu recomendaria arquivos tar.xz.
• Você também pode reduzir o número de blocos reservados com a opção -m para mkfs ou tune2fs . Isso define a porcentagem (definida como 5 por padrão), que é reservada apenas para a raiz . Não defina a zero; o sistema de arquivos requer algum espaço para uma operação eficiente.

Answer 2

O SquashFS é um sistema de arquivos de somente leitura que se ajusta bem aos seus requisitos, está no kernel há alguns anos e já é amplamente usado (por exemplo, em LiveCDs). A documentação mais recente das ferramentas de espaço do usuário está no GitHub . Da documentação:

Squashfs is a highly compressed read-only filesystem for Linux. It uses either gzip/xz/lzo/lz4 compression to compress both files, inodes and directories. Inodes in the system are very small and all blocks are packed to minimise data overhead. Block sizes greater than 4K are supported up to a maximum of 1Mbytes (default block size 128K).

Squashfs is intended for general read-only filesystem use, for archival use (i.e. in cases where a .tar.gz file may be used), and in constrained block device/memory systems (e.g. embedded systems) where low overhead is needed.

    

Answer 3

Você provavelmente seria melhor servido por um sistema de arquivos compactado.

Existem maneiras de compactar vários sistemas de arquivos Linux ( FUSE pode fazer isso), mas como isso será somente leitura depois de criá-lo, você pode considerar squashfs . Você cria o sistema de arquivos com o mksquashfs.

O Linux tem o squashfs no kernel principal desde o 2.6.alguma coisa, então deve funcionar de praticamente qualquer caixa do Linux.

Eu acho que btrfs pode fazer compactação instantânea, mas eu nunca usei isso sozinho. ZFS can - Eu mesmo o uso no FreeBSD - embora seja necessária alguma configuração antes que uma máquina Linux possa lê-lo.

No que diz respeito ao ext2 vs ext4 sem journalling, eu não poderia dizer - eu uso o JFS e o XFS fora de hábito no Linux.