今天的 Tetralet 又在唧唧喳喳了文章彙整管理介面 --> 站內搜尋

前幾天公司的電源瞬斷，我的一台使用 reiserfs 的主機就此再也無法開機：『root 檔案系統損毀』。後來拔硬碟到另外一台電腦做 fsck 之後是復活了，但也嚇出了我一身的冷汗。長久以來總一直聽到有關 reiserfs 的種種負面評論，親身體驗之後才知道真的不是一般的恐怖。於是興起來把我所有主機裡的 reiserfs 丟掉的念頭。

要轉換檔案系統是很麻煩沒錯。但最麻煩的是：該選擇哪一種檔案系統才好？Google 了半天，幾乎各種檔案系統都有其支持者和種種見証及說法讓人無所適從，甚至種種測試報告及使用心得，其結論都大異其趣，還真叫人不知該聽信哪一個才好。於是我決定自己動手測試，畢竟自己動手測過，感覺才會實在。

測試環境：

CPU：Intel(R) Pentium(R) 4 CPU 2.80GHz
RAM：1GB（其中約 600 MB 掛載為 tmpfs）
Kernel：2.6.29-RC1
Swap：(none)

參加測試的檔案系統簡介：

ext2：老牌 Linux 檔案系統，不支援 journaling。
ext3：當今各大 Linux 預設使用的檔案系統。支援 journaling。
ext3 (data)：加上 journal_data 功能的 ext3。
ext4：ext3 的下一版本。已正式進入 kernel 2.6.28 中。
reiserfs：號稱最快的 FS。Linux 上第一個支援 journaling 的檔案系統。
reiserfs (data)：加上 journal_data 功能的 reiserfs。
reiser4：reiserfs 的下一版。（尚未進入 kernel 中）
jfs：由 IBM 所開發的 journaling 型檔案系統。已停止開發。
xfs：由 SGI 所開發的 journaling 型檔案系統。
vfat：古老 DOS/Windows 檔案系統，不支援 journaling。
ntfs：現今 Windows 的主流檔案系統。在 Linux 上是經由 fuse 來支援 ntfs。
zfs：由 Sun 所開發的終極檔案系統。在 Linux 上是經由 fuse 來支援 zfs。
btrfs：下一代 Linux 預設使用的檔案系統。已進入 kernel 2.6.29 RC1 的測試分支中。

測試方式：

把 Swap 關掉。這是為了避免 Swap 到硬碟會影響測試結果。
將650 MB 掛載為 tmpfs。因為 1GB 的 RAM 太大了，故意減少 RAM 的空間。據說測試資料要是 RAM 的 2 倍，結果才會較準確。不過要有塞資料給 tmpfs，它才會真的佔用 RAM 的空間，所以敝人計劃要塞 Debian Etch 的 iso 檔進去，並把它當作資料來源。
把 Debian Etch 的 iso 檔複製到 tmpfs 裡。
掛載該 Debian Etch 的 iso 檔。因為 RAM 的讀取速度應該會遠大於硬碟的讀取速度，用 RAM 當資料來源比較不會影響到測試結果。
開始將該 iso 裡的檔案及目錄複製到測試分割區裡。然後刪除約一半的檔案。如此重覆 24 次。這是模擬人們使用硬碟會不斷寫入刪除資料的動作，讓磁碟裡的資料散亂。最後將硬碟寫滿。
再刪除一部份資料以空出空間做為測試用。如此硬碟裡的資料應該算是十分散亂了。
開始測試資料的讀出、寫入、列出、搜尋、計算剩餘空間等等。並記錄其時間及 CPU Loading。

以下為測試結果：

剛開始寫入硬碟的速度：

btrfs 不愧是下一代 Linux 預設使用的檔案系統，速度實在驚人，竟然連 reiser4 都追不上。

而 ext3 / jfs / xfs 就真的有待加強了。ext3 慢 btrfs 約 36%，jfs 慢 btrfs 約 40%，xfs 慢 btrfs 約 60%。

而加上了 journal_data 功能的 reiserfs 及 ext3 就更慢了，因為所有的資料都要寫入硬碟 2 次。

zfs 和 ntfs 由於是用 fuse 實作的，所以實在慢得可憐。

在磁碟裡的資料散亂後，寫入硬碟的速度：

