PTT數位生活區 / Linux

[問題] Linux 磁碟重整與否

看板Linux作者 (香蕉公車)時間16年前 (2009/07/19 13:22), 編輯推噓7(7推 0噓 57→)
留言64則, 5人參與, 最新討論串1/1
在請教問題之前, 先提供幾個網頁: http://linux.vbird.org/linux_basic/0230filesystem.php http://en.wikipedia.org/wiki/Defragmentation http://0rz.tw/UFo9P http://phorum.study-area.org/index.php?action=printpage;topic=10368.0 在鳥哥裡面提到, 由於 Ext2 是索引式檔案系統，基本上不太需要 常常進行磁碟重組的。 在 Tanenbaum 的 << Modern Operating Systems, 2e >> 裡面提到 Linux 一開始的 file system 是使用 Minix 的 file system 而現今在使用的 ex2 file system 可以說是 Minix file system 的衍生 , 但本質上也都是使有 inode(index node) 作為管理, 即鳥哥所說的 "索引式檔案系統" (index file system) http://en.wikipedia.org/wiki/Inode 相對於"索引式檔案系統"的應該是"鏈節式檔案系統"(linked list allocation) , 最著名的應該是 FAT(file allocation table), 但實際上應為 linked list allocation using an index http://en.wikipedia.org/wiki/File_Allocation_Table 現在問題來了： inode 的原理是需要開啟檔案時, 將目的檔案的 inode 從硬碟載入, 藉以知 道檔案本身的內容是存在硬碟的哪個 block, 因為開一個檔案需要從 root 不斷的 往目的檔案所在的資料夾讀取, 所以可能需要很多次的硬碟讀取 為此使用了 caching (詳細情形可參考 J.Bath 的 <<The Design of The Unix Operating System>>) 來加速。 而 FAT 則是把整個 FAT 都放在記憶體中, 因此不需要額外的硬碟讀取便可找 到目標檔案位於哪些 block(只要開機掛載時讀取) 總結以上, 我們可以發現 FAT 其實沒有磁碟重整的必要, 因為它整個 FAT 都在 記憶體裡面,相對的將 inode 的目錄與子目錄所在的 block 重整, 或許還可以加速 ----------------------------------------------------------------------- 而事實上, 兩種 file system 其實都可能會造成檔案在硬碟中不連續配置(這是為 了排除 fragmentation 採用了 block 的方式所造成的後遺症), 因此對於硬碟一次 可以讀取大量 block 的特性,其實是很不利的。 總結這部份, 如果為了支援 block 一次可以讀取大量 block 的特性, 兩種 file system 都應該要進行磁碟重組 那為甚麼網路上大家都說 windows 的 file system 要磁碟重組,而 Linux 的不大 需要呢?? 感謝大家的回答 <(__)> -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.243.43 ※ 編輯: operationcow 來自: 140.112.243.43 (07/19 13:25) ※ 編輯: operationcow 來自: 140.112.243.43 (07/19 15:40)
推
07/19 15:56, , 1F
問你一個問題：磁碟重組主要是要重組什麼？是檔案配置表還是
07/19 15:56, 1F
→
07/19 15:57, , 2F
實際資料所佔區塊？又何者所佔用磁碟空間較大，影響讀取時間
07/19 15:57, 2F
→
07/19 15:58, , 3F
較巨？
07/19 15:58, 3F
→
07/19 17:15, , 4F
實際資料所佔區塊
07/19 17:15, 4F
→
07/19 17:16, , 5F
所以應該兩個都要磁碟重組不是嗎?
07/19 17:16, 5F
→
07/19 17:19, , 6F
不過我記得 Tanenbaum 有一篇 paper 提到檔案大小大
07/19 17:19, 6F
→
07/19 17:20, , 7F
概是 1K(1 個 block), 這樣來看的話說不定 Linux 用
07/19 17:20, 7F
→
07/19 17:22, , 8F
inode 的方式反倒比較需要磁碟讀取, 這樣應該是 FAT
07/19 17:22, 8F
→
07/19 17:22, , 9F
比較吃香, inode 可以用 caching 和 磁碟重整 inode
07/19 17:22, 9F
→
07/19 17:22, , 10F
來獲得加速
07/19 17:22, 10F
→
07/19 17:23, , 11F
補充一下,上面提到的 paper 是 Mullender and
07/19 17:23, 11F
→
07/19 17:23, , 12F
Tanenbaum 在 1984 提出的, 對象是 Unix, 現在看可能
07/19 17:23, 12F
→
07/19 17:24, , 13F
有一點不合時宜, 剛剛打開我的資料夾,檔案多是幾十 k
07/19 17:24, 13F
→
07/19 17:25, , 14F
到幾百 k, 不過如果從文章中的分析, 應該是兩個都需
07/19 17:25, 14F
→
07/19 17:25, , 15F
要磁碟重整??
07/19 17:25, 15F
→
07/19 17:34, , 16F
我覺得應該是第一個耶...所佔區塊 應該是指容量大小吧..
07/19 17:34, 16F
→
07/19 17:34, , 17F
等版主來解答^^
07/19 17:34, 17F
→
07/19 17:42, , 18F
整個"檔案配置表"不可能比整個"資料所佔區塊"來的大
07/19 17:42, 18F
→
07/19 17:43, , 19F
這樣使用太沒效率了
07/19 17:43, 19F
→
07/19 17:45, , 20F
以一個20GB大的硬碟來說, 1kB/block, 大概是使用80MB
07/19 17:45, 20F
→
07/19 17:45, , 21F
的記憶體作為 FAT
07/19 17:45, 21F
推
07/20 07:26, , 22F
其實主要的差別是在寫入資料時所用的演算法，FAT 的做法比較
07/20 07:26, 22F
→
07/20 07:31, , 23F
偏向「見洞就鑽」型，它是挑第一個找到可以放得下資料的位置
07/20 07:31, 23F
→
07/20 07:33, , 24F
來用，但該位置不見得與檔案中其他資料的位置接近；ex2/ex3
07/20 07:33, 24F
→
07/20 07:35, , 25F
則會選擇儘量讓同一檔案的資料區塊放在附近，所以相較之下，
07/20 07:35, 25F
→
07/20 07:37, , 26F
ext2/ext3 就比較不會有 fragmentation 的問題。
07/20 07:37, 26F
→
07/20 08:36, , 27F
所以版主的意思是說鳥哥及某些文章所說的, 索引式檔
07/20 08:36, 27F
→
07/20 08:37, , 28F
案系統比較不需要磁碟重組是錯的, 問題是出在寫入資
07/20 08:37, 28F
→
07/20 08:37, , 29F
料的演算法??
07/20 08:37, 29F
→
07/20 08:38, , 30F
另外就是採用 block 使得資料在 physical view 產生
07/20 08:38, 30F
→
07/20 08:38, , 31F
不連續的現象似乎不叫 fragmentation??
07/20 08:38, 31F
→
07/20 08:39, , 32F
fragmentation 該是分 internal 和 external, 而
07/20 08:39, 32F
→
07/20 08:39, , 33F
internal 應該是跟 block 的大小與檔案的大小有關,
07/20 08:39, 33F
→
07/20 08:41, , 34F
external 在 block 的機制下應該是避掉了
07/20 08:41, 34F
→
07/20 08:42, , 35F
抱歉, 修正一下上面所說, 這種採用 block 而資料不連
07/20 08:42, 35F
→
07/20 08:42, , 36F
續的現象應該算是 data fragmentation
07/20 08:42, 36F
→
07/20 08:43, , 37F
07/20 08:43, 37F
→
07/20 08:44, , 38F
不過針對寫入資料的演算法那部份, 我提出質疑
07/20 08:44, 38F
→
07/20 08:44, , 39F
因為在最原始的 Linux/Minix file system, 是採用
07/20 08:44, 39F
→
07/20 08:46, , 40F
zone 的方式來使得資料存在硬碟的同一個 cylinder
07/20 08:46, 40F
→
07/20 08:47, , 41F
可是在 http://0rz.tw/jzG8y An Improvement for
07/20 08:47, 41F
→
07/20 08:48, , 42F
MINIX File System:Design and Implementation 這篇
07/20 08:48, 42F
→
07/20 08:49, , 43F
文章中提到, there is no implied relationship
07/20 08:49, 43F
→
07/20 08:49, , 44F
between logical sector addresses and the actual
07/20 08:49, 44F
→
07/20 08:49, , 45F
physical location of the data sector
07/20 08:49, 45F
→
07/20 08:50, , 46F
因為都被 drive controller 給最佳化/隱藏掉了
07/20 08:50, 46F
→
07/20 08:51, , 47F
因此不是想寫哪邊就寫哪邊, 不太可能是因為寫入演算
07/20 08:51, 47F
→
07/20 08:52, , 48F
法的不同造成磁碟重組與否 @@
07/20 08:52, 48F
推
07/20 09:42, , 49F
寫入資料的演算法也是屬於檔案系統實作的一部分，我的說法跟
07/20 09:42, 49F
→
07/20 09:43, , 50F
他們的講法並沒有衝突。
07/20 09:43, 50F
推
07/20 09:57, , 51F
針對你的質疑，我先聲明實際底層的運作我也不懂。不過，它會
07/20 09:57, 51F
→
07/20 09:59, , 52F
對 ext2/ext3 造成的影響也一樣會對 FAT 造成影響吧。而且，
07/20 09:59, 52F
→
07/20 10:04, , 53F
雖然它說 logical 和 physical 之間沒有絕對的關係，但也許有
07/20 10:04, 53F
→
07/20 10:07, , 54F
其他辦法能達到某種程度上的相對關係之類的，我指的是相鄰
07/20 10:07, 54F
→
07/20 10:09, , 55F
logical 位置與相鄰 physical 位置間的關係。
07/20 10:09, 55F
→
07/20 10:10, , 56F
07/20 10:10, 56F
→
07/20 10:12, , 57F
Modern Linux filesystem(s) keep fragmentation at a
07/20 10:12, 57F
→
07/20 10:12, , 58F
minimum by keeping all blocks in a file close together,
07/20 10:12, 58F
→
07/20 10:13, , 59F
even if they can't be stored in consecutive sectors.
07/20 10:13, 59F
推
07/20 14:19, , 60F
這是一個很有趣的問題 我也想知道多一些
07/20 14:19, 60F
推
07/20 14:48, , 61F
我上星期也在跟學弟討論，為什麼ext4裡會有online defrag.
07/20 14:48, 61F
推
07/20 16:35, , 62F
因為不管怎麼好的檔案系統，久了還是難免會有 fragmentation
07/20 16:35, 62F
→
07/20 16:37, , 63F
的問題，所以 ext4 才會加入 online defrag，我上面引的那篇
07/20 16:37, 63F
→
07/20 16:37, , 64F
文章中有說。
07/20 16:37, 64F
※ operationcow:轉錄至看板 LinuxDev 07/20 21:27 ※ operationcow:轉錄至看板 WinNT 07/20 21:30 ※ operationcow:轉錄至看板 Windows 07/20 21:31
‣ 更多 operationcow 的文章
文章代碼(AID): #1AOgrxWD (Linux)
Linux 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 operationcow 的文章
文章代碼(AID): #1AOgrxWD (Linux)