[問題] 磁碟重整與否

看板WinNT作者 (香蕉公車)時間15年前 (2009/07/20 21:30), 編輯推噓0(0推 0噓 0→)
留言0則, 0人參與, 最新討論串1/1
※ [本文轉錄自 Linux 看板] 作者: operationcow (香蕉公車) 看板: Linux 標題: [問題] Linux 磁碟重整與否 時間: Sun Jul 19 13:22:02 2009 在請教問題之前, 先提供幾個網頁: 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,
問你一個問題：磁碟重組主要是要重組什麼？是檔案配置表還是
07/19 15:56
→
07/19 15:57,
實際資料所佔區塊？又何者所佔用磁碟空間較大，影響讀取時間
07/19 15:57
→
07/19 15:58,
較巨？
07/19 15:58
→
07/19 17:15,
實際資料所佔區塊
07/19 17:15
→
07/19 17:16,
所以應該兩個都要磁碟重組不是嗎?
07/19 17:16
→
07/19 17:19,
不過我記得 Tanenbaum 有一篇 paper 提到檔案大小大
07/19 17:19
→
07/19 17:20,
概是 1K(1 個 block), 這樣來看的話說不定 Linux 用
07/19 17:20
→
07/19 17:22,
inode 的方式反倒比較需要磁碟讀取, 這樣應該是 FAT
07/19 17:22
→
07/19 17:22,
比較吃香, inode 可以用 caching 和 磁碟重整 inode
07/19 17:22
→
07/19 17:22,
來獲得加速
07/19 17:22
→
07/19 17:23,
補充一下,上面提到的 paper 是 Mullender and
07/19 17:23
→
07/19 17:23,
Tanenbaum 在 1984 提出的, 對象是 Unix, 現在看可能
07/19 17:23
→
07/19 17:24,
有一點不合時宜, 剛剛打開我的資料夾,檔案多是幾十 k
07/19 17:24
→
07/19 17:25,
到幾百 k, 不過如果從文章中的分析, 應該是兩個都需
07/19 17:25
→
07/19 17:25,
要磁碟重整??
07/19 17:25
→
07/19 17:34,
我覺得應該是第一個耶...所佔區塊 應該是指容量大小吧..
07/19 17:34
→
07/19 17:34,
等版主來解答^^
07/19 17:34
→
07/19 17:42,
整個"檔案配置表"不可能比整個"資料所佔區塊"來的大
07/19 17:42
→
07/19 17:43,
這樣使用太沒效率了
07/19 17:43
→
07/19 17:45,
以一個20GB大的硬碟來說, 1kB/block, 大概是使用80MB
07/19 17:45
→
07/19 17:45,
的記憶體作為 FAT
07/19 17:45
推
07/20 07:26,
其實主要的差別是在寫入資料時所用的演算法，FAT 的做法比較
07/20 07:26
→
07/20 07:31,
偏向「見洞就鑽」型，它是挑第一個找到可以放得下資料的位置
07/20 07:31
→
07/20 07:33,
來用，但該位置不見得與檔案中其他資料的位置接近；ex2/ex3
07/20 07:33
→
07/20 07:35,
則會選擇儘量讓同一檔案的資料區塊放在附近，所以相較之下，
07/20 07:35
→
07/20 07:37,
ext2/ext3 就比較不會有 fragmentation 的問題。
07/20 07:37
→
07/20 08:36,
所以版主的意思是說鳥哥及某些文章所說的, 索引式檔
07/20 08:36
→
07/20 08:37,
案系統比較不需要磁碟重組是錯的, 問題是出在寫入資
07/20 08:37
→
07/20 08:37,
料的演算法??
07/20 08:37
→
07/20 08:38,
另外就是採用 block 使得資料在 physical view 產生
07/20 08:38
→
07/20 08:38,
不連續的現象似乎不叫 fragmentation??
07/20 08:38
→
07/20 08:39,
fragmentation 該是分 internal 和 external, 而
07/20 08:39
→
07/20 08:39,
internal 應該是跟 block 的大小與檔案的大小有關,
07/20 08:39
→
07/20 08:41,
external 在 block 的機制下應該是避掉了
07/20 08:41
→
07/20 08:42,
抱歉, 修正一下上面所說, 這種採用 block 而資料不連
07/20 08:42
→
07/20 08:42,
續的現象應該算是 data fragmentation
07/20 08:42
→
07/20 08:43,
07/20 08:43
→
07/20 08:44,
不過針對寫入資料的演算法那部份, 我提出質疑
07/20 08:44
→
07/20 08:44,
因為在最原始的 Linux/Minix file system, 是採用
07/20 08:44
→
07/20 08:46,
zone 的方式來使得資料存在硬碟的同一個 cylinder
07/20 08:46
→
07/20 08:47,
可是在 http://0rz.tw/jzG8y An Improvement for
07/20 08:47
→
07/20 08:48,
MINIX File System:Design and Implementation 這篇
07/20 08:48
→
07/20 08:49,
文章中提到, there is no implied relationship
07/20 08:49
→
07/20 08:49,
between logical sector addresses and the actual
07/20 08:49
→
07/20 08:49,
physical location of the data sector
07/20 08:49
→
07/20 08:50,
因為都被 drive controller 給最佳化/隱藏掉了
07/20 08:50
→
07/20 08:51,
因此不是想寫哪邊就寫哪邊, 不太可能是因為寫入演算
07/20 08:51
→
07/20 08:52,
法的不同造成磁碟重組與否 @@
07/20 08:52
推
07/20 09:42,
寫入資料的演算法也是屬於檔案系統實作的一部分，我的說法跟
07/20 09:42
→
07/20 09:43,
他們的講法並沒有衝突。
07/20 09:43
推
07/20 09:57,
針對你的質疑，我先聲明實際底層的運作我也不懂。不過，它會
07/20 09:57
→
07/20 09:59,
對 ext2/ext3 造成的影響也一樣會對 FAT 造成影響吧。而且，
07/20 09:59
→
07/20 10:04,
雖然它說 logical 和 physical 之間沒有絕對的關係，但也許有
07/20 10:04
→
07/20 10:07,
其他辦法能達到某種程度上的相對關係之類的，我指的是相鄰
07/20 10:07
→
07/20 10:09,
logical 位置與相鄰 physical 位置間的關係。
07/20 10:09
→
07/20 10:12,
Modern Linux filesystem(s) keep fragmentation at a
07/20 10:12
→
07/20 10:12,
minimum by keeping all blocks in a file close together,
07/20 10:12
→
07/20 10:13,
even if they can't be stored in consecutive sectors.
07/20 10:13
推
07/20 14:19,
這是一個很有趣的問題 我也想知道多一些
07/20 14:19
推
07/20 14:48,
我上星期也在跟學弟討論，為什麼ext4裡會有online defrag.
07/20 14:48
推
07/20 16:35,
因為不管怎麼好的檔案系統，久了還是難免會有 fragmentation
07/20 16:35
→
07/20 16:37,
的問題，所以 ext4 才會加入 online defrag，我上面引的那篇
07/20 16:37
→
07/20 16:37,
文章中有說。
07/20 16:37
※ operationcow:轉錄至看板 LinuxDev 07/20 21:27 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.243.43
‣ 更多 operationcow 的文章
文章代碼(AID): #1AP7643G (WinNT)