看來，在磁碟裡的資料散亂後，btrfs 會有 fragment 的問題，速度上己被 reiser4 追過。但還是遙遙領先其它的檔案系統。

此時，ext3 慢 btrfs 約 27%，jfs 慢 btrfs 約 30%，xfs 慢 btrfs 約 60%。

fragment 的比率：

這是資料在最剛開始及最後時，寫入速度的比較。jfs 的表現令人驚豔，但也慢了約 13%；btrfs 和 xfs 就有待加強了，約慢了 23% 左右。

ntfs 和 zfs 也許不是 defragment 做得好，而可能是因為碟裡的資料是否散亂已不是速度的瓶頸 - 用 fuse 來實作的速度實在太慢了，慢到連磁碟 I/O 變慢了都不太影響到測試結果。 XD

讀出、寫入、列出、搜尋、計算剩餘空間等等的效能表現：

reiserfs 不愧是檔案系統的效能之王，佔據了前 1、2 名。而 jfs 則慢了 reiser4 約 40% 左右，xfs 則是慢了 reiser4 約 65% 左右。差距實在很大。

不過在本測試中，操作的多是一些 < 10MB 的小的檔案，對於像是 xfs 這類適用於 > 500MB 大檔案的檔案系統其實並不公平。但個人認為 Linux 系統裡本來就是充斥著小檔案，所以其實也有必要如此測試才行。

敝人也試著用 > 500MB 的大檔案來進行測試，除了 ntfs 和 zfs 之外，最慢的 jfs 也只比最快的 reiser4 慢約 13%，個人認為差距沒有想像中大。

據說 xfs 在操作 > 1TB 的檔案的速度是其它檔案系統完全比不上的：xfs 要刪除一個 1TB 的檔案和刪除 1KB 的檔案所花費的時間是一樣的；但若是 ext3 則可能要刪上幾個小時。但因為敝人實在沒有什麼操作 1TB 檔案的機會，所以這個功能對敝人而言實在是英雄無用武之地。

另外，每個人、甚至每個目錄操作檔案系統的習慣都不同，有的目錄（像 /var）常在做讀寫動作；而像 /usr 就讀取比較多，/home 則用ls、讀寫的機會比較高，find 和 du 因為會耗費大量磁磁 I/O 敝人就不常用...一個測試要能完全模擬人們使用磁碟的習慣是不可能的。所以這個測試一定有其不準確的地方，僅供參考。

CPU 使用量：

如圖，藍色的是 %user，紅色的是 %system，而黃色的是 %iowait。大部份的檔案系統的 %user 都不到2%，差距實在不大；ntfs 和 zfs 是運作在 user space，所以數據才會如此嚇人。而在 %system 上，xfs / jfs /ext3 都約在 10% 上下，其實算是不錯的了。reiserfs 約是 20%，而 btrfs 則是33%，應該是還有很多的調整空間。xfs 竟然還有 18% 是 idle 的，實在太驚人了。要不是 xfs 有著一些較為不足之處，其實敝人光看這個數據，真的會直接轉用 xfs。

磁碟空間使用量：

這個數據是指，當 zfs 塞滿後，用同樣的資料量去塞別的檔案系統，會佔用多少硬碟空間。

xfs/btrfs/reiserfs/vfat/ntfs/jfs 的比率十分接近，而 ext2/3/4 的表現就很糟了。使用ext2/3/4 會無謂得浪費很多硬碟空間，在本測試中，ext3 會比 xfs 多佔用 12% 的硬碟空間，ext3 據說要再保留 10%的硬碟空間否則效能會嚴重下滑，想想真的是太超過了。zfs 則是磁碟空間使用量最大的。

另外，圖中 btrfs 的硬碟使用率極佳，但在個人的測試裡，btrfs 只到約 86% 就回應已無可用空間，但 btrfs 不是支援動態inode 嗎？真令人百思不解。最下方那條 btrfs (guess) 是假設，若那 14% 是被 btrfs 暗槓掉的話，那麼 btrfs 真正的使用空間應該會再多上 16%，那麼它的使用空間就會比 zfs 更多了。

請注意，隨著分割區大小的不同，以上的數據將會跟著不同。

敝人對以上各種檔案系統的評語：

ext2：

在隨身碟上可以考慮使用這個格式，以減少磁碟讀寫，延長隨身碟使用年限。

