大多數情況下，在檢查資料夾或檔案的大小時，“Size”和“Size on disk”的值將非常接近匹配，但如果兩者之間存在巨大差異呢？今天的超級使用者問答文章將探討這個令人困惑的問題的答案。

今天的問答環節是由SuperUser提供的，SuperUser是Stack Exchange的一個分支，是一個由社群驅動的問答網站分組。

問題

超級使用者讀者thelastblack想知道為什麼**SD卡上的資料夾的“大小”和“磁碟大小”之間有如此巨大的差別：

As you can see below, there is so much difference between the ‘Size’ and ‘Size on disk’ fields for this folder. Why is that?

I know that ‘Size on disk’ should be a little more than ‘Size’ because of allocation units in Windows, but why is there that much difference? Could it be because of the large number of files?

BTW, this folder is on my Android phone’s SD card. Inside this, my maps app stores its cached maps, and the app gets its maps from Google Maps.

從截圖上看，“大小”和“磁碟大小”之間肯定存在巨大差異，那麼是什麼原因造成的呢？

答案

超級使用者貢獻者Bob為我們提供了答案：

I will be assuming that you are using the FAT/FAT32 file system here, since you mention this is an SD card. NTFS and exFAT behave similarly with regards to allocation units. Other file systems might be different, but they aren’t supported on Windows anyway.

If you have a lot of **all files, this is certainly possible. C***ider this:

• 50,000 files
• 32 KB cluster size (allocation units), which is the max for FAT32

Ok, now the minimum space taken is 50,000 * 32,000 = 1.6 GB (using SI prefixes, not binary, to simplify the maths). The space each file takes on the disk is always a multiple of the allocation unit size – and here we’re assuming each file is actually **all enough to fit within a single unit, with some (wasted) space left over.

If each file averaged 2 KB, you’d get about 100 MB total – but you’re also wasting 15x that (30 KB per file) on average due to the allocation unit size.

In-Depth Explanation

Why does this happen? Well, the FAT32 file system needs to keep track of where each file is stored. If it were to keep a list of every single byte, the table (like an address book) would grow at the same speed as the data – and waste a lot of space. So what they do is use “allocation units”, also known as the “cluster size”. The volume is divided into these allocation units, and as far as the file system is concerned, they cannot be subdivided – those are the **allest blocks it can address. Much like you have a house number, but your postman doesn’t care how many bedrooms you have or who lives in them.

So what happens if you have a very **all file? Well, the file system doesn’t care if the file is 0 KB, 2 KB, or even 15 KB, it’ll give it the least space it can – in the example above, that’s 32 KB. Your file is only using a **all amount of this space, and the rest is basically wasted, but still belongs to the file – much like a bedroom you leave unoccupied.

Why are there different allocation unit sizes? Well, it becomes a trade-off between having a bigger table (address book, e.g. saying John owns a house at 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.), or more wasted space in each unit (house). If you have larger files, it makes more sense to use larger allocation units – because a file doesn’t get a new unit (house) until all others are filled up. If you have lots of **all files, well, you’re going to have a big table (address book) anyway, so may as well give them **all units (houses).

Large allocation units, as a general rule, will waste a lot of space if you have lots of **all files. There usually isn’t a good reason to go above 4 KB for general use.

Fragmentation?

As for fragmentation, fragmentation shouldn’t waste space in this manner. Large files may be fragmented, i.e. split up, into multiple allocation units, but each unit should be filled before the next one is started. Defragging might save a little space in the allocation tables, but this isn’t your specific issue.

Possible Soluti***

As gladiator2345 suggested, your only real opti*** at this point are to live with it or reformat with **aller allocation units.

Your card might be formatted in FAT16, which has a **aller limit on table size and therefore requires much larger allocation units in order to address a larger volume (with an upper limit of 2 GB with 32 KB allocation units). Source courtesy of Braiam. If that is the case, you should be able to safely format as FAT32 anyway.

有什麼要補充的解釋嗎？在評論中發出聲音。想從其他精通技術的Stack Exchange使用者那裡瞭解更多答案嗎？在這裡檢視完整的討論主題。