dimensioni della partizione ext4 / discrepanze nello spazio libero


14

Durante la creazione di una partizione di backup da 250GiB per i miei dati, ho notato molte discrepanze tra la dimensione della partizione segnalata e lo spazio libero in Nautilus, gParted, df, tune2fs, ecc.

All'inizio ho pensato che fosse una confusione GiB / GB. Non lo era .

Poi ho pensato che potrebbero essere i blocchi riservati di ext4. Non lo era .

Sono completamente perplesso. Ecco alcune immagini. Ecco i passaggi:

  • Innanzitutto, NTFS. 524288000 settori x 512 byte / settore = 268435456000 byte = 268,4 GB = 250 GiB.

inserisci qui la descrizione dell'immagine inserisci qui la descrizione dell'immagine

Nautilus dice " Capacità totale: 250,0 GB " (anche se in realtà è GiB, non GB). A parte quel piccolo errore di etichettatura, finora, così buono

  • Ora, stessa partizione, formattata come ext4 con gparted:

inserisci qui la descrizione dell'immagine

I settori First, Last e Total sono gli stessi. È la stessa partizione da 250GiB. La dimensione utilizzata è 4.11GiB (blocchi riservati forse?)

inserisci qui la descrizione dell'immagine

No. Sembra che i blocchi riservati siano 12,7 GiB (~ 5%. Ahi! ). Ma ... perché la capacità totale ora è solo 246,1 GiB ??? . Tale differenza (sorta di) corrisponde ai 4,11 GiB riportati da gparted. Ma ... se non proviene da blocchi riservati, che cos'è? E perché gparted non ha segnalato quel 12.7GiB di spazio usato?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