無謂得浪費很多硬碟空間。

ext3：

因架構上的優勢及長年的開發測試，據說有著最可靠的回復能力。

在掛載硬碟時，可用 -o journal_data 啟用 data journaling 功能。那麼，在寫入磁碟時，會先把資料內容先寫入journal 裡，然後再真的寫到磁碟上，如此能有效再進一步降低資料丟失的機率。不過因為資料會寫入磁碟 2 次，效能也會因而大幅下滑。

沒有 undelete 功能。

在開機時會視情況進行自我檢查。有時會等上半小時。非常令人不耐。ext4 據說有試著解決這個問題了。
可用：

tune2fs -c 0 -i 1m /dev/hdXY

來關閉 max-mount-counts，讓它不會在掛載多次後便進行 fsck；並設定 interval-between-checks 為 1 個月。

除了 journal 會佔用大量的硬碟空間之外，有人建議至少要保留 10% 的未使用空間，否則會造成 ext3 效能低落。

ext4：

向前相容於 ext3，但有著更可靠的 checksumming in journal 功能。

在個人測試中，速度可逼進 ext2。

和 ext3 類似的，會無謂得浪費很多硬碟空間。

加快了 fsck 的速度。

可線上重整。

reiserfs：

速度飛快。這也是之前敝人選擇這種檔案系統的主因。

和 ext3 一樣，也支援 data journaling 功能。不過效能也會大幅下滑。

有些目錄的操作是非同步的，不太適合用於某些系統（像 postfix）上。

會佔用較多的 CPU 及記憶體。較適合用於較新的電腦上。

回復能力較差。常常有人抱怨說，硬碟裡的資料在不正常斷電後就一去不回了。

掛載及卸載速度很慢，嚴重影響到開機速度。

個人在使用時，偶爾偶爾在搬移檔案時會出現 Disk I/O 100% 超過 30 秒的怪事。

隨著主要開發者入獄，開發工作幾近停頓了。

reiser4：

改進了 reiserfs 的眾多缺點，且速度比 reiserfs 更快！

隨著主要開發者入獄，開發工作幾近停頓，應該不可能進入 kernel 了。

xfs：

在操作一些充斥著小檔案的目錄，或是在大量新增或移除檔案或目錄時，速度很慢。因此不太建議使用在 / 上。

在操作 > 200MB 的檔案時有其優勢。但個人以 600MB 的檔案實測結果是相差無幾。

可線上重整磁區。

只要使用時日一久，效能下降得很嚴重。

沒有 undelete 功能。

有報告指出，在強迫關機後，甚至只是 umount，檔案可能因而損壞且難以復原。

在所有的檔案系統中，佔用最少的 CPU Loading。

掛載及卸載速度極快。

仍在開發維護中。

jfs：

佔用較低的 CPU Loading。

綜合比較起來，速度會比起 ext3 快上一些些。

據說其修復能力可以和 ext3 比擬。

磁碟較不容易有 fragment 的問題。

掛載及卸載速度極快。

可將 journal 放到另一顆硬碟上，不過在實作上是有點麻煩。

在刪除大量檔案時速度很慢。

雖然 IBM 開發這個磁碟系統時間超過 10 年，但在它在 Linux 真正普及之前就已停止開發了，所以使用的人並不多。所以是否有潛在的問題也未可知。

Debian Installer 預設就會提供 fsck.jfs。

vfat：

還是很常見於數位相機、數位攝影機、手機等等攜帶裝置中。

速度中下，且不支援 journaling。

磁碟 fragment 的問題很嚴重。

ntfs：

因為是經由 fuse 來支援 ntfs 的，所以速度很慢很慢。但對於還在使用 Window/Linux 雙系統的使用者而言，它仍是一個很重要的工具程式。

在個人測試中常導致 Kernel Panic。

zfs：

雖然號稱是終極檔案系統，但因為授權的因素而無法進入 kernel 中，因而是經由 fuse 來支援 zfs 的，所以速度很慢很慢。在 Linux 上幾乎沒有競爭力。

btrfs：

基本上是為了向 zfs 看齊而開發出來的 Linux 終極檔案系統。

支援一些很先進的磁碟功能，像是磁碟快照、磁碟陣列、動態掛載等等。

在速度上也是傲視群倫。

更可靠的 checksumming in journal 功能。

