ext4: come rendere conto dello spazio del filesystem?

Di recente ho formattato un'unità da 1,5 TB con l'intenzione di sostituire NTFS con ext4.

Poi ho notato che i file che ho salvato non si adattano alla nuova partizione.

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

La differenza di 1K blocchi significa uno spazio utilizzabile evidentemente inferiore di 22 GiB.

L'ho già giustiziato

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

con, ovviamente, nessun effetto in quanto non influisce sui blocchi che semplicemente non ci sono.

Tuttavia, fdisk riporta che la partizione ext4 copre l'intero 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 quindi ad esempio resize2fs segnala che non c'è "Niente da fare!"

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

Cosa sta usando quello spazio mancante?

Vediamo. La dimensione del dispositivo è 1.465.138.583½ kB = 1.500.301.909.504 B. Il filesystem è composto da 366.284.288 blocchi di 4096 B ciascuno, che è 1.500.300.443.648 B. Non so per cosa vengano utilizzati i restanti 1.465.856 B (1,4 MB) ? So che ci sono alcuni kB di spazio all'inizio per il bootloader.).

Il filesystem contiene 91.578.368 inode di 256 byte ciascuno, che occupa 23.444.062.208 B (circa 22 GB, suggerimento, suggerimento). Quindi ci sono 1.442.146.364 kB = 1.476.757.876.736 B per il contenuto del file. Ciò rappresenta 23.444.062.208 B + 1.476.757.876.736 B = 1.500.201.938.944 B. La dimensione rimanente è 98.504.704 B = 24.029 blocchi che si trova nell'intervallo corretto per essere la dimensione del giornale.

Come puoi vedere, tutto è giustificato. (Ok, quasi tutto, ma stiamo parlando di megabyte, non di gigabyte.)

Prima di tutto, la differenza nello spazio disponibile che stai vedendo non significa affatto che lo spazio sia "sprecato"; non è sprecato perché è di fondamentale importanza per il funzionamento del filesystem. Non è necessario confrontare Ext4 e NTFS in questo modo senza un grande "ma" specificando tutte le differenze di progettazione e strutturali tra i filesystem e anche le specifiche di ogni implementazione (ad esempio come ogni driver segnala spazio libero al livello VFS).

Immagina la partizione come uno spazio enorme in cui puoi inserire tutti i dati che hai. Se hai solo un pezzo di dati con una dimensione uguale alla partizione, puoi semplicemente scriverlo a partire dall'inizio della partizione ed essere cool con esso. Ma tu no. Invece potresti avere migliaia di piccoli file e tutti questi file raggruppati in modi diversi e ogni file associato a molti altri piccoli pezzi di dati (nome, data / ora e autorizzazioni), ecc. Devi organizzare il grande spazio del partizione in modo da poter raggiungere tutti questi dati in modo rapido ed efficiente. Inoltre, devi preoccuparti di come scrivere nuovi pezzi di dati e scartare i vecchi pezzi di dati in modo efficiente. Hai bisogno di strutture di dati .

E ci sono molte strutture di dati . Alcuni sono molto stupidi, altri ti consentono di recuperare i dati più rapidamente a spese di scritture più lente, altri consentono di scrivere più rapidamente a spese di letture, alcuni possono comunque essere molto bravi sia in lettura che in scrittura ma richiedono lunghe pause e sovraccarico inattivo mentre riorganizza i dati, ecc.

Sicuramente vuoi un sistema che:

1. È molto veloce per scrivere informazioni su di esso;
2. È molto veloce per recuperare informazioni da esso;
3. È bravo a organizzare e gestire le informazioni in essa contenute;
4. Fa buon uso dello spazio (partizione) in cui è archiviato il filesystem;
5. È resistente ai problemi hardware, in modo da poter recuperare la maggior parte o tutte le informazioni in caso di guasti parziali del sistema;
6. È resistente ai problemi del software, in modo che un bug in un'applicazione o un'applicazione dannosa installata non distrugga i dati in modo permanente;
7. È resistente agli errori umani, in modo che ti perdoni quando ordini accidentalmente al sistema di eliminare qualcosa che non dovresti (ovvero il cestino / cestino).

I filesystem ad alte prestazioni consentono letture e scritture molto veloci a scapito di un po 'di spazio. Alcune delle strutture dati più veloci utilizzate nei filesystem, come le tabelle hash e gli alberi B , sono molto complesse e riservano più spazio di quanto non sia effettivamente in uso per consentire accessi molto veloci.

Ext4 ha altre proprietà importanti. Non esiste un singolo punto di errore nel filesystem. Esistono molte copie di dati critici diffusi attraverso la partizione, mentre alcuni altri filesystem (non posso dire per NTFS) possono rendere illeggibili tutti i tuoi dati se si verifica un errore nel posto giusto. Inoltre, Ext4 riserva molto spazio per i tuoi dati proprio nella fase di creazione del filesystem, mentre NTFS cresce con i tuoi dati.

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

Questo messaggio indica che il disco utilizza il partizionamento in stile GPT e questo fdiskstrumento comprende solo lo stile MBR legacy.

Per evitare riformattazioni accidentali se i dischi partizionati con GPT sono collegati a vecchi sistemi non compatibili con GPT, lo schema di partizionamento GPT include un "MBR protettivo": una tabella di partizioni completamente falsa che sostanzialmente dice "questo disco è completamente utilizzato da un tipo di partizione non so nulla di "su qualsiasi sistema operativo o strumento che comprenda solo il partizionamento MBR.

Per ottenere una visualizzazione accurata della tabella delle partizioni /dev/sdb, utilizzare:

parted /dev/sdb print