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