O ext4 é mais caro que o NTFS?


11

Acabei de converter uma partição NTFS para ext4, no entanto, o espaço total parece reduzido de 421G para 415G. Para onde foi o 6G? E, o espaço reservado é aumentado para 199M no ext4, muito maior em comparação aos 78M no NTFS, por quê?

A partição é usada principalmente para filmes / músicas; portanto, a maioria dos arquivos é muito grande (> 10 milhões cada). Eu quero usar o sistema de arquivos ext4, há alguma sugestão?

mkfs.ntfs:
    /dev/sdb4             421G   78M  421G   1% /mnt/mmedia

mkfs.ext4:
    /dev/sdb4             415G  199M  393G   1% /mnt/mmedia
                       (415G - 199M == 393G ?)

Também é estranho que o tamanho restante do ext4 seja 393G, não deveria ser 415G ou 414G? O que aconteceu com os 22G desaparecidos? Comparado ao NTFS, o ext4 consumiu 6,6% do espaço total, isso é realmente um grande negócio.

A questão é:

  1. Para que o 6G é usado principalmente, para diário, redundância ou indexação?
  2. Por que o espaço restante 393G não 415G? Existe um buraco 22G que é bastante grande.
  3. Quais parâmetros você recomendaria se essa partição ext4 for usada para armazenar arquivos de filme / música? Dizem que o ext4 tem um desempenho melhor que o ext3 para partições grandes, é verdade? Não voltarei ao ext2 que não é diário.

Respostas:


8

Para que o 6G é usado principalmente, para diário, redundância ou indexação?

(Ainda não conhecido.)

Por que o espaço restante 393G não 415G? Existe um buraco 22G que é bastante grande.

São 5% de blocos reservados para superusuário, usados ​​para evitar fragmentação. Você pode ajustá-lo para 1% em mkfs.ext4 -m 1.

Quais parâmetros você recomendaria se essa partição ext4 for usada para armazenar arquivos de filme / música?

Você pode especificar uma opção de uso para mkfs.ext4, por exemplo mkfs.ext4 -T large_file, isso permitirá que mkfs.ext4 decida parâmetros para partições que contêm arquivos grandes.


1
o 6G será para as listas de inodes.
Sirex

1
Blocos reservados também limitam o impacto de um ataque de negação de serviço em que usuários regulares preenchem um disco até o ponto em que os arquivos de log não podem mais ser gravados. O espaço reservado, no mínimo, fornecerá à raiz logs suficientes para capturar o usuário ofensivo.
precisa saber é o seguinte

Meu /etc/mke2fs.conf fala dos parâmetros "largefile" e "largefile4" para -T, não para "large_file".
user1338062

4
  1. Os 6GB são inodes. o padrão ext4 é 1/64 (1,56%) para inodes, cada 256B; pode preencher com arquivos de 16 KB
  2. O espaço disponível no df exclui o espaço reservado para raiz, 5% por padrão, use tune2fs -m
  3. mkfs.ext4 -m 0 -N 4000000 / dev / Whatever # reformats, 0 reservado, 4 milhões de inodes usa 1 GB
  4. ext4 fsck é muito mais rápido que ext3; além disso, você não notará nenhuma diferença

Cada arquivo / diretório precisa de 1 inode. Você não pode alterar o número de inodes após criar um sistema de arquivos ext. Até 1000000 inodes seriam suficientes para essa partição, se você a usar apenas para filmes e música.

A tabela de arquivos mestre do NTFS (MFT) é um pouco mais flexível, portanto, o NTFS pode incluir mais dados por padrão.

A única boa razão para usar o NTFS no Linux é compartilhar arquivos com o Windows. Ele funcionará bem para mídia, mas não possui vários recursos UNIX, portanto não é adequado para uso geral no Linux. Não compile!


Each inode 256B, so can fill with 16KB filesVocê quer dizer que existem 16K-256 = 16128 bytes livres em cada inode?
Xiè Jìléi

1
Quero dizer, se você usa 1/64 de um dispositivo para tabelas de inodes, e cada inode é 256B, então você recebe um inode por 16 KB de dispositivo ... na verdade, é 1 inode por 15.75 KB do dispositivo restante, mas perto o suficiente. Então você tem inodes suficientes para encher o disco inteiro com arquivos de 16 KB. Se você espera ter arquivos muito maiores, por exemplo, vídeos, pode se contentar com menos inodes e salvar talvez alguns GB do dispositivo.
Sam Watkins