dfcorrisponde a Nautilus nello spazio libero segnalato. Ma .. solo 188M usati? Non dovrebbe essere ~ 12 GB? E la capacità totale è ancora sbagliata. Quindi sono corso tune2fsa trovare alcuni indizi. (l'output irrilevante è ommited)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal 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 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 blocchi totali * 4096 byte / blocco = 268435456000 byte = 268,4 GB = 250 GiB. Corrisponde a gparted.

3276800 blocchi riservati = 13421772800 byte = 13,4 GB = 12,5 GiB. (Di nuovo, in qualche modo) corrisponde a Nautilus.

64459851 blocchi liberi = 264027549696 byte = 264,0 GB = 245,9 GiB. Perché? Non dovrebbe essere 250-12,5 = 237,5 (o 250- (12,5 + 4,11) = ~ 233)?

Rimozione dei blocchi riservati:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal 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 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

Come previsto, stesso numero di blocchi, 0 blocchi riservati, ma ... stessi blocchi gratuiti ? Non ho appena liberato 12,5 GiB?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

inserisci qui la descrizione dell'immagine

Sembra che l'ho fatto. Lo spazio disponibile è aumentato da 233 a 245,9 GiB. a gparted non importava affatto, mostrando esattamente le stesse informazioni! (inutile pubblicare uno screenshot identico)

Che casino enorme!

Ho provato a documentarlo nel miglior modo possibile ... Quindi, per favore qualcuno può darmi qualche idea su cosa sta succedendo qui?

  • Cosa mancano quei misteriosi 4.11 GiB mancanti in NTFS -> formattazione ext4?
  • Perché ci sono così tante discrepanze tra gparted, Nautilus, tune2fs, df?
  • Cosa c'è di sbagliato con la mia matematica? (domande in grassetto sparse questo post)

Qualsiasi aiuto è apprezzato. Anche se non riesco a capire cosa stia succedendo, sto seriamente considerando di rinunciare a ext4 a favore di NTFS per tutto tranne che per la mia / partizione.

Grazie!




@Uri Herrera: hai letto davvero la mia domanda, o almeno le prime righe? Questo non è un problema di GiB / GB. La partizione è 268,4 GB = 250,0GiB, non 246,1
MestreLion,

1
Un'altra risposta a cui puoi dare un'occhiata: askubuntu.com/questions/5335/…
enzotib,

Risposte:


13

Ci sono alcune cose che stanno succedendo qui. gparted riporta lo spazio effettivamente utilizzato / libero. Il kernel riduce il conteggio disponibile dallo spazio riservato. Dopo aver rimosso lo spazio riservato, il conteggio gratuito non è cambiato poiché i blocchi riservati erano già liberi; è solo che gli utenti non root non sono autorizzati a invadere quello spazio per impedire loro di causare problemi riempiendo il disco. I numeri degli gnomi sono un po 'traballanti a causa di un bug . Invece di riportare lo spazio usato che il kernel riporta (e df mostra), lo calcola sottraendo lo spazio libero dal totale. Questo fa sì che mostri lo spazio riservato usato.

I 4 GB mancanti sono effettivamente utilizzati nell'overhead di fs per ext4. NTFS inizialmente alloca solo una piccola quantità di spazio per la MFT e la fa crescere secondo necessità. La serie ext di filesystem, tuttavia, alloca spazio per la tabella degli inode (equivalente approssimativo della MFT) al momento del formato e non può crescere. Lo spazio mancante dallo spazio totale riportato è la tabella degli inode. Il bit rimanente di spazio utilizzato proviene dal journal (di solito 128 mb) e ridimensiona gli inode.


Grazie, +1 per aver risolto alcuni dei misteri! Ma se i ~ 4 GB sono sovraccarichi del filesystem, perché alcuni di essi (3,9 GB) vengono dedotti dallo spazio totale, mentre 188 MB vengono visualizzati come effettivamente utilizzati? Quale (o entrambi) è il sovraccarico? E perché gestito diversamente? Inoltre, dfanche con sudo, mostra la capacità totale (247 GB) e lo spazio utilizzato (188 MB) come Nautilus. Quindi se è un bug, non è solo lo gnomo.
MestreLion,

Ho pensato che i 188 MB fossero il sovraccarico (rispetto ai 72 MB di NTFS). Ma se l'overhead NTFS aumenterà dopo il tempo, ciò significa che Nautilus in seguito riferirà che la sua capacità totale si sta riducendo ?
MestreLion,

Correzione: df mostra sempre lo spazio disponibile, indipendentemente da chi lo gestisce. Per visualizzare lo spazio libero (== spazio disponibile + spazio riservato), utilizzare stat -f /media/BACKUP.
Marius Gedminas,

Risposta modificata per chiarire. E credo che NTFS riporterà solo più spazio utilizzato, non ridurrà il totale man mano che la MFT cresce. @Marius, neanche questo è corretto. statfs () e quindi sia df che stat -f mostrano entrambi lo spazio disponibile senza contare i blocchi riservati. Avrei giurato che si adeguasse anche alla quota e variava la sua risposta in base all'utente chiamante, ma hai ragione a riguardo; non conta la quota e non importa come lo chiama l'utente.
psusi,

@psusi: quindi ho ~ 3.9GiB di tabella di inode e ~ 188MB di journal + qualcosa? E Nautilus sottrae la tabella degli inode da Dimensione totale, mentre riporta il giornale come spazio utilizzato? E gparted li riporta come un singolo 4.11GiB di spazio usato? È corretto? In tal caso, ho solo desiderato che Nautilus gestisse entrambe le spese generali nello stesso modo ... o entrambe sottratte dal totale o entrambe contate come "spazio utilizzato" (preferibilmente).
MestreLion,

7

Innanzitutto, i blocchi riservati non sono blocchi utilizzati per la gestione interna del filesystem.

I blocchi riservati sono semplicemente riservati root, in modo da garantire che i servizi che utilizzano file su quella partizione non possano essere esclusi dallo spazio da un utente non amministratore che riempie tutto lo spazio.

Anche senza blocchi riservati ( -m 0) c'è sempre una parte dello spazio utilizzato per la gestione interna del filesystem, non posso dire quanto, non ho una conoscenza così profonda.

Inoltre, Gparted viene eseguito come root, quindi vede i blocchi riservati come gratuiti. Nautilus , eseguito come utente, li vede come non liberi.

Ok, la risposta di @psusi è molto chiara, non ho nulla da aggiungere.


Humm, molto istruttivo, +1. Almeno questo risolve alcuni dei problemi che ho riscontrato. Vedere i blocchi riservati come un "limite" per non-root anziché "blocchi usati" rende le letture gparted, df e tune2fs (e sensate). Rimangono tuttavia alcune domande, in particolare i 4 GB di spazio utilizzato / capacità totale.
MestreLion,

1
Inoltre, ho letto da qualche parte (uno di quei vecchi "perché non hai bisogno di deframmentare la tua partizione Linux ogni mese" forse HOWTO?) Che riservare il 5% di spazio per root dà un po 'di respiro agli algoritmi di allocazione extN e quindi evita la frammentazione.
Marius Gedminas,

1

Prova a ridurre la dimensione della partizione di alcuni megabyte usando gparted, quindi aumentandola nuovamente alla sua dimensione originale. Ciò può far sì che altre applicazioni leggano correttamente le dimensioni. Recentemente ho corretto un errore di 50 GB in questo modo!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.