關於exFAT檔案大小的問題 - MAC

By Ina
at 2011-05-11T01:31
at 2011-05-11T01:31
Table of Contents
這故事要從 FAT 的設計說起
板上有修過 OS 課的請先原諒小弟的班門弄斧
FAT 的全名是 File Allocation Table,
顧名思義它有一張表來記錄你檔案怎麼分配的
檔案在存進去 FAT 磁區的時候,會被分成好幾塊,
那一塊的大小稱為 cluster size,是 512 KB 的倍數
每一個 cluster 在 FA Table 裡面都有一個位置,稱為 FA entry
記錄的是我的下一個 block 在哪裡,所以它其實在存取的時候是要一串讀過去。
這一個 entry 的大小寫成 bit 的話就是 FAT xx 的這個 xx
如 FAT 32 則 entry size = 32 bits = 4 Bytes
exFAT 根據我查到的資料是 32-bit 也就是 4 bytes。
假設您的 exFAT 磁區有 > 32GB,根據微軟的文件,預設的 cluster size = 128 KB
http://support.microsoft.com/kb/140365/en-us
所以當你儲存 4.5MB 的檔案進入 exFAT (FAT64) 的磁區時
你要佔用的空間除了儲存檔案實際內容的那一堆 clusters of blocks (4.5MB)
還有描述 clusters 的 FA entries,
每一個 128KB 的 cluster 都要有一個對應的 entry,
所以只要除以 cluster size 就得到要記錄這一堆 clusters 所需要的 entry 數量:
4.5 MB ( 4096 + 512 ) KB
------- = ----------------- = 36
128 KB 128 KB
每一個 entry size = 32 bits = 4 bytes ,所以 36 * 4 = 144 Bytes
也就是說,為了儲存這 4.5MB,你需要額外的 144 Bytes,
大約就是你看到的 4.6 MB
當然這個數字會根據你格式化時指定的 cluster size 而不同
感謝三樓指正,我算錯了 XDD 以下訂正
這樣也才 1KB ,怎麼會有差到近 100KB 的數字呢?
是因為你的 cluster 可能沒有用滿,通常的情況下也是這樣,
你的檔案不會是 128KB 的整數倍,所以超過的部份會佔掉 1 個 cluster = 128KB
大概就是為什麼會多約 100 KB 的原因吧。
如果你的作業系統在計算容量時,會計較其真正在檔案系統中實際佔用的空間,
那就會把後面這個沒用完的 128 KB 給算進去,檔案愈多,則冗餘空間愈大。
以上是根據我以前上課的筆記,如果有錯還請板友指正 <(_ _)>
附帶一提,因為這種分配的特性,假如作業系統操作 FAT 磁區的演算法不好的話,
就很容易產生分佈很散碎片,讀取時因為必須從頭到尾乖乖讀,
這樣子磁頭要一直前前後後,就很像折返跑好幾十次那樣。
所以檔案分得愈零散,讀取就愈耗時,這時候也就需要做磁碟重組。
當然這件事在 SSD 上面不會發生,因為它的隨機存取很快。
※ 引述《SugarBrown (The Prestige)》之銘言:
: 不好意思 我不太確定問題是軟體還是硬體的問題
: 不過我還是選了軟體
: 事情是這樣的
: 這兩天我買了一顆硬碟 然後順利的把他格式化成exFAT的這種格式
: 之後我放了檔案進去
: 但是檔案在exFAT這個新硬碟裡顯示的大小都會比較大
: 例如:我放了一個4.5mb的mp3進去(在原電腦上顯示4.5mb)
: 然後在exFAT這顆新硬碟裡就變成4.6mb
: 當然更大的檔案差別更是巨大(像是我備份的整個iTUNES資料庫就差好幾GB)
: 請問這是正常現象嗎?
: 因為我還有一個TimeCapsule 但是我把一樣的檔案丟進去,大小就不會變
: 而我知道Timecapsule是原本mac用的那種日誌式的格式
: 難道說這是因為格式化成不同的格式的緣故嗎?
: 煩請各位解答 因為我Google不到相關的資訊
: 謝謝:)
--
--
板上有修過 OS 課的請先原諒小弟的班門弄斧
FAT 的全名是 File Allocation Table,
顧名思義它有一張表來記錄你檔案怎麼分配的
檔案在存進去 FAT 磁區的時候,會被分成好幾塊,
那一塊的大小稱為 cluster size,是 512 KB 的倍數
每一個 cluster 在 FA Table 裡面都有一個位置,稱為 FA entry
記錄的是我的下一個 block 在哪裡,所以它其實在存取的時候是要一串讀過去。
這一個 entry 的大小寫成 bit 的話就是 FAT xx 的這個 xx
如 FAT 32 則 entry size = 32 bits = 4 Bytes
exFAT 根據我查到的資料是 32-bit 也就是 4 bytes。
假設您的 exFAT 磁區有 > 32GB,根據微軟的文件,預設的 cluster size = 128 KB
http://support.microsoft.com/kb/140365/en-us
所以當你儲存 4.5MB 的檔案進入 exFAT (FAT64) 的磁區時
你要佔用的空間除了儲存檔案實際內容的那一堆 clusters of blocks (4.5MB)
還有描述 clusters 的 FA entries,
每一個 128KB 的 cluster 都要有一個對應的 entry,
所以只要除以 cluster size 就得到要記錄這一堆 clusters 所需要的 entry 數量:
4.5 MB ( 4096 + 512 ) KB
------- = ----------------- = 36
128 KB 128 KB
每一個 entry size = 32 bits = 4 bytes ,所以 36 * 4 = 144 Bytes
也就是說,為了儲存這 4.5MB,你需要額外的 144 Bytes,
大約就是你看到的 4.6 MB
當然這個數字會根據你格式化時指定的 cluster size 而不同
感謝三樓指正,我算錯了 XDD 以下訂正
這樣也才 1KB ,怎麼會有差到近 100KB 的數字呢?
是因為你的 cluster 可能沒有用滿,通常的情況下也是這樣,
你的檔案不會是 128KB 的整數倍,所以超過的部份會佔掉 1 個 cluster = 128KB
大概就是為什麼會多約 100 KB 的原因吧。
如果你的作業系統在計算容量時,會計較其真正在檔案系統中實際佔用的空間,
那就會把後面這個沒用完的 128 KB 給算進去,檔案愈多,則冗餘空間愈大。
以上是根據我以前上課的筆記,如果有錯還請板友指正 <(_ _)>
附帶一提,因為這種分配的特性,假如作業系統操作 FAT 磁區的演算法不好的話,
就很容易產生分佈很散碎片,讀取時因為必須從頭到尾乖乖讀,
這樣子磁頭要一直前前後後,就很像折返跑好幾十次那樣。
所以檔案分得愈零散,讀取就愈耗時,這時候也就需要做磁碟重組。
當然這件事在 SSD 上面不會發生,因為它的隨機存取很快。
※ 引述《SugarBrown (The Prestige)》之銘言:
: 不好意思 我不太確定問題是軟體還是硬體的問題
: 不過我還是選了軟體
: 事情是這樣的
: 這兩天我買了一顆硬碟 然後順利的把他格式化成exFAT的這種格式
: 之後我放了檔案進去
: 但是檔案在exFAT這個新硬碟裡顯示的大小都會比較大
: 例如:我放了一個4.5mb的mp3進去(在原電腦上顯示4.5mb)
: 然後在exFAT這顆新硬碟裡就變成4.6mb
: 當然更大的檔案差別更是巨大(像是我備份的整個iTUNES資料庫就差好幾GB)
: 請問這是正常現象嗎?
: 因為我還有一個TimeCapsule 但是我把一樣的檔案丟進去,大小就不會變
: 而我知道Timecapsule是原本mac用的那種日誌式的格式
: 難道說這是因為格式化成不同的格式的緣故嗎?
: 煩請各位解答 因為我Google不到相關的資訊
: 謝謝:)
--
--
Tags:
MAC
All Comments

By Todd Johnson
at 2011-05-15T11:57
at 2011-05-15T11:57

By Megan
at 2011-05-20T01:17
at 2011-05-20T01:17

By Edith
at 2011-05-20T15:46
at 2011-05-20T15:46

By Iris
at 2011-05-23T02:30
at 2011-05-23T02:30

By Doris
at 2011-05-25T03:47
at 2011-05-25T03:47
Related Posts
MBP 2011 的使用時間

By Megan
at 2011-05-11T01:15
at 2011-05-11T01:15
MBP 2011 15" 記憶體更換問題

By Leila
at 2011-05-11T01:01
at 2011-05-11T01:01
滅火的 New iMac 規格

By Delia
at 2011-05-11T00:49
at 2011-05-11T00:49
關於exFAT檔案大小的問題

By Noah
at 2011-05-11T00:24
at 2011-05-11T00:24
PD6的小疑問

By Lydia
at 2011-05-11T00:05
at 2011-05-11T00:05