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