Ext4 è più costoso di NTFS?


11

Ho appena convertito una partizione NTFS in ext4, tuttavia lo spazio totale sembra ridotto da 421G a 415G. Dov'è finito il 6G? E, lo spazio riservato è cresciuto a 199M in ext4, molto più grande rispetto ai 78M in NTFS, perché?

La partizione viene utilizzata principalmente per film / musica, quindi la maggior parte dei file sono molto grandi (> 10 M ciascuno). Voglio usare il file system ext4, c'è qualche suggerimento?

mkfs.ntfs:
    /dev/sdb4             421G   78M  421G   1% /mnt/mmedia

mkfs.ext4:
    /dev/sdb4             415G  199M  393G   1% /mnt/mmedia
                       (415G - 199M == 393G ?)

È anche strano che la dimensione rimanente di ext4 sia 393G, non dovrebbe essere 415G o 414G? Cosa è successo al 22G scomparso? Rispetto a NTFS, ext4 ha consumato il 6,6% dello spazio totale, è davvero un grosso problema.

La domanda è:

  1. A cosa serve principalmente il 6G, per il journal, per la ridondanza o per l'indicizzazione?
  2. Perché lo spazio rimanente 393G non 415G? C'è un buco da 22G che è piuttosto grande.
  3. Quali parametri consiglieresti se questa partizione ext4 viene utilizzata per archiviare file di film / musica? Si dice che ext4 funzioni meglio di ext3 per partizioni di grandi dimensioni, è vero? Non tornerò a ext2 che non è journal.

Risposte:


8

A cosa serve principalmente il 6G, per il journal, per la ridondanza o per l'indicizzazione?

(Non ancora noto.)

Perché lo spazio rimanente 393G non 415G? C'è un buco da 22G che è piuttosto grande.

Sono blocchi riservati al 5% per superutente, che viene utilizzato per evitare la frammentazione. Puoi regolarlo all'1% di mkfs.ext4 -m 1.

Quali parametri consiglieresti se questa partizione ext4 viene utilizzata per archiviare file di film / musica?

È possibile specificare un'opzione di utilizzo su mkfs.ext4, ad esempio mkfs.ext4 -T large_file, ciò consentirà a mkfs.ext4 di decidere i parametri per le partizioni contenenti file di grandi dimensioni.


1
il 6G sarà per gli elenchi degli inode.
Sirex,

1
I blocchi riservati limitano anche l'impatto di un attacco Denial Of Service in cui gli utenti normali riempiono un disco al punto in cui i file di registro non possono più essere scritti. Lo spazio riservato fornirà almeno i log sufficienti di root per catturare l'utente offensivo.
MSalter

Il mio /etc/mke2fs.conf parla dei parametri "largefile" e "largefile4" per -T, non "large_file".
user1338062,

4
  1. 6 GB sono inode. ext4 è impostato su 1/64 (1,56%) per gli inode, ciascuno 256B; quindi può riempire con file da 16 KB
  2. Lo spazio disponibile df esclude lo spazio riservato per root, 5% per impostazione predefinita, utilizzare tune2fs -m
  3. mkfs.ext4 -m 0 -N 4000000 / dev / qualunque # # riformattati, 0 riservato, 4 milioni di inode utilizza 1 GB
  4. ext4 fsck è molto più veloce di ext3; a parte questo non noterai alcuna differenza

Ogni file / dir necessita di 1 inode. Non è possibile modificare il numero di inode dopo aver creato un filesystem ext. Anche 1000000 inode sarebbero sufficienti per quella partizione, se la utilizzerai solo per film e musica.

La tabella dei file master NTFS (MFT) è leggermente più flessibile, quindi NTFS può contenere più dati per impostazione predefinita.

L'unico buon motivo per usare NTFS su Linux è condividere file con Windows. Funzionerà bene per i media, ma manca di varie funzionalità UNIX, quindi non è adatto a scopi generali su Linux. Non compilare su di esso!


Each inode 256B, so can fill with 16KB filesVuoi dire che ci sono 16K-256 = 16128 byte liberi in ciascun inode?
Xiè Jìléi,

1
Voglio dire, se usi 1/64 di un dispositivo per le tabelle degli inode e ogni inode è 256B, otterrai un inode per 16 KB di dispositivo ... in realtà è 1 inode per 15,75 KB del dispositivo rimanente, ma abbastanza vicino. Quindi hai abbastanza inode per riempire l'intero disco con file da 16 KB. Se prevedi di avere file molto più grandi, ad esempio video, puoi accontentarti di un minor numero di inode e salvare forse qualche GB dal dispositivo.
Sam Watkins,

