ext4: Como explicar o espaço do sistema de arquivos?

Question

Eu recentemente formatei um drive de 1,5 TB com a intenção de substituir o ntfs pelo ext4.

Então notei que os arquivos que salvei não se encaixam na nova partição.

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

Essa diferença de blocos de 1K significa um espaço útil menor de 22 GiB.

Eu já executei

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

com, sem surpresa, nenhum efeito, pois isso não afeta os blocos que simplesmente não estão lá.

Ainda assim, o fdisk informa que a partição ext4 cobre todo o disco.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

E assim e. g. resize2fs relata que não há "nada para fazer!"

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

O que está usando esse espaço ausente?

    

Answer 1

Vamos ver. O tamanho do dispositivo é de 1.465.138.583½ kB = 1.500.301.909.504 B. O sistema de arquivos consiste em 366.284.288 blocos de 4096 B cada, que é 1.500.300.443.648 B. Não sei o que os 1.465.856 B restantes (1,4 MB) são usados para (cópias adicionais do superbloco "Eu sei que existem alguns kB de espaço no começo para o bootloader.).

O sistema de arquivos contém 91.578.368 inodes de 256 bytes cada, que ocupa 23.444.062.208 B (cerca de 22 GB, dica, sugestão). Então há 1,442,146,364 kB = 1,476,757,876,736 B para o conteúdo do arquivo. Isso representa 23.444.062.208 B + 1.476.757.876.736 B = 1.500.201.938.944 B. O tamanho restante é de 98.504.704 B = 24.029 blocos, que está no intervalo correto para ser o tamanho do diário.

Como você pode ver, tudo é contabilizado. (Ok, quase tudo, mas estamos falando de megabytes, não de gigabytes.)

    

Answer 2

Em primeiro lugar, a diferença no espaço disponível que você está vendo não significa, em absoluto, que haja espaço "desperdiçado"; não é desperdiçado porque é de fundamental importância que o sistema de arquivos funcione. Você não deve comparar Ext4 e NTFS desta forma sem um "mas" muito grande especificando todas as diferenças estruturais e de design entre os sistemas de arquivos e também especificidades de cada implementação (por exemplo, como cada driver reporta espaço livre para a camada VFS). >

Imagine a partição como um espaço enorme onde você pode colocar qualquer parte de dados que tenha. Se você tem apenas um pedaço de dados com um tamanho igual à partição, você poderia escrevê-lo a partir do início da partição e ficar bem com ele. Mas você não Em vez disso, você pode ter milhares de arquivos pequenos, e todos esses arquivos agrupados de maneiras diferentes, e cada arquivo associado a muitos outros pequenos dados (nome, data / hora e permissões), etc. Você precisa organizar o grande espaço do arquivo. partição para que você possa acessar todos esses dados com rapidez e eficiência. Além disso, você precisa se preocupar em como criar novos dados e descartar dados antigos de maneira eficiente. Você precisa de estruturas de dados .

E há muitas estruturas de dados . Alguns deles são muito burros, outros permitem recuperar dados mais rapidamente à custa de gravações mais lentas, outros permitem escrever mais rapidamente às custas de leituras, alguns ainda podem ser muito bons em leituras e gravações, mas exigem longas pausas e sobrecarga ociosa enquanto reorganiza os dados, etc.

Você certamente deseja um sistema que:

1. É muito rápido para escrever informações sobre ele;
2. É muito rápido para recuperar informações dele;
3. É bom em organizar e gerenciar as informações armazenadas nele;
4. Faz bom uso do espaço (partição) onde o sistema de arquivos é armazenado;
5. É resiliente contra problemas de hardware, para que você ainda obtenha a maioria ou todas as suas informações em falhas parciais do sistema;
6. É resiliente contra problemas de software, para que um bug em um aplicativo ou um aplicativo mal-intencionado instalado não destrua seus dados permanentemente;
7. É resiliente contra erros humanos, de modo que perdoa quando você acidentalmente ordena que o sistema exclua algo que você não deveria (ou seja, a lixeira / lixeira).

Sistemas de arquivos de alto desempenho permitem leituras e gravações muito rápidas às custas de algum espaço. Algumas das estruturas de dados mais rápidas usadas nos sistemas de arquivos, como as tabelas hash e B-trees , são muito complexas e reservam mais espaço do que realmente estão em uso para permitir acessos muito rápidos.

O Ext4 tem outras propriedades importantes. Não há ponto único de falha no sistema de arquivos. Existem muitas cópias de dados críticos espalhados pela partição, enquanto alguns outros sistemas de arquivos (não posso dizer para NTFS) podem tornar todos os seus dados ilegíveis se uma falha acontecer no ponto certo. Além disso, o Ext4 reserva muito espaço para seus dados diretamente no estágio de criação do sistema de arquivos, enquanto o NTFS cresce com seus dados.

    

Answer 3

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

Esta mensagem indica que o disco usa o particionamento estilo GPT, e essa ferramenta fdisk entende apenas o estilo legado do MBR.

Para evitar reformatações acidentais, se os discos particionados por GPT estiverem conectados a sistemas não compatíveis com GPT, o esquema de particionamento GPT inclui um "MBR protetor": uma tabela de partição completamente falsa que basicamente diz "este disco está completamente em uso por um tipo de partição você não sabe nada sobre "para qualquer sistema operacional ou ferramenta que só entende o particionamento MBR.

Para obter uma exibição precisa da tabela de partições do seu /dev/sdb , use:

parted /dev/sdb print