3

Sim, este é um pequeno tópico arrumado. Cada sistema de arquivos implementa suas estruturas de dados de maneira diferente. Algo interessante que você pode tentar é formatar uma partição com vários sistemas de arquivos e comparar. O espaço "livre" será diferente. Além disso, conforme você os preenche, haverá uma diferença na sobrecarga de armazenamento e, de certa forma, quanto espaço é necessário para armazenar o mesmo arquivo PODE diferir dependendo do sistema de arquivos. Geralmente, quando você formata um sistema de arquivos, também pode selecionar alguns parâmetros para a organização - isso também afeta.

A resposta para sua pergunta é uma daquelas respostas "depende" . Acho que, acima de tudo, 6/400 GB não é uma variação terrível, mas, na verdade, isso é perceptível. Ainda o espaço de armazenamento está ficando cada vez mais barato. Mas acho que os sistemas de arquivos provavelmente estão ficando mais pesados, pois queremos recursos mais sofisticados. Eu suspeito que ext2 é um pouco mais enxuto que ext4. Eu estaria interessado em ver alguns números do mundo real sobre isso. Obviamente, essa "eficiência" tem um preço (a maior delas é que não é registrada em diário e, portanto, mais rápida e mais facilmente corrompida).

Quanto ao motivo pelo qual o ext4 ocupa mais espaço nesse caso, presumo que seus custers de armazenamento no NTFS foram configurados para endereçar seu espaço de armazenamento com blocos muito maiores do que os parâmetros ext4 solicitados. Se isso for verdade, você deverá obter um uso de armazenamento mais eficiente se tiver muitos arquivos relativamente pequenos.

Basta dizer que todo o assunto continua. Se você quiser obter mais informações, sugiro dar uma olhada em várias páginas da Wikipédia comparando os sistemas de arquivos por aí. Assim como as páginas de manual de cada FS em que você está interessado.

Espero que você ache isso útil.


1

Super-blocos reservados é uma coisa, mas não a quantidade a que você está se referindo. Alterar os super-blocos reservados não aparece no "espaço total disponível" ... isso não muda. É o número de inodes x seu tamanho. No ext4, por padrão, espere algo como 256 bytes por inode e 400 GB , Suponho que mkfs.ext4 faça ~ 25-30 mill talvez.Use dumpe2fs -h para ver o número atual.Este compõe os 6 GB que você está perdendo e não os bloqueios reservados de quem alguém está falando (por exemplo, inode- contagem x tamanho do inode b / 1024 ^ 3) GBs.

Suspeito que a saída df -h esteja relacionada a alguma claudicação; p Tente fazê-lo novamente e especifique metade dos seus nós-i (você pode fazê-lo com segurança e ainda mais se estiver em negrito), mas esteja ciente de que muitos diretórios podem fazer você ficar sem inodes antes do espaço.

Por exemplo. O ext4 reserva vários inodes 93-4?) por diretório, supondo que você pretenda armazenar mais do que apenas um ou dois arquivos e, portanto, tornando-o mais eficiente. Se você tiver 1 milhão de pastas com 1 milhão de arquivos, você ficará sem inodes nesse layout antes de realmente ficar sem espaço. Normalmente, os inodes são usados ​​apenas dentro de alguns por cento do espaço, mas podem aumentar para 35%; portanto, dividir por dois é bastante seguro para usuários de desktop, mas não faz mais para estar do lado seguro.

Aqui está um exemplo:

RAW de 415 GB (dev / sdb1 diz) mkfs.ext4 -m0 -Ndefault # / 2 -Lext4-1 -O extensão, dir_index, large_file, sparse_super, uninit_bg / dev / sdb1

as opções ajudarão em arquivos / partições grandes com a mídia, digamos. uninit_bg é para kernels recentes. Isso é publicado mesmo que seja antigo para futuros leitores.

Malina Salina


0

Eu tinha um sistema de arquivos NTFS (completo) contendo cerca de 1000 GB de dados com apenas algumas centenas de megabytes livres. Mesmo que a capacidade formatada do ext4 fosse muito menor do que ntfs, lembro que, quando copiei tudo, ainda tinha cerca de 70 GB livres no ext4, mesmo que a capacidade formatada fosse menor. (Lembre-se de que o NTFS estava cheio). Não posso prometer que isso aconteceu com você, mas pelo menos para os arquivos que eu tinha o ext4, foi realmente um poupador de espaço! :)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.