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?
filesystems
disk-usage
ext4
misc
fonte
fonte
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:
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.
fonte
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:fonte