3

Sì, questo è un piccolo argomento pulito. Ogni file system implementa le sue strutture di dati in modo diverso. Qualcosa di pulito che puoi provare è la formattazione di una partizione con vari file system e il confronto. Lo spazio "libero" sarà diverso. Inoltre, man mano che li riempi, ci sarà una differenza nell'overhead di archiviazione e quindi, in un certo senso, quanto spazio è necessario per archiviare lo stesso file PU file differire a seconda del file system. Di solito, quando formatti un file system puoi anche selezionare alcuni parametri per come deve essere organizzato, anche questo ha un impatto.

La risposta alla tua domanda è una di quelle risposte "dipende" . Penso che, soprattutto, 6/400 GB non siano una varianza terribile, ma in effetti è evidente. Ancora lo spazio di archiviazione sta diventando sempre più economico. Ma penso che i file system stiano probabilmente diventando più pesanti perché vogliamo funzionalità più fantasiose in essi. Sospetto che ext2 sia un po 'più snello di ext4. Sarei interessato a vedere alcuni numeri del mondo reale su questo. Naturalmente, tale "efficienza" ha un prezzo (il più grande è che non è registrato su giornale e quindi più veloce e più facilmente corrotto).

Per quanto riguarda il motivo per cui ext4 occupa più spazio in questo caso, suppongo che i cluster di archiviazione su NTFS siano stati impostati per indirizzare lo spazio di archiviazione in blocchi molto più grandi di quelli richiesti dai parametri ext4. Se questo è vero, allora dovresti ottenere un uso dello storage più efficiente se hai molti file relativamente piccoli.

Basti dire che l'intera materia continua all'infinito. Se vuoi maggiori informazioni, ti suggerisco di dare un'occhiata a varie pagine di Wikipedia confrontando i file system là fuori .. Oltre a guardare le pagine man per ogni FS che ti interessa.

Spero che lo trovi utile.


1

I superblocchi riservati sono una cosa, ma per niente l'importo a cui ti stai riferendo. La modifica dei superblocchi riservati non viene visualizzata nello "spazio disponibile totale" ... ciò non cambia. È il numero di inode x la loro dimensione. Su ext4 per impostazione predefinita, aspettarsi qualcosa come 256 byte per inode e per 400 GB , Immagino che forse mkfs.ext4 farà ~ 25-30 milioni. Usa dumpe2fs -h per vedere il numero attuale. Ciò costituisce i 6 GB che ti mancano e non i blocchi riservati su cui si trova qualcuno (ad es. Inode- conta x dimensioni inode b / 1024 ^ 3) GB.

L'output di df -h che sospetto potrebbe avere a che fare con un po 'di zoppia; p Prova a farlo di nuovo e specifica metà dei tuoi i-nodi (puoi farlo in sicurezza, e ancora di più se sei in grassetto) ma fai attenzione che molte directory potrebbero ti fanno finire gli inode prima dello spazio.

Per esempio. ext4 riserva diversi inode 93-4?) per directory, supponendo che tu abbia intenzione di contenere più di uno o due file, rendendolo quindi più efficiente. Se si dispone di 1 milione di cartelle con 1 milione di file, si esauriranno gli inode su quel layout prima di esaurire lo spazio. Di solito gli inode vengono utilizzati solo in una percentuale inferiore dello spazio, ma possono raggiungere il 35%, quindi dividere per due è abbastanza sicuro per gli utenti desktop, ma non fare di più per essere al sicuro.

Ecco un esempio:

415 GB RAW (dev / sdb1 dire) mkfs.ext4 -m0 -Ndefault # / 2 -Lext4-1 -O extension, dir_index, large_file, sparse_super, uninit_bg / dev / sdb1

le opzioni aiuteranno per grandi file / partizioni con media dire. uninit_bg è per kernel recenti. Questo è pubblicato anche se è vecchio per i futuri lettori.

Malina Salina


0

Avevo un filesystem (completo) ntfs che conteneva circa 1000 GB di dati con solo poche centinaia di megabyte gratuiti. Anche se la capacità formattata di ext4 era molto inferiore a NTFS, ricordo che quando ho copiato tutto avevo ancora circa 70 GB di spazio libero su ext4 anche se la capacità formattata era inferiore. (Ricorda che il NTFS era pieno). Non posso promettere che questo ti accada, ma almeno per i file che ho avuto ext4 è stato un vero risparmio di spazio! :)

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.