有對 SSD 做最佳化。

可線上重整磁區。

尚在測試實驗階段，連基本架構都未定案。

於是，幾經考慮，在 btrfs 推出之前，在 ext3、reiserfs、jfs 和 xfs 等 4 種檔案系統之間，敝人的首選應該會是jfs - CPU Loading 低、硬碟使用率高、效能中上、回復能力佳。至於 IBM 已停止開發 jfs 一事，我想只好先不管了。

不過，關於資料回復一事，其實以上的評論大多來自網路一些使用者本身的使用經驗。但同是 ext3，有些人說它的回復能力是其它檔案系統所比不上的，但也有使用者回報他的 ext3 死了無數次。所以這些評論請頂多當作參考，不要太過相信呀！

而要讓磁碟資料長保安康，請確保：

記憶體務必好好測過。有問題的記憶體是硬碟資料殺手。
請安裝 UPS。電腦常不正常關機肯定會影響到磁碟資料的。
要進行可能會 kernel panic 的動作，像測試 kernel module 前，請先祈禱。
備份、備份、備份，永遠不嫌少。

然後，再加點運氣，也許那些磁碟資料真能跟著您直到天長地久、海枯石爛呢！

迴響

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

load kernel: /vmlinuz ...... mem=256M (or something).
tmpfs use little memory (if nothing is stored).

[回應] noname @ 24/01/2009, 22:10

Re: noname

所以才會把 Debian Etch 的 iso 檔複製到 tmpfs 裡呀！

修正：依您的意見在文中加註了。感謝您的意見！

[回應] Tetralet @ 24/01/2009, 22:53

上了 solidot 耶！

剛剛在 solidot 看到 Tetralet 的這篇文章耶！ :D

http://linux.solidot.org/article.pl?sid=09/01/25/1426251

[回應] yurenju @ 26/01/2009, 01:13

Re: yurenju

呵，努力辛辛苦苦測了好幾天也不算白費了。

感謝告知！

[回應] Tetralet @ 26/01/2009, 17:58

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

T大好文！一定要推的！

[回應] winlin @ 26/01/2009, 20:55

btrfs

我竟然沒聽過

[回應] gcin @ 27/01/2009, 10:53

Re: gcin

在 Linux 上竟有劉老大沒聽過的事，也算稀奇了 XD

[回應] Tetralet @ 27/01/2009, 16:35

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

我在内陆拜读大作，遗憾因某些原因不能阅读图片。关于“讀出、寫入、列出、搜尋、計算剩餘空間等等的效能表現”部分可否文字描述一下（读出、写入、搜寻/reiserfs、btrfs、jfs）？上文可只是说reiserfs占据了前一、二名，呵呵

[回應] 学习 @ 29/01/2009, 21:32

Re: 学习

我把圖片換到 Google 上了，希望 GFW 不會擋... orz。
若還是看不到圖片請不吝回報。謝謝！

[回應] Tetralet @ 30/01/2009, 00:59

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

看到图片了，谢谢！

[回應] 学习 @ 30/01/2009, 20:54

图片终于能看到了

谢谢哪！不需要发动穿墙术了

[回應] Chung @ 31/01/2009, 21:25

这里是不是写错了哪

ext4：ext3 的下一版本。已正式進入 kernel 2.9.28 中。
btrfs：下一代 Linux 預設使用的檔案系統。已進入 kernel 2.9.29 RC1 的測試分支中。

kernel "2.9.28".....

[回應] Chung @ 31/01/2009, 21:32

难得好文章

用过REISERFS，MOUNT速度慢
XFS，TAR文件，删除文件慢
JFS，刚想换，看了这个文章，更想换

[回應] katost @ 31/01/2009, 22:32

Re: 这里是不是写错了哪

Linux 2.9.28
现在的评测家真是超前。

[回應] lag @ 01/02/2009, 00:21

Re: Chung & lag

呀～寫錯了... orz

感謝兩位的指正！

[回應] Tetralet @ 01/02/2009, 00:29

Re: katost

換 ext3/ext4？ XD

真希望 btrfs 快點出呀～～不過可能要等到 Debian Squeeze 吧？ orz

[回應] Tetralet @ 01/02/2009, 00:33

关于btrfs

