Perché esiste una differenza così grande tra "Dimensione" e "Dimensione su disco"?


302

Come puoi vedere sotto, c'è così tanta differenza tra i campi Dimensione e Dimensione su disco nella mia cartella. Perché?

Schermata che mostra 50.875 file in 1.504 cartelle, 105 MB da 1,43 GB su disco

So che Dimensione su disco dovrebbe essere un po 'più di Dimensione a causa delle unità di allocazione in Windows, ma perché tanta differenza? Potrebbe essere a causa del gran numero di file?

A proposito, questa cartella si trova sulla scheda SD del mio telefono Android. Al suo interno, la mia app per le mappe memorizza le sue mappe memorizzate nella cache e l'app ottiene la sua mappa da Google Maps.


10
Ciao thelastblack, e benvenuto su SuperUser. Ho modificato la tua domanda per rimuovere la parte relativa alla deframmentazione, poiché le due risposte esistenti si concentrano sulla dimensione / dimensione sulla discrepanza del disco e il formato Stack Exchange funziona meglio quando ogni domanda pubblicata riguarda una sola cosa. Puoi certamente ri-porre questa domanda come una domanda separata, anche se penso che le risposte che hai ricevuto finora su questa domanda dimostrino che la deframmentazione non ti aiuterà. (In genere non va bene nemmeno sui media a stato solido.) Sentiti libero di modificare ulteriormente la tua domanda se ritieni che io abbia cambiato le tue intenzioni in alcun modo.
un CVn

