I file occupano una diversa quantità di spazio in NTFS e LUKS + ext4?


3

Ho due volumi, uno NTFS (15028048 14213120 51544), che corrisponde a (blocchi 1-K, usati, disponibili) e l'altro è un LUKS + ext4 (14895184 13869752 245752). Ho controllato i file all'interno con md5sum e sono uguali, tuttavia, come può essere che NTFS abbia 14213120 e l'altro 13869752? Comprendo che una formattazione diversa porterà via una diversa quantità di spazio, ma una volta che hai un file da 1 MB, questo file da 1 MB è lo stesso in NTFS, vfat, ext3, ext4 o in qualunque formato tu usi. Cosa mi sto perdendo?

Risposte:


4

TL; DR → le dimensioni del contenuto del file sono solo una parte della storia e il modo in cui è memorizzato nel filesystem influenza il tuo spazio effettivo.

Un file 1MiB può richiedere una quantità diversa di overhead di "pulizia", ​​ovvero metadati, oltre ad essere allocato su un diverso numero di blocchi.

La lunghezza del contenuto di un file - ovvero il suo "inode" (un file normale ha una o più voci di directory, aka collegamenti fissi e un inode, che ha il contenuto) - dovrebbe essere identico indipendentemente dal filesystem utilizzato, ma la quantità di spazio che l'inode e i metadati rendono collettivamente non disponibili per l'uso di altri file possono differire in qualche modo.

Ad esempio un filesystem potrebbe allocare spazio in blocchi da 4 kB; in tal caso, una directory potrebbe occupare 4 kB anche con una sola voce e un file da 1 byte potrebbe occupare 4 kB. Un file da 4.097 byte su un filesystem con blocchi da 4 kB richiederebbe uno spazio effettivo di 8 KiB.

stat .emacs

  File: ‘.emacs’
  Size: 36303           Blocks: 72         IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 2097977     Links: 1

L' statoutput qui mostra che la mia casa si trova su un filesystem con tipici blocchi I / O da 4.096 byte (4KiB), quindi il file ~ 36kiB (36.303B) occupa effettivamente un po 'più di spazio rispetto a un sistema degli anni '70 con 512 -byte blocchi I / O.

La Blocks:figura si trova nei tradizionali blocchi Unix da 512 byte (½ kB), quindi dividendo la IO Blockdimensione per 512 (4.096 ÷ 512 = 8), scoprirai che il numero di blocchi è sempre un multiplo di 8 su questo filesystem. Tale overhead di allocazione rappresenta uno spazio sprecato di (72 × 512 = 36.864) - 36.303 = 561 byte in questo caso. (Su un filesystem con blocchi da 512 byte, verrebbero utilizzati solo 71 blocchi, quindi un sovraccarico di soli 49 byte.)

I filesystem ext2 / 3/4, in particolare, hanno alcune ottimizzazioni per rendere i collegamenti simbolici e file molto piccoli occupano meno spazio e gestiscono i file "sparsi" (file con molti blocchi di nient'altro che zero) in modo particolarmente efficiente. Ad esempio, un file vuoto occupa solo lo spazio della sua voce di directory:

  File: ‘emptyness’
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file                                                                 

Allo stesso modo, un breve collegamento simbolico potrebbe essere memorizzato senza allocare effettivamente alcun blocco a sé stante:

  File: ‘symlink’ -> ‘emptyness’
  Size: 9               Blocks: 0          IO Block: 4096   symbolic link                                                                      

I 9 byte del collegamento simbolico sono memorizzati nel file di directory, quindi occupa 0 byte.

Potrebbe essere necessario un nome symlink molto più lungo per allocare spazio:

File: ‘long-symlink’ -> ‘a very very long symlink target name … …                                                                     
Size: 2000            Blocks: 8          IO Block: 4096   symbolic link                                                                    

Si noti che 8 "blocchi Unix" è la quantità minima che questo filesystem può allocare (4096 ÷ 512), quindi i contenuti di ~ 2k occupano ~ 4k.

Ecco un file che non contiene nulla ma zero (creato con truncate -s 49M sparse-file), che ha anche una dimensione logica che non corrisponde al suo footprint del disco:

File: ‘sparse-file’
Size: 51380224        Blocks: 0          IO Block: 4096   regular file                                                                   

Si noti che questi tipi di file sono spesso creati da programmi ad accesso casuale come database o download di ordini casuali come BitTorrent.


Ci sono anche una serie di opzioni che puoi impostare quando crei ("formatta") il filesystem, che può renderlo più efficiente per il tuo particolare carico di lavoro, se è una grande preoccupazione. (Il mke2fsmanuale contiene alcuni dettagli.)

Oltre ai metadati che si riferiscono a singoli file (incluse directory, file regolari, collegamenti simbolici e file speciali del dispositivo) come nomi di file, autorizzazioni, ACL, attributi estesi e simili, ci sono anche alcuni metadati a livello del filesystem stesso, come il "superblocco" (di cui ext2 / 3/4 conserva diverse copie di backup) e l'inode del journal, che conterà rispetto al tuo spazio utilizzabile (libero) effettivo.

E, infine, ext2 / 3/4 di solito riserva una percentuale di ciascun volume solo per uso del superuso (ovvero root) - questo spazio non verrà visualizzato come "libero" su programmi ad esempio duo la maggior parte dei programmi simili, ma è ancora spazio inutilizzato per root" s solo uso. Questo può essere modificato tune2fsin qualsiasi momento - in genere lo riduco notevolmente sui volumi di tipo "documenti", ma lascio un certo importo riservato /in caso di emergenza di qualche tipo.

Se desideri davvero vedere più dettagli di quanto sia di solito utile, dumpe2fostamperà un rapporto piuttosto lungo delle varie opzioni in vigore sul tuo filesystem - ad esempio un po 'di quel rapporto potrebbe leggere:

Filesystem features:      has_journal ext_attr resize_inode dir_index f … …
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              128016
Block count:              512000
Reserved block count:     25600
Free blocks:              331865
Free inodes:              127631

Dettaglio fantastico. Questa è un'ottima risposta
Twisty Impersonator,

0

Penso che questo blaster dalla risposta di Doc alla domanda SU " Ext4 sia più costoso di NTFS? " Lo copre bene:

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 differ 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.

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.