有几点想说一下
首先是空间使用的问题，2.6.29RC1中的btrfs还不能很好地处理ENOSPC，为了防止在空间满时出现kernel panic，代码内部预置了一条86%的红线，超过这个范围就直接视为空间满不允许再写入了。

另外同样是由于目前BTRFS中有效统计实际的磁盘占用很困难，在用户态直接得到的磁盘占用大小是不准确的。

BTRFS目前的磁盘格式还算稳定，看起来不会有什么变动了。

BTRFS处理随机写时有极大优势。

[回應] Roy @ 01/02/2009, 12:19

Re: Roy

原來如此！（恍然大悟）

感謝您提供的資訊！

[回應] Tetralet @ 01/02/2009, 15:18

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

今天看到國外對 ext4 的測試，給各位參考參考。
http://tinyurl.com/9pgj6t , http://tinyurl.com/5ebp97
我不太會解讀，不過看起來似乎比 JFS 好耶，讓我想在 Ubuntu 9.04 推出的時候改用 ext4 看看。

[回應] Nelson @ 03/02/2009, 12:59

deprecated ext3

ext3 基本上我已經死過無數次了
只要大量讀寫的過程中故意踢掉電源
很快的你就會見到 filesystem corruption.
JFS 用了很久, 倒是沒發現過怪問題
甚至有一次把損壞的 RAM 插上
svn co 竟然就發現無法寫入(remount-ro)

[回應] dou0228 @ 03/02/2009, 13:39

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

楼主主要测试了小于10M的文件，这个测试适合于个人电脑吧。

我倒很关心文件系统在服务器（server/伺服器）上的表现。本文测试受到了大家的关注，楼主有没有兴趣继续测试一下服务器上的文件系统。我觉得这两个测试是重要的：

1、一个包含很多文件的目录下读写/查找速度。测试一个目录包含100、1000、10000、100000个文件时的读写速度。预计reiserfs/reiser4将会大幅领先于其它FS，甚至有倍数级的差异。btrfs可能和reiser一样优秀。

2、不同大小的文件在不同文件系统下的读写性能差异。测试文件大小为0.5K、3K、5K、20K、50K、500K。预计reiserfs/reiser4在0.5K、3K的文件读写上会比另外的一些FS快几倍甚至10倍以上。

通过测试，希望找到这两个问题的答案：

1、如果一个目录下存放100000个3K的小文件（如照片的缩略图），reiserfs能不能创造比另外一些FS快50倍的读写（主要是读/查找了）的成绩。

2、如果要存储100000个3K的文件，一些慢速的FS以什么方式处理目录（例如分拆目录，每个目录保存10、100或1000个文件）是否可以提高读取/查找速度，提高到什么程度。

本文测试首次把btrfs、reiser4和ext4等FS包含在一起对比测试，这非常有价值，谢谢！

[回應] server @ 03/02/2009, 15:28

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

能否請教測試中xfs所使用的參數...以小弟經驗下列參數會有令人印象深刻的表現
mkfs.xfs -l size=128m,lazy-count=1
mount -o logbufs=8,logbsize=128k
此外，穩固性上的問題建議掛載參數加上-o barrier，雖然會對效能有影響，但不容易產生資料遺失的問題！印象中etx4也將會支援此參數

[回應] Jing @ 04/02/2009, 20:51

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

忘了問一件事...io scheduler用的是...？
xfs跟jfs在deadline會有比較好得表現！

[回應] Jing @ 04/02/2009, 21:02

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

barrier 在 ext4 已經是 default 了
scheduler 雖然會有影響, 但是底層的 filesystem 實作影響更大.

[回應] dou0228 @ 04/02/2009, 21:43

Re: Jing

我是有試過以下參數：
mkfs.xfs -l size=128m mount -t xfs -o logbufs=8
但結果似乎差異不大，所以我就沒有把測試結果放進去了。也許試試您的參數會有不一樣的結果吧？

Debian 的 Kernel 都是預設使用 cfq。有機會敝人會試試 deadline 的。

另外，在 kernel 2.6.17 後在 xfs 上就會預設啟用 -o barrier 了。

[回應] Tetralet @ 05/02/2009, 14:12

Re: server

有機會敝人會依照您的建議試試看的。
謝謝您的意見！

[回應] Tetralet @ 05/02/2009, 14:14

xfs 的穩定度