1
@ MichaelKjörling Heh, ho appena pubblicato una discussione minore sulla frammentazione (mi sono distratto un po 'prima)
Bob

21
@ MichaelKjörling Non modificare le domande in modo retroattivo per adattarle alle risposte. Una delle risposte affronta la parte di frammentazione della domanda del PO. La modifica deve essere annullata per evitare confusione.
DanteTheEgregore,

5
@DanteTheEgregore Se ti riferisci alla risposta di Bob, che in effetti è stata modificata per discutere anche degli effetti della frammentazione, quindi prima di saltare la pistola, controlla le cronologie di modifica e i timestamp su quella risposta e sulla domanda. Al momento della mia modifica, la risposta di Bob non copriva affatto il problema della frammentazione. Se l'OP vuole farlo, la modifica in "la deframmentazione dei media mi aiuterà in questo?" dovrebbe risolvere qualsiasi confusione eccezionale, sebbene ritenga che sia meglio porre una domanda separata; IMO la questione della differenza tra i due valori non è correlata.
un CVn

11
Mi sembra che questa app sia seriamente programmata male - considera di presentare una segnalazione di bug. Non sono affatto un programmatore professionista, ma una volta ho hackerato qualcosa di simile insieme in JavaME, e ovviamente uno dei problemi che ho dovuto risolvere era come archiviare tutte quelle tessere mappa in modo efficiente (archiviazione e accesso) in un contenitore. Ho finito per usare i file zip non compressi.
A. Donda,

Risposte:


303

Presumo che tu stia utilizzando il file system FAT / FAT32 qui, poiché dici che si tratta di una scheda SD. NTFS ed exFAT si comportano in modo simile per quanto riguarda le unità di allocazione. Altri filesystem potrebbero essere diversi, ma non sono comunque supportati su Windows.

Se hai molti file di piccole dimensioni, questo è certamente possibile. Considera questo:

  • 50.000 file.

  • Dimensione cluster 32 kB (unità di allocazione), che è il massimo per FAT32

Ok, ora lo spazio minimo richiesto è 50.000 * 32.000 = 1,6 GB (usando prefissi SI, non binari, per semplificare la matematica). Lo spazio che ogni file occupa sul disco è sempre un multiplo della dimensione dell'unità di allocazione - e qui assumiamo che ogni file sia effettivamente abbastanza piccolo da adattarsi all'interno di una singola unità, con uno spazio (sprecato) rimasto.

Se ogni file avesse una media di 2 kB, otterresti circa 100 MB in totale, ma stai sprecando in media 15 volte (30 kB per file) a causa delle dimensioni dell'unità di allocazione.


Spiegazione approfondita

Perché succede? Bene, il filesystem FAT32 deve tenere traccia di dove è archiviato ogni file. Se dovesse mantenere un elenco di ogni singolo byte, la tabella (come una rubrica) crescerebbe alla stessa velocità dei dati e sprecherebbe molto spazio. Quindi quello che fanno è usare le "unità di allocazione", note anche come "dimensione del cluster". Il volume è diviso in queste unità di allocazione e, per quanto riguarda il filesystem, non possono essere suddivisi: questi sono i blocchi più piccoli che può affrontare. Proprio come se tu avessi un numero civico, ma al tuo postino non importa quante camere hai o chi ci abita.

Quindi cosa succede se hai un file molto piccolo? Bene, al filesystem non importa se il file è 0 kB, 2 kB o anche 15 kB, gli darà il minor spazio possibile - nell'esempio sopra, è 32 kB. Il tuo file utilizza solo una piccola quantità di questo spazio e il resto è sostanzialmente sprecato, ma appartiene ancora al file, proprio come una camera da letto che lasci vuota.

Perché esistono diverse dimensioni delle unità di allocazione? Bene, diventa un compromesso tra avere un tavolo più grande (rubrica, ad esempio dicendo che John possiede una casa in 123 Fake Street, 124 Fake Street, 666 Satan Lane, ecc.) O più spazio sprecato in ogni unità (casa). Se hai file più grandi, ha più senso usare unità di allocazione più grandi, perché un file non ottiene una nuova unità (casa) fino a quando tutti gli altri non vengono riempiti. Se hai molti file piccoli, beh, avrai comunque un grande tavolo (rubrica), quindi potresti anche dare loro piccole unità (case).

Le unità di allocazione di grandi dimensioni, come regola generale, sprecheranno molto spazio se si dispone di molti file di piccole dimensioni. Di solito non c'è un buon motivo per andare oltre i 4 kB per uso generale.


La frammentazione?

Per quanto riguarda la frammentazione, la frammentazione non dovrebbe sprecare spazio in questo modo. I file di grandi dimensioni possono essere frammentati, ovvero suddivisi, in più unità di allocazione, ma ogni unità deve essere riempita prima di iniziare quella successiva. La deframmentazione potrebbe risparmiare un po 'di spazio nelle tabelle di allocazione, ma questo non è il tuo problema specifico.


Possibili soluzioni

Come suggerito da gladiator2345 , le uniche opzioni reali a questo punto sono convivere con esso o riformattare con unità di allocazione più piccole.

La tua scheda potrebbe essere formattata in FAT16, che ha un limite più piccolo per le dimensioni del tavolo e quindi richiede unità di allocazione molto più grandi al fine di affrontare un volume maggiore (con un limite superiore di 2 GB con unità di allocazione da 32 kB). Fonte per gentile concessione di Braiam . In tal caso, dovresti comunque essere in grado di formattare in modo sicuro come FAT32.


3
Lo spazio sprecato a causa delle dimensioni minime di allocazione è in realtà tecnicamente chiamato "frammentazione interna", quindi si potrebbe dire che la frammentazione è il colpevole. Ma non è ancora qualcosa su cui qualsiasi strumento di "deframmentazione" può fare qualcosa.
Hobbs

3
(Meno tecnicamente, si chiama semplicemente "slack".)
Hobbs

1
Le dimensioni del cluster limitano anche la dimensione massima del file system. Ad esempio, se lo spazio degli indirizzi è a 32 bit, hai un totale di circa 4,29 miliardi di cluster totali possibili. Ora, se si utilizza la dimensione del cluster più piccola supportata da NTFS (512 byte), è possibile indirizzare un massimo di 512 * 2 ^ 32 byte = 2 GiB. Se è necessario un volume in grado di memorizzare più di 2 GiB di dati, è necessario aumentare le dimensioni del cluster. Tutto questo è indipendente dall'attuale file più grande che si tenta di archiviare, a condizione che non sia possibile archiviare un file di dimensioni superiori a 2 GiB che è l'ultimo dei problemi.
Andon M. Coleman,

4 cluster KiB ti consentiranno di indirizzare i file in un volume di dimensioni fino a 16 TiB, che dovrebbe essere sufficiente per il prossimo futuro.
Andon M. Coleman,

1
Bene, potrebbe comprimere il suo archivio di piccoli file in un unico file di grandi dimensioni.
einpoklum,

45

Questa è una di quelle situazioni in cui può essere utile comprimere / archiviare in un singolo file. Ciò che Bob ha detto nella sua risposta è vero, ma la soluzione potrebbe essere più semplice della riformulazione del disco, come suggeriscono altre risposte. Se comprimete o archiviate la directory (usando zip, tar o qualsiasi altro metodo) il file system vedrà che avete un singolo file grande, anziché diversi file più piccoli. Anche senza comprimere, tornerai indietro di quasi 1,4 GiB di spazio, perché tutti quei "file di piccole dimensioni" verranno conteggiati come un singolo file di grandi dimensioni.

Al suo interno, la mia app per le mappe memorizza le sue mappe memorizzate nella cache e l'app ottiene la sua mappa da Google Maps

Forse dovresti discutere con lo sviluppatore per utilizzare un archivio o un database anziché più file. Questo probabilmente aiuterà anche ad avere il disco meno frammentato e sicuramente risparmierà spazio soprattutto se si tratta di un'unità flash NAND. Se spieghi la situazione ridicola in cui 100 MB di payload / dati utili diventano 1,4GiB, c'è qualcosa di sbagliato nel modo in cui i dati vengono archiviati e gli sviluppatori dovrebbero offrire una soluzione migliore.


1
> All'interno, la mia app per le mappe memorizza le sue mappe memorizzate nella cache e l'app ottiene la sua mappa da Google Maps. - sfortunatamente, in questo caso, la compressione (che è effettivamente un file system sopra quello di base) richiederebbe il supporto di questa app di mappatura.
Bob,

1
@Bob allora la soluzione dovrebbe venire dal lato sviluppatore D:
Braiam

4
È assolutamente vero. Per ora penso che dovrei cambiare la mia app.
vfsoraki,

17
@Braiam Non sta ingannando il file system nel pensare che ci sia un solo file; c'è un solo file. Il motivo per cui gli sviluppatori non memorizzano le informazioni della cache in un archivio, è probabilmente perché la maggior parte dei formati di archivio non sono progettati per scritture casuali veloci, di cui una cache ha sicuramente bisogno. Un'alternativa migliore potrebbe essere quella di utilizzare una libreria di database leggera come SQLite.
scrive il

1
Assolutamente vero ..... +1
arundevma

25

Nel caso in cui qualcuno si trovi di fronte a questo problema, potrebbe essere utile sapere anche che un altro motivo per vedere una grande differenza nella dimensione / spazio del file sul disco è l'uso di flussi di dati alternativi (ADS)

Questo vale solo per NTFS a mia conoscenza. Gli annunci sono noti sia per usi legittimi che non legittimi:

  • per taggare un file scaricato da Internet
  • per memorizzare i metadati (Microsoft voleva includere alcune delle funzionalità del sistema operativo Apple, come non usare l'estensione del file per determinare il tipo di un file)
  • per nascondere dati o codice nel contesto di un malware .

ADS semplicemente: qualsiasi file NTFS può contenere più flussi di dati (capire "file secondari"). Uno è il flusso principale, utilizzato da Windows Explorer e altri strumenti di Windows, che contiene il solito contenuto di un file. I flussi di dati alternativi possono contenere altre informazioni, esattamente come il flusso principale, ma non possono essere gestiti direttamente dagli strumenti di Windows (in particolare Explorer visualizza le dimensioni del file come uguali alle dimensioni del flusso principale, indipendentemente dalle dimensioni dell'ADS), devi usare strumenti o codice specializzati per scrivere, leggere e localizzare gli annunci pubblicitari.

Il punto principale è che in caso di grandi differenze di dimensioni dei file osservate, non trascurare la possibilità di ADS e malware nascosto.

Un altro collegamento .

Per sperimentare in sicurezza con ADS, prova questo a livello DOS / CMD ...

Creare e quindi visualizzare il contenuto di un file nella radice di C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Risultato:

C:\> The main data stream

Ora aggiungi un ADS con lo stesso metodo, basta specificare il nome ADS oltre al nome del file:

C:\> echo The secret message> test.txt:secret

Hai appena nascosto il messaggio segreto nel file. Si noti che la dimensione del file in Explorer non è cambiata nonostante abbiamo aggiunto byte nel "segreto" di ADS.

Prova a visualizzare il contenuto ADS:

C:\> type test.txt:secret

Risultato:

The filename, directory name, or volume label syntax is incorrect.

CMD typenon è in grado di visualizzare il contenuto dell'ADS. Utilizzeremo invece Blocco note:

notepad test.txt:secret

Nel Blocco note possiamo vedere il contenuto degli annunci pubblicitari:

The secret message

Puoi anche nascondere un eseguibile completo in un ADS di un file di testo innocente ed eseguirlo in qualsiasi momento. La ricchezza non danneggia gli hacker :-)


Io stesso non sono un uomo di vittoria, il mio lavoro è principalmente svolto su Linux. Questo è stato molto utile. Grazie
vfsoraki il

4
Vale la pena usare uno strumento come Stream di Sysinternals per verificare l'utilizzo di ADS. Ad esempio, i file scaricati su un sistema Windows possono essere taggati con una fonte in ADS, anche se questo è piccolo e non dovrebbe occupare spazio. Normalmente non verrà visualizzato in output dir o Explorer. Potrebbe richiedere blocchi e aggravare il problema di utilizzo del disco su cui si sta indagando. .
Adric,

19

Il problema potrebbe essere dovuto alla dimensione del cluster.

Secondo Microsoft :

Se non si utilizza la compressione NTFS per file o cartelle contenuti nel volume, la differenza tra SIZE e SIZE ON DISK è spazio sprecato a causa di una dimensione del cluster più grande del necessario. Si dovrebbe tentare di utilizzare una dimensione del cluster ottimale in modo che il valore SIZE ON DISK sia il più vicino possibile al valore SIZE. Un'eccessiva discrepanza tra SIZE ON DISK e il valore SIZE indica che la dimensione del cluster predefinita è troppo grande per la dimensione media del file che si sta archiviando nel volume e che dovrebbe essere ridotta. Questo può essere fatto solo eseguendo il backup del volume e quindi riformattando il volume utilizzando il comando format e l'opzione / a per specificare la dimensione di allocazione appropriata: IE: format D: /a:2048 (Questo esempio utilizza una dimensione del cluster da 2 KB).

Prova a formattare l'unità con dimensioni del cluster inferiori.


4
Detto questo, non si dovrebbe rendere le dimensioni del cluster inferiori a 4096 byte o semplicemente non multiple di questo numero. Il sistema operativo a 32 bit funziona con pagine che (nel caso non PAE) sono di 4096 byte, quindi l'utilizzo di cluster non multipli può influire negativamente sulle prestazioni del file system. Questo è il motivo per cui la dimensione predefinita è impostata su 4096 byte.
Ruslan,

2
Per aggiungere ciò che ha detto @Ruslan, i dischi rigidi più recenti ora hanno una dimensione del settore di 4 kB e sarebbe ottimale allineare il filesystem ai settori fisici e avere un multiplo della dimensione del settore fisico come dimensione dell'unità di allocazione.
Bob,

1
@Ruslan Credo che tu voglia dire che dovrebbe essere una potenza di due volte 4096. 12288 (3 × 4096) e 20480 (5 × 4096) non sono grandi scelte.
Scott,

9

Vedo molte persone che consigliano di riformattare l'unità con un cluster di dimensioni inferiori. Poiché si tratta di una scheda SD, tenere presente che molti fornitori preformattano la scheda in base alla dimensione del cluster consigliata per adattarla alla dimensione del cluster della NAND (mantenere entrambi sincronizzati è molto importante per prestazioni di lettura / scrittura ottimali e ridurre l'usura)

Non è possibile modificare le dimensioni del cluster della NAND (è un attributo fisico dell'hardware della scheda SD).

Per prima cosa esegui scandisk / chkdsk sulla tua scheda SD per assicurarti che il problema relativo alle dimensioni non risieda in un file system danneggiato.

In secondo luogo, ti suggerirei di segnalare il bug agli sviluppatori di Google Map, per loro è quello da incolpare qui. Dovrebbero utilizzare un metodo di archiviazione superiore. La correzione dovrebbe anche rendere l'applicazione più veloce su molti dispositivi a causa della minore attività di I / O e di attività del file system.


In realtà, non era Google Maps, ma un'altra app che utilizzava le mappe di Google. Ho informato lo sviluppatore e ho appena rimosso quei file dalla mia SD.
vfsoraki,

7

Questo è un problema generale con molti filesystem. Ci sono due fattori al lavoro qui, il numero massimo di "blocchi" che un filesystem può gestire per volume logico e restrizioni fisiche del supporto di archiviazione. È possibile assegnare solo 1 file a un determinato blocco (i file in genere richiedono tutti i blocchi di cui hanno bisogno). Quindi un file di testo con 64 byte può spesso richiedere da 4k a 32k, a seconda della dimensione del blocco del filesystem su cui risiede.

Un modo di pensare a questo è pensare a ciascun blocco nel filesystem come una scatola e il filesystem come una stanza. Tutte le tue scatole hanno le stesse dimensioni e cerchi di inserirne il maggior numero possibile in una stanza. Se li inserisci tutti con più spazio rimasto, devi ottenere scatole più grandi in modo che la stanza sia riempita completamente di scatole.

Una delle regole per mettere le cose nelle scatole è che non puoi mettere due cose non correlate in una scatola. Devono far parte dello stesso documento. Quindi, se dovessi scrivere una pagina di testo, avrebbe la sua casella. Se il mio testo digitato avesse così tante pagine che non avrei potuto inserirle tutte in una casella, avrei semplicemente trovato un'altra casella e avrei continuato a inserire pagine, ripetendo fino a quando non avessi archiviato tutte le mie pagine. Avrei anche scritto le scatole che avevo usato per quel documento e l'ordine delle scatole per leggerlo in sequenza.

A seconda di come organizzerei le scatole, potrei avere abbastanza spazio nel mio manifest per un certo numero di scatole. Quindi, se avessi una grande stanza da riempire, ma solo un piccolo numero di scatole dovrei usare scatole molto grandi per raggiungere la capacità della stanza.

Quindi in quel caso il mio documento di una pagina occuperebbe ancora una sola casella, senza nient'altro che lo condividesse.

Le stesse situazioni si manifestano tra varie soluzioni di archiviazione. FAT32 può gestire solo quello che è considerato un numero basso di "box" sugli enormi hard disk di oggi, quindi finisce con "box" molto grandi per compensare questo.


6

A parte le dimensioni dei cluster, puoi anche avere una discrepanza a causa delle seguenti condizioni:

  • I file compressi o crittografati possono utilizzare uno spazio diverso da quello della dimensione del file logico.
  • I file collegati riporteranno n volte il numero di collegamenti per la dimensione del file per la dimensione del file logico, ma lo spazio fisico utilizzato è generalmente inferiore.

In generale, potrebbe essere vero. Ma nel mio caso, il problema era rappresentato da un'unità di allocazione elevata.
vfsoraki,

3
Sì, sto solo cercando di aggiungere alla risposta dando più possibili ragioni per la discrepanza.
Archimede Trajano,

6

Dovresti dare un'occhiata alla voce Block Suballocation in Wikipedia. Questo è esattamente quello che ti sta succedendo. L'uso di un file system con supporto per Tail Packaging è una soluzione a livello di file system per questo problema oltre a modificare le dimensioni del cluster di allocazione.

Tutti hanno l'inconveniente di dover riformattare il disco.

In alcuni casi, la semplice memorizzazione di tali file in un archivio risolveva il problema (e anche i file di piccole dimensioni venivano compressi oltre a interrompere la perdita di spazio alla fine dei file). Questo ha l'inconveniente di trascorrere del tempo per la decompressione.

Un'altra opzione se hai tanti piccoli file a causa di un problema specifico relativo all'applicazione è la memorizzazione dei dati del software utilizzando un altro metodo (potrebbe essere in un database). Ma ovviamente è una soluzione per programmatori, non per utenti finali.

http://en.wikipedia.org/wiki/Tail_packing


0

Ho notato enormi discrepanze nella dimensione del file in Windows 10 su un singolo file, ma se guardo le proprietà del file SAME dalla stessa posizione (un'unità di rete), con Windows XP, la grande discrepanza non c'è; solo una piccola differenza, che è quello che ti aspetteresti. Penso che ci sia un bug in Windows 10. Un file di 449 MB probabilmente non occupa 3,99 GB, che è ciò che mi dice Windows 10.


1
Solo un FYI, la domanda non ha nulla a che fare con Windows 10. OP utilizza Windows 7.
TheKB
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.