因為我 git 的各項操作實在是太慢了.
慢到整個系統大概可以和 P5 比吧 (反正就是慢慢慢)

一開始我以為是 raid/disk 的問題, 不過在數次交叉測試下, 看起來兇手指向 File System
以下就是我的測試環境.

CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
OS: Ubuntu Linux 10.04 LTS
HDD1: Device Model: Seagate ST31000528AS (1T)
HDD2: Device Model: Seagate ST31000528AS (1T)
同一顆.

測試方式.

HDD1, HDD2 分別切了 40G 的 Primary 1 Partition.
第一次在 HDD1 測 ext4 , HDD2 測 xfs
第二次在 HDD1 測 xfs , HDD2 測 ext3
第二次測完後追加 ext3 和 btrfs
使用 time command 測試時間.
在 Copy 之前會先 mkfs disk .
硬碟內先行準備好一個 git repository 的測試資料, 然後再另建一個目錄 clone 這份測試資料(不細測 Read/Write)

測試資料.
9.1G 的 .git source tree. 包含 5G 的 .git database 還有 4.1G 的 source code/binary/image .. 等等資料. 約有 2800 個 commit.

以下是測試數據
First Round
sda1: ext4
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 3m30.381s
user 0m24.878s
sys 0m31.402s

sdb1: xfs
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk2/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 13m47.297s
user 0m31.510s
sys 0m24.482s

Round 2:
sda1: xfs
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 13m10.405s
user 0m32.122s
sys 0m19.761s

sdb1: ext4
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk2/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 1m25.192s
user 0m26.210s
sys 0m14.017s

sdb: ext3
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk2/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 3m5.792s
user 0m25.534s
sys 0m23.065s

sda: btrfs
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 1m13.981s
user 0m24.670s
sys 0m32.730s

簡單的做一個圖表做測試結果.

由此圖可知, 我的效能問題是出在 xfs 上.將 raid system 改成 ext4 後, 這個問題就解決了.

但是奇怪的是, xfs 雖然花了 13m, 但是實際 CPU 使用時間並不多. 這個問題也有可能是 ubuntu/Linux kernel 造成的.

ext4 和  btrfs 都各有一次不錯的表現. 尤其是 btrfs, 才 1m13 秒. 大家有常常使用 git 的, 可以考慮一下 btrfs.

受限於個人時間, 這個測試並不嚴謹, 不過己經可以解決我目前的問題, 至於這個數據, 簡單整理一下以後, 可以給常常使用 git 的朋友一個參考的資料.
接下來就是希望有人能夠花點時間做出更完整的數據, 或是順便 Debug 了.

The post git 和 filesystem 的 Performance appeared first on richliu's blog.

我的 Root Disk 是用 Raid1 + XFS 做的, 硬碟的規劃是

md1 : 100M etx3 booting 用
md2: 40G xfs Root File System 用
md3: 4G swap
md4: /home

用 kubuntu 7.04 開機之後, 檢查了一下, 看起來像是 xfs 系統亂掉, 所以就做一次 xfs_repair /dev/md2, 不過要清掉一些 LOG, 所以下的是 xfs_repair -L /dev/md2

第一次重開機是成功的, 但是跑一小時時間會 I/O Error,
所以我又開起來, mount 起來看系統有沒有問題?
檢查的結果是 xfs_repair 之後，所有的程式都沒有問題，看起來就不是 glibc 死掉，感覺像是 xfs 掛了。不過這時候我並沒有證據是 xfs 死掉造成的.

就這樣重覆修修開開, 終於有一次注意到, 開機時死掉的訊息有一段是

“XFS internal error XFS_WANT_CORRUPTED_RETURN”

查了一下, 網路上的資料不多(還能被我碰上實在不簡單), 有人說是減少檔案數目就可以, 其他的網頁到是沒有講到解決方案.

我做過減少數量, xfs_check and xfs_repair, 重新 format filesystem 都無效.

最後失望之餘, 改用 ext3, 發現還是 mount 不起來, 這就讓我懷疑了, 到底是那一塊出問題?

後來在檢查 mdadm -D /dev/md2 時, 發現 persistence : no block persistent.
再檢查 mdadm -D /dev/sda2, /dev/sdb2 , 都找不到 raid block, 但是 mdadm -D /dev/md1 雖然是 persistence: no block persistent, 但是 Disk 部份是找得到 Raid 的 Super Block .
這應該就是原因了, 檢查了一下, 重新 create 一次 raid1 device 就沒有問題了.

個人猜想原因可能是 xfs 系統大亂, 影響到 /dev/md1 /dev/md2 /dev/md3 等等 file system,  但是從 raid 的 super block 也被破壞等跡像來看, 可能是 Linux 內 xfs 和 Raid 配合有問題所致. 不過個人急著上線, 所以無法驗証.

我用 xfs + Linux raid 有數年的經驗, 沒有一次像這樣災情這麼嚴重, 前前後後花了將近 8 小時去找出問題並修復, 還好資料並沒有毀損, 不過經歷這次經驗, 以後會對 xfs 有戒心了.

以下是相關修復指令, 備用.

強迫安裝

# lftp ftp.twaren.net
>cd ubuntu/pool/main/m/madm
>get mdadm_2.6.3-xxxxx.deb
# dpkg -i –force-all madm_2.6.3-xxxxxxx.deb

重建 Raid

# mdadm –build /dev/md2 –level=2 –raid-devices=2 /dev/sd[ab]2

重新 Create Raid

# mdadm –create /dev/md2 –level=2 –raid-devices=2 /dev/sd[ab]2

The post XFS 碰到 “XFS internal error XFS_WANT_CORRUPTED_RETURN” appeared first on richliu's blog.