我之前也是遇到公司出貨的機器用ext3和reiserfs 因為斷電或是不正常關機之後整個檔案系統再見的

倒楣事，而且發生的頻率還很高，但是在我換成xfs之後這幾年幾本上除了硬體的問題而造成檔案系統

掛掉之外機可以說是再也沒發生過了。

所以我到在儘管出了那麼多的新系統加上他效能不是最好的但是我還是還一直在用xfs。

在歷經了那麼多次的檔案系統損毀，我覺得穩定度勝過速度，因為你不知道你的資料他哪

一天會直接飛上天不見了。

[回應] Arian @ 11/02/2009, 11:44

Re: Arian

真的出人意料之外的說法！因為我常聽到的反而是說 xfs 的修復能力不佳說！

敝人會把您的意見加註在本文中的。謝謝您提供的意見！

[回應] Tetralet @ 11/02/2009, 15:57

測試 Journal 真假

http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/1470.html

直接測試檔案系統是否真的算是 journal..

ext3 是直接過不了該測試

[回應] dou0228 @ 11/02/2009, 16:15

Re: Re: Arian

主要是我們公司出貨的db上面都run xfs，而我自己也實際去手動關掉電源

10幾次都沒發現有問題，真的有出問題真的都是hardware出問題。

出貨的機器都有幾百台了，所以到現在我連自己用的機器都用xfs

基本上系統碟可以用效能好的fs，但是資料碟我是覺得沒必要拿資料去做賭注。

至於jfs我在8-9年前還在alpha的時候有用過當時的印像是還不穩定而且總覺得

IBM時只是為了湊熱鬧而拿出來的所以就一直沒用到現在。

再來reiserfs在死過那麼多次在加上他原始的開發者因為被懷疑謀殺他老婆被抓去

關之後我就再也沒碰過了。

[回應] Arian @ 11/02/2009, 17:32

Re: Re: Re: Arian

XFS 我在 2.6.18 跑過
不跑 xfs_freeze 是沒出過包.. 不過如果跑 xfs_freeze + lvm snapshot.
就等著瞧

JFS 穩定性是 ok, 如果 AIX 上面跑的是 ext3.
我想今天 IBM 恐怕會賠錢賠很慘..

[回應] dou0228 @ 11/02/2009, 17:59

Re: Re: Re: Re: Arian

我倒是沒用xfs_freeze + lvm snapshot我用的是比較單純的

xfs+lvm2，下次有機會我會試看看xfs_freeze + lvm snapshot。

因為我們是要出貨的商品一些比較特別的功能我是比較不會想碰

除非有必要，因為有可能會跟別人打架。

另外請問大大一下有什麼場合會需要用到xfs_freeze + lvm snapshot呢？

倒是我最近要把系統換成64bit的卻發現32bit建的lvm在64bit下面會開不起來。

[回應] Arian @ 11/02/2009, 18:32

Re: Re: Re: Re: Re: Arian

online backup :P

1. stop services
2. lvm snapshot
3. mount snapshot
4. start services

雖然 xfs_freeze 希望可以不要執行 1, 4 步
但是我最後發現, 還是回頭跑比較安全

[回應] dou0228 @ 11/02/2009, 18:42

Re: Re: Arian

我是沒做過online backup的一般都是也是跟客戶橋好時間
把整個db停掉在做backup，通常都在凌晨比較多。

最近遇到32bit的linux無法抓到30TB的disk，用lvm也是只能抓到
14TB,所以只好做成2個lvm group，但是卻發現要換64bit linux 的時候
會不認得32bit建的lvm，再來是用舊版的mkfs.xfs會無法format 30TB的disk
換成新版之後就可以。

基本上我是覺得xfs 比起其他的filesystem穩定度算是很高的又不太吃cpu
至少他也是由SGI的IRIX出來的，目前也好像還是由sgi在維護中，算是一個活動度
高的project。

只是不知道你現在用的fs是哪一種？

[回應] Arian @ 12/02/2009, 14:53

Re: Re: Re: Arian

現在個人是選擇 JFS, ext3 是被我強制移除, 沒得用 :P

XFS 對 DB 來說應是最佳選擇.
只不過, 希望降低 backup 時, service down time
我選擇是 lvm snapshot :P

有機會找個 16T or 32T 的機器來試一下 mkfs.{jfs, xfs}
您注意一下是不是有開啟 CONFIG_LBD @ .config ? (CONFIG LARGE BLOCK DEVICE)

