主題: ext2的檔案系統有抗破碎的能力

[被騎上班的老]

發信人: leolarrel@kkcity.com.tw (我是可愛的C++)
日期: 09 Jul 2002 03:25:57 GMT
標題: Re: 請問Linux優秀的原因
信群: tw.bbs.comp.linux    看板: TWBBS/linux/A0UIKLU5
來源: <41F0fL$Zyz@bbs.kkcity.com.tw>:218506, bbs.kkcity.com.tw
組織: KKCITY

> 還有人家說ext2的檔案系統有抗破碎的能力...所以不需要磁碟重組程式
> 那麼ext2是怎麼抗破碎的呢??

  我不清除何謂抗破碎拉,我只是知道,M$ 的 FAT 系列 是使用 鏈結串列
  來記錄資料 而 ext2 是使用 13 個指標來記錄

  一個檔案,用了3個叢區紀錄資料 FAT 紀錄這3個叢區的實作如下
  一個鏈結串列

  100 --> 120 --> 135 --> 結束符號

  你可以看見叢區不連續,這樣系統毒這一個檔案就會比較沒效率
  所以你需要磁碟重組成

  100 --> 101 --> 102

  這樣系統就不必浪費浪費時間找下兩個叢區,直接照順序讀入就可以了

   ext2 的做法

  一個13個指標的結構

  point 1 --> 100
  point 2 --> 120
  point 3 --> 135
  point 4 NULL
  ...
  point 13 NULL

  系統依照這些指標把資料讀入

  實際如何比較優劣,請其他懂得人接著寫下去吧

> 還有我希望各位大大能夠說明一下linux比windows的優越處及why
> 謝謝...

  前面有很多post 可看..
--
┌─────◆ＫＫＣＩＴＹ◆─────┐┐┌┐┐┌┐┌─┐┌┬┐┌┬┐┐  ┌
│         bbs.kkcity.com.tw          │├┘┐├┘┐│      │    │  └┬┘
└──《From:202.145.60.221     》──┘┘  ┘┘  ┘└─┘└┴┘  ┴    ┴

[twu2]

基本上不論那一種 FS, 都無法避免這個問題, 只是要看如何設計使這個問題造成的影響比較小...

fat 是一個比較簡單的設計... 所以很多東西都沒有考慮到... 拿來與現在一些 FS 比較, 可能真的無法比...

ext2 一樣有 defrag 的工具, 只是用到的機會不會那麼大...
linux 也不是只有 ext2 這個 fs, 只是目前多數的人都用這個.

[被騎上班的老]

ext2 一樣有 defrag 的工具, 只是用到的機會不會那麼大...

告訴我，我想知道這個工具叫什麼？

[梁楓]

ext2 一樣有 defrag 的工具, 只是用到的機會不會那麼大...

告訴我，我想知道這個工具叫什麼？

我也想知道

[twu2]

我不知道在其他的系統上有沒有這個 package, 如果是使用 debian, 可以裝這個

apt-get install defrag

就可以了...
不過我沒有執行過... 我現在用的系統, 好像沒有一個用 ext2, 都改用 XFS 了.
ext2 用的執行檔叫 e2defrag, 用 google 也找的到.

defrag - ext2, minix and xiafs filesystem defragmenter

As a file system is used, data tends to become more and more scattered
across the disk, degrading performance.  A disk defragmenter simply
re-organises the data on the disk, so that individual files occupy a single
sequential set of disk blocks, and all the free space on the disk is
collected together in a single region. Thie generally means that reading a
whole file is faster, and disk accesses in general are more efficient.

[被騎上班的老]

我有聽過一種方法，不過很笨。就是 tar 起來，然後殺光檔案再解開。

[ahlek]

>不過我沒有執行過... 我現在用的系統, 好像沒有一個用 ext2, 都改用 XFS 了.
>ext2 用的執行檔叫 e2defrag, 用 google 也找的到.

if i wan my redhat use other File system..
how i going to change..and still got what kind
of fs can using it
[/url]

