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

Formatei recentemente uma unidade de 1,5 TB com a intenção de substituir o NTFS pelo ext4.

Então notei que os arquivos salvos 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 evidente e menos útil de 22 GiB.

Eu já executei

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

sem surpresa, nenhum efeito, pois isso não afeta os blocos que simplesmente não existem.

Ainda assim, o fdisk relata 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, por exemplo, resize2fs relata que não há "nada a 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?

Vamos ver. O tamanho do dispositivo é 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 para que os 1.465.856 B restantes (1,4 MB) são usados ​​(cópias adicionais do superbloco ? Eu sei que há alguns kB de espaço no começo para o gerenciador de inicialização.).

O sistema de arquivos contém 91.578.368 inodes de 256 bytes cada, o que ocupa 23.444.062.208 B (cerca de 22 GB, dica, dica). Depois, 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 é 98.504.704 B = 24.029 blocos, que está no intervalo certo para ser o tamanho do diário.

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

Primeiro, a diferença de espaço disponível que você está vendo não significa que exista espaço "desperdiçado"; não é desperdiçado porque é de importância fundamental o funcionamento do sistema de arquivos. Você não deve comparar o Ext4 e o NTFS dessa maneira sem um "mas" muito grande, especificando todas as diferenças de design e estruturais entre os sistemas de arquivos e também as especificidades de cada implementação (por exemplo, como cada driver relata espaço livre na camada VFS).

Imagine a partição como um espaço enorme, onde você pode colocar quaisquer dados que tiver. Se você tiver apenas um dado com o tamanho igual à partição, basta escrevê-lo a partir do início da partição e ser legal 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ê deve organizar o grande espaço do partição para que você possa acessar todos esses dados de maneira rápida e eficiente. Além disso, você deve se preocupar em como escrever novos dados e descartar com eficiência dados antigos. Você precisa de estruturas de dados .

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

Você certamente quer um sistema que:

1. É muito rápido escrever informações nele;
2. É muito rápido 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 está armazenado;
5. É resistente a problemas de hardware, para que você ainda recupere a maioria ou todas as suas informações em caso de falhas parciais no sistema;
6. É resistente a problemas de software, para que um bug em um aplicativo ou aplicativo malicioso instalado não destrua seus dados permanentemente;
7. É resistente a erros humanos, de modo que o perdoa quando você acidentalmente ordena que o sistema exclua algo que não deveria (também conhecido como lixeira / lixeira).

Os sistemas de arquivos de alto desempenho permitem leituras e gravações muito rápidas, à custa de algum espaço. Algumas das estruturas de dados mais rápidas usadas em sistemas de arquivos, como tabelas de hash e árvores B , são muito complexas e reservam mais espaço do que realmente é usado para permitir acessos muito rápidos.

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

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 no estilo GPT e essa fdiskferramenta entende apenas o estilo MBR herdado.

Para evitar reformatações acidentais se os discos particionados por GPT estiverem conectados a sistemas antigos que não reconhecem a GPT, o esquema de particionamento da GPT inclui um "MBR protetor": uma tabela de partição completamente falsa que basicamente diz "este disco está sendo usado por um tipo de partição. não sei nada sobre "qualquer sistema operacional ou ferramenta que apenas entenda o particionamento do MBR.

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

parted /dev/sdb print