因為照規格來說, JFS & XFS 不應該有 TB 的限制才對.

CONFIG_LBD 已經把 sector_t define 為 u64

@include/linux/types.h

#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif

[回應] dou0228 @ 12/02/2009, 15:05

Re: Re: Re: Re: Arian

我有開啟CONFIG_LBD選項因為沒開我記得只能抓到2TB
xfs是沒有TB的限制，問題出在parted就是切不出大於8TB的
partition，用lvm也只能勉強撐到14TB在上去它也是無力阿.....

但是當我換到64bit之後就可以切出單partition 32T了，除
了原先mkfs.xfs太舊沒辦法format之外其他都正常。

所以我這邊的發現是32bit的disk上限是在8TB，用lvm2上限大概在
14TB，所以客戶納編現在是run 32bit linux + lvm2 (14TBx2) x2套，但
是問題來了，當我換到64bit linux之後lvm不給我mount，pvscan根
本就沒看到東西，這下就頭大了根本不知道要怎麼搬。

[回應] Arian @ 12/02/2009, 16:50

Re: Arian

直接把 partition type 改成 0xee ( EFI GPT )

照 sfdisk 說法:
A partition descriptor has 6 fields:
struct partition {
unsigned char bootable; /* 0 or 0x80 */
hsc begin_hsc;
unsigned char id;
hsc end_hsc;
unsigned int starting_sector;
unsigned int nr_of_sectors;
}

即 start sector and number of sectors 均為 unsigned int(4 bytes @ 32bit)
http://en.wikipedia.org/wiki/GUID_Partition_Table

請參照 :)

[回應] dou0228 @ 12/02/2009, 17:30

EFI GPT

抱歉我忘記提到我已經有把partition type改成GPT了，但是就算是用gpt還是有8TB的上限，因為沒用gpt根本無法超過2TB，但是沒加CONFIG_LBD我記的好像也是只能看到2TB，超過就算dmesg有看到超過2TB的disk一樣是只能切出2TB :) 用gpt label有個好處就是可以直接用lvm，partition建完直接就可以用pvcreate了，但是用gpt有一件要注意的就是要記得kernel有enable CONFIG_EFI_PARTITION不然重開機之後該partition會無法mount，我之前就是忘了enable所以 partition建完之後重開機之後就mount不起來害我搞了好久 :(

[回應] Arian @ 13/02/2009, 10:00

請問板主使用的測試 package 為何呢?

小弟也想試試 read write etc. 測試，但不知板主使用的測試軟體為何呢? 請指點小弟 ~ Thanks.

[回應] wesley.tw @ 17/02/2009, 17:16

專業的分析！謝謝您

請問Tetralet大哥：
您的圖表是用什麼工具產生出來的呢？
謝謝～

[回應] Maxsolar @ 19/02/2009, 00:57

Re: wesley.tw

我是用自己寫的 Script 去測的。如果您有興趣，應當試試專業的測試軟體，如：Bonnie++（已包含於 Debian 官方資料庫中）來進行測試，結果應該會比敝人的亂七八糟測試還有公信力吧？

另外，敝人的 Script 會在另一篇的貼文中公開出來。到時請不妨批評指教！

[回應] Tetralet @ 19/02/2009, 11:09

Re: Maxsolar

那些圖表（想當然爾）是用 OO.o 畫的呀！ XD

[回應] Tetralet @ 19/02/2009, 11:11

RE: GPT EFI

可否列一下 C/H/S 的值
hardware RAID card = ?

如果用 sysrescuecd 跑 64bit 是否還能 mount lvm partition?

[回應] dou0228 @ 27/02/2009, 13:00

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

評測的很詳細，我還是繼續用 ext3 比較穩定

[回應] Yoshi @ 18/04/2009, 20:53

Re: Linux 支援的檔案系統小評測 - 最後的選擇是...

我們公司用 reiserfs 比較多
自己有遇到 reiserfs 斷電修復硬碟的經驗！EXT3 還沒遇到過
還有遇過硬體 RAID 異常整個 reiserfs 使整個 SYSTEM 卡死，ext3 則可以正常 work

[回應] trj @ 04/07/2009, 00:35

Accessible and Valid XHTML 1.0 Strict and CSS