[twu2]

if i wan my redhat use other File system..
how i going to change..and still got what kind
of fs can using it

for ext2 => ext3
just make a new kernel support ext3, and use 'tune2fs -j' to convert it.

for ext2 => others
make a new kernel with the filesystem support you want.
and get the userspace tools for the filesystem.

usually, you NEED to backup your old files and make a new filesystem, then restore it.

it is not a easy way for a running system.... :-(

[被騎上班的老]

以下純粹是我的猜測︰

defragment 對單工的機器有用，對多工的機器可能就不一定了。defragment 的用處是將實體存取位址連續化，但是在多工的作業系統，它可能同時在讀寫好幾個檔案，所以作了等於白做。

[duncanlo]

一顆硬碟不是就只有一組磁頭?!

[twu2]

不至於白做... 如果是單一的硬碟... 至少同一個時間只能存取一個固定的實體位置, 與 OS 多工沒什麼關係.
要讀取的資料放在一起, 讀起來一定會比較快...

至於實際運作時的效能差異, 如果分散的程度不大, 或許影響不會很大吧.
基本上, 如果一個 FS 說本身不用 defrag, 應該只是表示他的架構可以把分散存放的程度, 控制在一個可以接受的範圍, 且使用他的讀取演算法, 與全部連續放置之間差異小到可以忽略吧.

[jeffer]

但是在多工的作業系統，它可能同時在讀寫好幾個檔案，所以作了等於白做。

現在幾乎所有流行的os, 都是多工的作業系統.
如果是 server 上,常被同時要求同時存取 file , 也許真的沒什麼用,
但是據說novell, 會計算同時存取檔案的所在 sector 的相對位置,和磁頭的相對位
置,按順序來移動讀取.
不過這是針對os 來說, 可是有時考慮一下連續讀取的狀況.這也是滿多的case
例如同一database的資料查詢.
如果系統用了很久,破碎的情況很嚴重,重整是有其必要性.
而且有些 file 修繕程式, 對於連續的 file block ,有比較強的修正能力.

就 windows 系統來說, 重整之後, 速度確實有提升.

[duncanlo]

Rawdevice ?!

DB存在一個檔有時是很容易壞,像MS SQL...

[twu2]

不管是不是用 raw device 應該都一樣...
商用的 RDBMS 多數資料存放的空間都是先產生一個大大的檔案來放...
同樣也有碎裂的問題. 這個與 FS 比較沒關係, 因為對 FS 來說, 檔案還是連續的...
只是以 database 來看, 要取得的 data block 就不一定是連續的...

[duncanlo]

剛看了一下...
才發現twu2原來是以前光碟月刊的副站長,
希望老前輩多指教指教...

[twu2]

剛看了一下...
才發現twu2原來是以前光碟月刊的副站長,
希望老前輩多指教指教...

我看起來還是很年輕的...
那個副站長應該不是我... 在改成光碟月刊前我就去當兵了...

[duncanlo]

看了你網站的介紹才知道,
就是那個HopeBBS啦,
以前bbs上線還限時間,下載還限量,
不過在家上線花太多電話錢被家人罵,
還得到學校用telnet上...

[被騎上班的老]

例如同一database的資料查詢.
如果系統用了很久,破碎的情況很嚴重,重整是有其必要性.
就 windows 系統來說, 重整之後, 速度確實有提升.

資料庫的系統，基本上它會把資料放到 RAM 裡面來操作。所以如果重複讀取或處理都是在 RAM 裡面處理。如果每個 access 都要作實體的存取那還得了。

如果是一般的檔案，cache/buffer 也會處理。ext2 基本上每 30 秒才 sync 一次。

[twu2]

資料庫的系統，基本上它會把資料放到 RAM 裡面來操作。所以如果重複讀取或處理都是在 RAM 裡面處理。如果每個 access 都要作實體的存取那還得了。

如果是一般的檔案，cache/buffer 也會處理。ext2 基本上每 30 秒才 sync 一次。

不管是否有 buffer, 最後不是一定要讀寫實體的位置嗎 ?
存放位置的碎裂問題一定會存在, 你所提的方法都只能降低發生時的影響大小... 只要小到某個能接受的地步, 就可以忽略了.

DB 的碎裂問題, 在一開始可能都會被忽略, 但是, 如果你的系統真的用到某一天, 這個問題已經影響整個 DB 的效能時, DBA 就算想忽略這個問題, 你的使用者可能也沒辦法接受...

[被騎上班的老]

不管是否有 buffer, 最後不是一定要讀寫實體的位置嗎 ?
存放位置的碎裂問題一定會存在, 你所提的方法都只能降低發生時的影響大小... 只要小到某個能接受的地步, 就可以忽略了.

DB 的碎裂問題, 在一開始可能都會被忽略, 但是, 如果你的系統真的用到某一天, 這個問題已經影響整個 DB 的效能時, DBA 就算想忽略這個問題, 你的使用者可能也沒辦法接受...

我很好奇的問︰有哪家的資料庫廠商有提出這種建議來增快資料庫的速度？

[duncanlo]

有些DB的Troubleshooting或Tunning章節有提到一下,
像Oracle,DB2,Notes(這應該不算DB)好像有說到Defrag的問題...忘了!

[twu2]

ORACLE 在 performance tunning 上面就會提到. 基本上一個 table 在多次的異動之後, 資料的存放及索引的連續性就可能與最佳化的狀態有段差距, 資料的重整與索引的重建都有其必要性.

其他的資料庫沒有深入研究, 不很清楚...

defrag 只是一個系統在 tunning 時的一環, 而 tunnnig 的重要與否是要看使用者的需求而定的, 並不是每個系統都必須花時間去調整, 要如何取得這個平衡點是要每個管理員自己去決定的.

今天, 使用者對於如果讀取一個資料的可接受時間如果是 1 秒, 你的系統在最佳的情形下只要 1/1000 秒就做完, 而如果在碎裂嚴重時, 要 1/100 秒才做完, 這時候, 是否有必要花時間去重整呢 ? 使用者可能不會覺得 1/1000 與 1/100 之間有所差異 (雖然差了 10 倍). 相反的, 如果最佳時要 10 秒, 嚴重時要 20 秒, 雖然只有 1 倍的差異, 但是使用者的感覺就可能差很多...

[duncanlo]

忘了是那個DB還是Notes,
AP本身有提供一個類似重整或壓縮的工具,
作法有點像就是defrag,
不過我也沒玩到進階的部份,
感覺不到差異在那?

不過原廠是說,當你的DB檔已是GB等級時,
就會有較明顯的差異?!

twu2有沒有比較具體經驗可以分享?
因為一般人比較少有機會遇到,
我也很好奇!

[twu2]

雖然我這兒的資料庫我開了上百 G 的空間, 不過還是沒有這個經驗...

一般來說, 那個 tunning 已經是在很多 tunning 都無法解決時, 才會去考慮的吧.
在我們的系統... 目前看來, 一般的 SQL tunning 就有很大的效果.

實際 table 的重整可能很難有機會做到, 不過 index rebuild 就應該是在一段時間的使用後就可以考慮看看.

ORACLE 的 enterprice manager 就有一個重整的工具, O8 時好像叫 re-org... 什麼的.. o9 中好像叫 tablespace map 的工具, 就好像可以線上做重整, 像一般 disk 的 defrag 那樣.
不過... 那個功能要裝 management server, 利用 agent 才能執行... 我在 O9 之後的版本, 試裝過幾次都沒成功, 就沒再試過了... O8 時有玩過, 不過資料不大, 所以也不知道有什麼差別...

[duncanlo]

有時實際要作Tunning時,真的是要經驗,並且算算是否合乎成本!

一般來說, 那個 tunning 已經是在很多 tunning 都無法解決時, 才會去考慮的吧.
在我們的系統... 目前看來, 一般的 SQL tunning 就有很大的效果.

記得前公司,有廠商拿個什麼FastSQL還QuickSQL的軟體來推銷,
號稱用這軟體改過之後的SQL語法可以變成2x,3x以上的效率,
公司的一個DBA試過真的是比較快,有人有玩過這東東嗎?
(公家機關自己有寫程式好像多有買!)

[twu2]

記得前公司,有廠商拿個什麼FastSQL還QuickSQL的軟體來推銷,
號稱用這軟體改過之後的SQL語法可以變成2x,3x以上的效率,
公司的一個DBA試過真的是比較快,有人有玩過這東東嗎?
(公家機關自己有寫程式好像多有買!)

不同的 SQL 寫法, 抓出同樣的資料, 可以會差到數十倍吧.
上述的東西, 如果對一個已經是最佳的 SQL 來說, 沒有什麼作用...

花那個錢我會覺得不值得, 寧願花時間教程式設計人員怎麼寫出正確的 SQL...
反正規則也不多, 多寫個幾次就可以寫出不至於效能太差的 SQL 了.

[被騎上班的老]

ORACLE 在 performance tunning 上面就會提到. 基本上一個 table 在多次的異動之後, 資料的存放及索引的連續性就可能與最佳化的狀態有段差距, 資料的重整與索引的重建都有其必要性.
...

你的意見啟發了我下面的看法︰

對資料庫而言，index 才是資料讀取的順序。如果一個 table 有兩種以上的 index ，資料要怎麼放磁碟的讀取才會連續？

所以看起來是這個樣子︰index 檔需要 defrag ，因為這是每次都要從頭讀到尾。table 就不需要了，除非你不建 index。

這樣的結論，各位以為如何？

twu2 也提及一個重要的觀點︰就是效益的問題。或許這個問題對系統效能無關緊要，不過難得有資料庫的專家在，我想在資料庫這邊多深入討論一點。

[duncanlo]

ORACLE 在 performance tunning 上面就會提到. 基本上一個 table 在多次的異動之後, 資料的存放及索引的連續性就可能與最佳化的狀態有段差距, 資料的重整與索引的重建都有其必要性.
...

你的意見啟發了我下面的看法︰
對資料庫而言，index 才是資料讀取的順序。如果一個 table 有兩種以上的 index ，資料要怎麼放磁碟的讀取才會連續？
所以看起來是這個樣子︰index 檔需要 defrag ，因為這是每次都要從頭讀到尾。table 就不需要了，除非你不建 index。
這樣的結論，各位以為如何？
twu2 也提及一個重要的觀點︰就是效益的問題。或許這個問題對系統效能無關緊要，不過難得有資料庫的專家在，我想在資料庫這邊多深入討論一點。

這種深入,實務,經驗的話題應該是值得討論!

是不是也要考慮View的功能,View建的好,是可以增加一些效率!

[twu2]

所以看起來是這個樣子︰index 檔需要 defrag ，因為這是每次都要從頭讀到尾。table 就不需要了，除非你不建 index。

重整也可以依照某個索引來排.. 所以, 多少有些效果.
至於索引, 多數都使用 B+Tree 吧, 可能不算是 defrag 的問題.. 只是 tree 在經過多次的異動之後, 就會不平衡, 失去索引的效果, 所以在每隔一段時間之後, 就有重建的需求. 算是 rebuild 不是 defrag...

[twu2]

是不是也要考慮View的功能,View建的好,是可以增加一些效率!

別的資料庫不熟, 不太清楚, 不過在 ORACLE 中, view 的作用我覺得只在於簡化程式寫作時的困難, 對於效能來說, 應該和直接使用 table 是一樣的. (這點是我的直覺, 不確定實際上是否如此)

因為在查詢一個 SQL 的 plan 時, 就算使用 view, 也都是轉成 table 做解釋.
且 view 也沒有 index 之類的功能, 還是只用 table 的 index.