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

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

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.

^{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.

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.

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 :-)

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.

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.

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.

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.

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

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.