FreeBSD 下 NTFS 效能

由於建立了儲存設備二號機, 之前放在 Windows XP 下磁碟陣列的資料也備份到 USB 外接硬碟. 就想將備份資料放到二號機(FreeBSD 9.0R + ZFS). 心想系統已經有內建的 mount_ntfs 就直接拿來用.
mount_ntfs -C Big-5 /dev/da0s1 /mnt
沒想到 rsync 下去, 速度竟然只有 1MB/s.
檢查確認 da0 是掛在 usbus1(on ehci0) 下

...

usbus1: EHCI version 1.0

usbus1:  on ehci0

...

usbus1: 480Mbps High Speed USB v2.0

...

ugen1.1:  at usbus1

uhub1:  on usbus1

...

ugen1.2:  at usbus1

umass0:  on usbus1

umass0:  SCSI over Bulk-Only; quirks = 0x4000

umass0:13:0:-1: Attached to scbus13

da0 at umass-sim0 bus 0 scbus13 target 0 lun 0

da0:  Fixed Direct Access SCSI-2 device

da0: 40.000MB/s transfers

da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C)

看過這篇討論覺得應該嘗試一下 sysutils/fusefs-ntfs.
沒想到效能差這麼多, 同樣使用 rsync 目前速度已經飆到平均 13MB/s , 最大值有看到 22MB/s. 總算可以快速將資料備份. 放在單一硬碟上還真是蠻擔心的.

加入 Project HoneyPot

既然機器三不五時有機器人來嘗試入侵, 就把機器加個小功能 : 升級當蜜罐. 再來看看如何將 sshd ipfw 的資料上傳給類似的計畫. Funny! 感覺好像在 Fallout 中加入 Brother of Steel 鋼鐵兄弟會.

參考資料 (Reference)
1. Project HoneyPot from delphij's Chaos
2. Project HoneyPot 官方網頁

測試 ZFS copies 在單顆磁碟下的復原能力.

感謝 Kuli 學長提供良好的測試方法 - 使用 memory disk 測試. 測試指令如下 :

1. 準備階段
1.1. 建立 zpool test 及測試 vol 1 及 2

# mdconfig -a -t swap -s 66m
# zpool create test /dev/md0
# zfs create -o copies=1 test/1
# zfs create -o copies=2 test/2

1.2. 編輯測試檔案

# vi /test/1/test1.txt

輸入 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

# vi /test/2/test2.txt

輸入 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

1.3. 匯出 zpool test 並製作 memory disk dump file.

# zpool export test
# dd if=/dev/md0 of=/root/md0

2. 複製 dump file 並使用 hexedit 搜尋連續的 A 及 B 編輯檔案.

# cp -a /root/md0 /root/md0-edit
# hexedit md0

2.1. 搜尋有 36 個 A 的區塊將 A 改成 C. 進行 3. 觀察 ZFS 的反應.

2.2. 搜尋有 36 個 B 的區塊將 B 改成 D, 但只修改其中一組. 進行 3. 觀察 ZFS 的反應.

2.3. 搜尋有 36 個 B 的區塊, 其中一組將 B 改成 D, 另一組將 B 改成 E. 進行 3. 觀察 ZFS 的反應.

3. 將檔案寫回 memory disk

# dd if=/root/md0-edit of=/dev/md0 bs=1m
# zpool import -d /dev test
# zfs scrub test

4. 觀察結果:
4.1. 進行 2.1. 後, vol 1 出現無法修復的錯誤, 並拒絕使用該檔案.

4.2. 進行 2.2. 後, vol 2 發現錯誤並直接修正錯誤(不需 zfs scrub test), 且匯入後可正常使用該檔案. 此時將 zpool test 匯出後並製作 dump file. 可以觀察到手動變更的 D 已經被修改回 B.

4.3. 進行 2.3. 後, vol 2 出現無法修復的錯誤, 並拒絕使用該檔案.

5. 不過這是可修正的軟體錯誤, 如果發生硬體錯誤會是如何處理. 目前尚未想到好方法測試. 不過可偵測錯誤並顯示出來或許對系統管理就蠻有用的. 至少可以提早發現更換硬碟.