作者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