2009年12月9日

VIA EPIA EN のその後

VIA EPIA EN12000 を24時間運転してサーバ運用してる。 以前は、時々ハングアップしていたのため、保険で watchdog 設定をしていたのだが、 奇妙なことに安定動作している。

# uptime 
 16:32:08 up 48 days, 21:24,  1 user,  load average: 0.06, 0.07, 0.01

取り敢えず、1ヶ月半くらい連続運転している。

はて?
なにが効果あったのかな?

環境としては、

  • VIA-EN12000EG / VIA C7 1.2GHz
  • DDR2-533 1G (IO-DATA DX533-1G)
  • PATA SSD 32G (TS32GSSD25-M)
  • SATA HDD 1Tx2 (WDC WD10EADS-00L/WDC WD10EADS-00M)
  • Debian lenny の標準的なパッケージをほぼ使ってる。
TimeMachine の バックアップ先になっており、一時間ぐらいの間隔で バースト的に Network I/O や Disk I/O が同時に発生する状況にある。

取り敢えずは、今のところ安定している。。。

まぁ、ネットワーク負荷を計測するときには、 負荷をかけるとハングアップすることが多々あった。 追っかけてみようかと思って保留して、 計測後の環境ではハングアップが全く無くなったので放置してしまった。

計測前と計測後には大きく2点の作業をしてある。

メモリのフリーページの調節

運良くコンソールにメッセージが出てきたとき「lockup」とかは見た記憶がある。 別のメッセージだったかもしれない。 色々調べて、「メモリーのフリーページの不足ぎみが NICドライバ内でのlockupを引き起こす」とか適当に結論づけて、 次の設定をした気がする

# echo "vm.min_free_kbytes = 8192" >> /etc/sysctl.conf

ただ、もっと良い設定があって次のようなスクリプトを自前のバックアップ処理の後に入れている

## pagecache clear & dirty page & inode cache clear
/sbin/sysctl -w vm.drop_caches=3
#
/sbin/sysctl -w vm.drop_caches=0

この設定は、結構気分の問題な気がする。

NIC ドライバの変更

計測中も、ベンダ提供のものか、自前で修正したものを使っている。 計測後は、自前で修正したものを使って長期運用している。。。ってその為に改良したしなぁ。

Debian 標準カーネルに含まれているvia-velocityドライバはバースト的なI/Oにはlockupするような、気がする。

まとめ

人生で初めて家の電灯の安定器のコンデンサが破裂していく音を聞いた。

「しゅるしゅるしゅる〜〜、ぷぅん」って。

VIA-EN12000EG のコンデンサが減ったった時が、VIA とのお別れですね


[全文を読む]

2009年10月21日

Blogger の「続きを読む」機能

ここ2〜3ヶ月くらいで、Blogger にクラウドタグと「続きを読む」機能が追加された。

すばらしい!

あとは、関連記事のリスト表示の対応が入れば、全部 Blogger 内でまかなえるのかなぁ。。。

ただし、ちょっとだけ問題がでた。

今使っている投稿アプリ ecto では 投稿後に再度 Blogger からデータを再取得してその内容を保存するような動作をしている。

このとき、Blogger から流れてくるデータでは 「<!-- more -->」が「<a name='more'></a>」に置換されてしまっている。

そのままで jump break と同等に機能すれば良いのだが、どうもそうでは無いらしい。

再度修正したいときは、都度確認し修正が必要のようである。

ecto の使い方がわるいんかなぁ。。。


[全文を読む]

2009年10月19日

VIA EPIA EN の設定のまとめ 2009Q4

気がついてみると VIA EPIA EN12000 と Linux の Tips がたまったので、まとめてみた。

PadLock

  1. Debian で VIA の PadLock を使ってみる
  2. IPSec のスループット
  3. Linux でボリュームを暗号化する (1) - swapの保護
  4. Linux でボリュームを暗号化する (2) - LVMの保護
  5. Linux でボリュームを暗号化する (3) - 性能比較

Watch Dog Timer

  1. VIA EPIA-EN で watchdog を設定

Onboard NIC / VT6122

  1. VT6122 の性能(1) - Linux のドライバの準備
  2. VT6122 の性能(2) - VIA Velocity の出自
  3. VT6122 の性能(3) - ネットワークスループット測定
  4. VT6122 の性能(4) - ドライバの強化
VIA EPIA EN のその後 (追記2009/12/09)

性能を使い切るポイントはある程度掴めたので、再度ファイルサーバとして組み直して使う事にした。 高負荷状態になってもたいして速くない電力を食わないので好都合かなぁ。 なので、これ以上このボードに特化したTipsはおしまい。

あれ、、、なぜかGbE-PCI2GbE-PCIe3が手元にあるのは何故なんだろう。。。


[全文を読む]

2009年10月15日

IPSec のスループット

ネットワークのスループットを測定する環境を整えたので、次いでに IPSec を通してた時のものも測定してみた。

測定の条件は

  1. スループット測定ツール nuttcp の計測用データチャンネル 5001/tcp を上り/下りにそれぞれ IPSec に通す。
  2. racoon ver.1 でサポートされていない暗号化スイートも測定したいので、鍵を手動で設定する。
  3. ESP認証/暗号の組み合わせで計測する。(AHは使わん)
  4. 追加で IPComp での圧縮の効果を見たい気がする。
複数の認証/暗号の組み合わせで測定する為にスクリプト(measure_ipsec_throughput.sh)化した。

setkey で、手動で鍵を設定する方法は多々情報(12)があるので、そちらを参考にして欲しい。ただ、IPComp を組み合わせる例が乏しいのでこの部分だけ。

IPComp を組み合わせて使う

IPSec設定済みで、ESPのみを使うSPDが次にようになってるだろう。

...
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp -P out ipsec esp/transport//require;
...

このときSPDのルールの順番が重要になる。カプセル化の下の方から、要は IPComp ⇒ ESP ⇒ AH の順に書き下していくことになる。

従ってIPCompを組み合わせるには、次のようにすればよい。

...
add xx.xx.xx.xx[port] yy.yy.yy.yy ipcomp zzzz -C deflate;
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp
	-P out ipsec ipcomp/transport//use esp/transport//require;

ただ、ベンチマークに流れるデータは「0」の羅列なので、いまいち効果が分からん。。。

なので計測は諦めた。

IPSec スループットの計測

前とほぼ同じ環境とmacbook pro を加えたものを用意、全ての計測に MTU 1500 / ロック周波数変更は全て無効にしMAXにした。また、TCP/IP通信に関するパラメータを修正せずにデフォルトにした。

  • ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
  • ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
  • via - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
  • osx - MacBookPro5,1 / Intel Core 2 Duo 2.4 GHz / DDR3-1066 2G x 2 / onboard Gigabit Ethernet
  • hub - Gigabit Hub(GS908M)
認証/暗号 ref1⇔ref2 ref1⇔via ref1⇔osx
throughput
(Mbps)
CPU % throughput
(Mbps)
CPU % throughput
(Mbps)
CPU %
ref1ref2 ref1via ref1osx
no ipsec 941.35801028 785.1857650 936.9429954
941.24611724 723.71001299 938.34511877
null/null 934.68349938 566.89471393 932.07073162
787.44951846 520.28801399 879.31272599
null/des-cbc 229.5461998 72.9094295 136.6533314
197.07681426 73.4657499 129.1215699
null/3des-cbc 110.51731004 30.8918287 59.206417
76.8033111 30.5976199 56.5818398
null/aes-cbc 466.79899933 392.07391491 475.77899543
472.17962836 396.22641799 376.38902299
null/aes-ctr 495.41637758 218.6071771
383.9987167 258.74301799
null/blowfish-cbc 316.03279911 77.6054374 263.77951531
244.9774114 84.1580499 228.48101399
null/twofish-cbc 372.53179919 100.8360573
289.2720159 102.0088599
null/camellia-cbc 340.991610015 86.7841360
267.3560185 84.5675499
hmac-md5/null 537.28579924 244.7170787 578.86759949
453.24482914 230.20191199 572.58092999
hmac-sha1/null 370.086110015 360.37542086 414.47069941
296.1913117 350.02872099 469.55875798
hmac-sha256/null 307.00789916 302.931510041 278.90011733
240.0495124 336.25121996 248.91492899
aes-xcbc-mac/null 447.60179920 216.0013680
347.98811312 271.08012199
hmac-md5/3des-cbc 101.51721005 29.0609188 57.006917
71.0862111 28.45191100 54.5636498
hmac-md5/aes-cbc 326.01559917 205.8441979 349.03388027
266.2639185 198.65111299 296.44312798
hmac-sha1/3des-cbc 94.18991005 30.1900185 56.661915
66.1646121 29.8474299 52.0154496
hmac-sha1/aes-cbc 259.36149915 253.11579956 275.36619825
202.5055124 286.00772093 270.10912697
hmac-sha1/aes-ctr 257.31529914 193.6954497
199.9059123 209.87451699
aes-xcbc-mac/aes-cbc 283.08649915 207.26131162
225.1556134 233.39072699
aes-xcbc-mac/aes-ctr 281.39699915 154.4989770
220.3145124 178.53991399

異様にたくさん計測したが、あんまり意味が無い気がしないでもない。

  • 暗号化方式の性能は
    aes系 > blowfish/twofish/camellia >> DES > 3DES
    VIA C7 では aes系 >> それ以外
  • 認証方式の性能は
    hmac-md5 > aes-xcbc-mac > hmac-sha1/hmac-sha256
    ただ、あまり差異はない。
    VIA C7 では hmac-sha1/hmac-sha256 >> それ以外
  • des-cbc/3des-cbc は他の暗号化方法に比べて5~10倍くらい遅い。もう、見る影が無い。
  • aes 系の実装には多くの開発リソースが割かれており、x86 コードでも十分早い。VIA PadLock が圧倒的に有利という訳ではない、不利という訳でもない。
  • 個々のNICドライバの個性がある。
    e1000e(Linux) / nvenet(MacOSX) に関しては送信時のCPU負荷が100%になる傾向があり、r8169 に関してはどう考えてもCPU利用率が低くなる。
    これが NIC 自体の性能か、TCPと組み合わせで何らかのビジーウェイトが起きるのかは、いまいち不明。。。nuttcp/netperf で発生するトラフィックパータンに対する適性なのだろうか。
    送信性能が上がるチューニングが必要なのだろうか?
  • 普通運用する hmac-sha1/aes-cbc は 約250Mbps のスループットが出る。PadLock を使えば同様の性能が出る。

結論

VIA-EN12000EG 上の Linux で IPSec を使うと約250Mbps程度のスループットの性能があり、Athlon64X2 2.0GHz と同程度の性能である。

Intel Atom はどの程度なのだろうかぁ?


[全文を読む]

2009年10月6日

VT6122 の性能(4) - ドライバの強化

元々 via-velocity は、少し古いバージョンの velocityget ソースを整理したものだった。ただ、現在の双方のバージョンを比べると、via-velocity に含まれていない要素がある。

  • EnableMRDPL (Memory-Read-Multiple)オプション
  • VIA 的には「Adaptive Interrupt」と呼ばれるもの
    (txque_timer/rxque_timer/tx_intsup/rx_intsupオプションとその関連部分)

これは、分岐後にVIAによって追加されたものか、意図的に省かれたのもか、どちらなのかは正直分からない。

EnableMRDPL (Memory-Read-Multiple)オプション

最初の要素は、PCIのバースト転送のモードをなんか指定するものらしいが、ベンチマーク上は効果がなかった。 PCIに詳しくなければいまいち内容が分からないし、デフォルトが無効なので、今回は見送った。

VIA 的には「Adaptive Interrupt」と呼ばれるもの

「適応割り込み」と称しているが、単に割り込みを一定数間引いたり、一定時間遅延を入れるだけのようで、 特に割り込みの頻度に応じて動的に変更はしない。。。なんかなぁ

うんで、機能追加パッチを作ってみた。(velocitygetの処理を流用)

  1. via-velocity の adaptive interrupt 関連の機能追加パッチ (debian lenny/kernel-2.6.26用) / via-velocity-adaptive-intr.patch

前出の修正パッチの後に当てればいい

# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# patch -p 3 -d via-velocity < via-velocity-adaptive-intr.patch
# cd via-velocity
# make install

スループット性能の比較

前回と同じ環境で、velocityget と via-velocityの「Adaptive Interrupt」パッチ有/無の3種類の場合を測定した。

velocitygetvia-velocity
パッチ無し
via-velocity
パッチあり
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1targetref1
target ⇒ ref1 655.484199 %11 % 646.403699 %12 % 724.780999 %12 %
target ⇐ ref1 741.275566 %4 % 709.246580 %2 % 762.342051 %5 %
mtu 1500 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

velocitygetvia-velocity
パッチ無し
via-velocity
パッチあり
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1targetref1
target ⇒ ref1 816.054432 %7 % 816.154130 %7 % 814.900731 %7 %
target ⇐ ref1 989.874548 %9 % 944.481346 %8 % 989.832346 %9 %
mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

考察

mtu 1500 のとき、送信性能が10%程度上がった。受信性能はほぼ velocityget と同程度になったが、CPU負荷率は低くなった。mtu 9000 のときは、velocityget と同程度になった。

受信時のCPU負荷率低下は面白い。NAPI化すればより軽くなるのかなぁ。e100?系の適応なんとかの動的アルゴリズムを流用すればもっと良くなるのかなぁ。もっと送信性能を上げるにはどうすれば良いのだろう。。。

スループットのベンチマーク上の結果だけなので、レイテンシとかはどうなんだろう。。。

本来 ethtool へのインタフェース経由で設定するものを、モジュールパラメータに載せて、固定値になっているのも気になると言えば気になる。

ちまちまパッチを切るのは面倒だから、どっかにレポジトリ借りて、最新版のバニラソースに作業するのがいいのかなぁ。

ふぅむ。

近年、VIA の NIC のシェアはかなり落ちている。大抵の onboard NIC は RealTek の奴だったりする。また、Windows 64bit系の4G問題とかも敬遠される原因になっている。

廃れつつ、傾きつつ、そんなものの為に作業する奴がいないんだろうなぁ。

VIA EPIA は本当に不憫な奴だ。




今年分の作業は、この辺かなぁ、、、では


[全文を読む]

2009年9月30日

VT6122 の性能(3) - ネットワークスループット測定

スループットを計測するツールは何種類かある。

  • ttcp / nttcp / nuttcp
    ttcp が古のツールでソースは色んなバージョン(1,2)が散見される、SGI の人が改良したのが nttcp (元サイトは http://www.leo.org/~elmar/nttcp/ だったらしいが、既に無くなっている)。nuttcp は、nttcp をベースに改良が続けられたもの。使うならば nuttcp かなぁ。
  • iperf
    Java ベースの GUI 付きがあるので、ベンリかも
  • netperf
    スループット以外にもテスト項目の種類が豊富。ただし、man ページが不完全でなので付属の HTML/PDF を参照する必要がある。
  • SmartBits
    商用でよく使われている奴ですね。

まぁ、スループットの測定ならば iperf を使えば良いが、CPU の負荷状況を見たいので nuttcp を使ってみた。

VIA-EN を含めて以下の3台とHUBを用意し、3台ともhubに直結した。

  • target - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
  • ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
  • ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
  • hub - Gigabit Hub(GS908M)
また、測定自体は、clock skew を避けるため全て ref1 上で計測した。cpufreq によるクロック周波数変更は全て無効にしMAXにした。 ref2 に関しては ref1 自体の評価にのみ使った。

ref1 ⇔ ref2 間

ref1 / ref2 ともに mtu 1500 に設定して測定した。

# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -t ref2
 1123.8690 MB /  10.01 sec =  941.3733 Mbps 11 %TX 27 %RX
# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -r ref2
 1122.3750 MB /  10.00 sec =  941.0966 Mbps 33 %TX 16 %RX
これを表にすると、
スループット
(Mbps)
CPU 利用率
ref1ref2
ref1 ⇒ ref2941.373311 %27 %
ref1 ⇐ ref2941.096616 %33 %
mtu 1500

まぁ、順当に ref1 は送受信ともに約 940Mbps 程度の性能を持っている事が分かる。

target ⇔ ref1 間

target の ドライバ via-velocity/velocityget のそれぞれに対して、mtu 1500 かつモジュールパラメータを設定せずに(ドライバのデフォルト値で)計測した。

velocitygetvia-velocity
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 655.217499 %12 % 340.168127 %9 %
target ⇐ ref1 738.798768 %3 % 514.590042 %2 %
mtu 1500 / モジュールパラメータは全てデフォルト値

熟考

結果を見れば、明らかに velocityget の方が性能が高いように思われるが、ソースを見比べるとモジュールパラメータ DMA_length のデフォルト値が、それぞれのドライバで異なる (velocitygetは6/via-velocityは0)。

DMA_length は、チップ内のバッファとメインメモリの間を転送する DMA の処理サイズを指定するらしく、大きなサイズであれば PCI バスの使用効率が上がるので、スループットに影響しそうである。

なので、DMA_length を 0〜7 に振って再度計測し直してみた。

DMA_lengthvelocitygetvia-velocity
(via-velocity
/velocityget)
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 0 369.505328 %11 % 340.182727 %10 % 0.920643
1 398.938239 %11 % 414.574740 %7 % 1.039195
2 497.400464 %9 % 494.275760 %8 % 0.993717
3 539.035684 %9 % 540.716080 %10 % 1.003117
4 610.574399 %10 % 608.103199 %10 % 0.995952
5 646.153099 %11 % 640.971199 %10 % 0.991980
6 655.484199 %11 % 646.403699 %12 % 0.986146
7 652.173299 %12 % 647.739799 %10 % 0.993201
target ⇐ ref1 0 450.885036 %2 % 502.953242 %2 % 1.115480
1 490.215038 %2 % 580.651856 %2 % 1.184483
2 599.558448 %3 % 642.568463 %2 % 1.071736
3 661.059252 %3 % 685.175374 %3 % 1.036480
4 719.696564 %3 % 709.948283 %3 % 0.986454
5 731.320969 %5 % 710.111380 %3 % 0.970998
6 741.275566 %4 % 709.246580 %3 % 0.956792
7 738.297565 %3 % 710.145982 %3 % 0.961869
mtu 1500 / モジュールパラメータはDMA_length以外はデフォルト値

DMA_length の値を合わせれば、送受信のスループットに関しては velocityget/via-velocity にほとんと差異は無く、強いて言えば velocityget の方が受信に関して 4〜5% 高く、処理が軽い。送信に関しては双方同じ程度に CPU を使い切って頭打ちになっている。VIA C7 では 1Gbps は吐けないのかぁ。。。

まぁ、DMA_length は velocityget のデフォルト値の 6 が推奨値かなぁ。ちなみに、NetBSDでのドライバ vge だと 4 だった。

ただ、DMA_lengthの値でスループットの差異が出るのは VT6122などのPCIベースの場合だけで、PCIe ベースの VT6130 ではどの値でも違いが無かった。。。多分省かれてしまったのでしょう。

さて、velocityget にだけあるっぽい機能を移植していけば、差異が無くなっていくのかなぁ?

MTU 9000 での測定

そういえば、mtu 9000 のスループットも測定をしたかったで Intel Pro/1000PT を外付けしたんだっけなぁ。なので、測定してみた。

velocitygetvia-velocity
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 816.054432 %7 % 816.154130 %7 %
target ⇐ ref1 989.874548 %9 % 944.481346 %8 %
mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

受信に関しては、ほぼ 1Gbps を使い切っている!凄し!

追記 (2009/10/06)

今回使ったスループット測定用のスクリプトmeasure_net_throughput.shをバックアップとして上げておく。


[全文を読む]

2009年9月27日

VT6122 の性能(2) - VIA Velocity の出自

velocitygetのソースを眺めていると VT3119 とか VT3216とか一見全く関係無さそうなチップ名らしき物が出てくる。 VT6122 の Device ID が 0x3119 なのでVIA内部型番になっているのかなぁ。 でも、ドライバ内では Rev ID での区別らしきものがあり、それに従うと VT6122 = VT3216 (?)っぽい。

正直のところ VIA に聞かないと分からないし、検索でもホンの僅かの情報しか引っ掛からないので、 憶測程度にしかならないが、ちょっとだけ書き残しておこう。

VT6110

ここら辺の事情は、ほんとに雲をつかむような感じだ。。。

ZyXEL社の Gigabit NIC (GN650-T/GN670-T) が最初の製品っぽい。そいつが VIA 内部では Device ID と関連づけて、多分 VT3119 と呼ばれていたんだろう。コイツにはまだ PHY が内蔵されておらず、ZyXEL の製品には PHY が載っている。それが CICADA製SimpliPHY のもの。

ZyXEL へのOEM供給?でチップの型番はZX1701Z/X1702になっているが、VIA が外販する時に VT6110 と付けたんだろうと推測できる。

参照
  1. BSD系のドライバ vgeには、ZyXEL 製のNICとVT3119 の記述がある。
  2. ZyXELのサイトには情報は殆どないが、Download Search で検索するととドライバ(rhineget 1.10/velocityget 1.18)が見つかる。
  3. ロシアでは結構流通した製品らしく、検索("Zyxel Omni LAN PCI G1")に出てくる。カード全体の鮮明な画像も出てくる。SimpliPHYのマークのチップが見てとれる。
  4. rhineget/velocityget 内の chip_info_table には、CHIP_TYPE_VT6110 のマクロがある。
  5. Gentooのフォーラムの記事に、GN650-T の lspciの出力があり、Rev 01 となっており、ソース内では REV_ID_VT3119_A1 に相当する。REV_ID_VT3119_A0 というのは開発版なのかなぁ。。。

VT6120/VT6121/VT6122

VT6110 に SimpliPHYを内蔵して1チップ化したものが、良く知っている VIA Velocity と呼ばれてる製品群で、 PCIのバスサイズが32bit/64bitのものがそれぞれがVT6120/VT6121で、VT6120 のパッケージを小型したのが VT6122 である。

内部的には VT3216 の型番が付いてると思われるが、ドライバが流用できるほど上位互換なので、Device ID が 0x3119 のままになったようである。

以後、Rev ID の範囲で区別する方針になったのか、0x00〜0x0F が ZX1701Z/X1702/VT6110 であり、0x10 〜 0x1F が VT6120/VT6121/VT6122 のどれかにあたる。ちなみに EPIA-EN12000EG に載っているのは 0x11 になっている。

性能アップのための機能で Tx/RX キューに関するなんかのタイマーが追加されている。

Rev ID が 0x20〜0x7fのもの

該当する製品が見つけられなかった。。。内部的には VT3284 の型番が付いていると思われる。

velocityget を読む限り、PCI のバースト転送に Memory-Read-Multiple が使えるようになったっぽい。なんのコッチャ、、、

Rev ID が 0x80 〜

PCIe に対応した VT6130/VT6132 が該当する。内部的には、VT3286 の型番が付いてると思われる。

どうも PCIe 化と同時に省かれた機能があるっぽいが、ドライバでは何も対処してないっぽい気がする。

まとめ

Device ID 0x3119 のデバイスは、Rev ID の範囲でチップを区別してるらしい(もしかしたら、特定の Rev ID リストが作れるかも)。

Rev ID内部型番チップ名
0x00 ~ 0x0fVT3119ZX1701Z/X1702/VT6110
0x10 ~ 0x1fVT3216VT6120/VT6121/VT6122
0x20 ~ 0x7fVT3284不明
0x80 ~ VT3286VT6130/VT6132

但し書き

元になるデータが凄く不確かであり、かなりの憶測が含んでいる(ほとんどが要出典)。あまり信用できる情報ではありませんのであしからず。


[全文を読む]

2009年9月24日

Linux の iSCSI

Linux で iSCSI を、やるならば先ず「iSCSI Enterprise Target (IET)」である。そして、kernel に取り込まれてる iSCSI システムが別にあるよってなる。

それって何だろう?

Linux SCSI target framework (STGT)」がそれらしい。iSCSIに限らず Fiber Channel などの一般的な SCSI Target を対象に絶賛開発中らしい。ユーザランドのコマンドは RHEL5系でscsi-target-utils として提供されいるので、結構安定してるかも。ただ、Debian にはまだ無いっぽい。

あと、別系統として、「generic SCSI target subsystem for Linux (SCST)」てのがある。

三種類の比較表を見ると、SCST が多機能で高性能っぽい。今後が楽しみだなぁ


[全文を読む]

VT6122 の性能(1) - Linux のドライバの準備

VIA EPIA は不憫な奴だ。

去年から消費電力が低い Intel Atom ボードが出荷され、当初性能がわずかに上かなぁ〜と思われた後で、Dual-Core だとか Hyper-Threading とかが追加され、もう比べるのも可哀想なぐらい、次いでに Mini-ITX のボードの市場も荒らされまくり、踏んだり蹴ったりのボコボコにされてますなぁ、、、なんか違うかも。

何の気の迷いか EPIA-EN12000EG を買ってしまって以来、 不憫な奴が故に捨てられずに、年に1回くらいは思い出したように手を入れて使っている。。。はぁ〜

今回は NIC の性能について愚痴ってみよう。

EPIA-EN12000EG には VT6122 (Gigabit Ethernet) が搭載されている。Datasheet(pdf) を見る限り、South Bridge / VT8237R+ の下のPCIバス(32bit/33MHz)にぶら下がっている。PCIバス(32bit/33MHz) の上限 133MByte/s がボトルネックになるので期待は出来ない。PCIe 接続の VT6130/VT6132 でないなければ Gigabit の限界には迫れないが、どれくらい迫れるかが興味の有るところ。

二種類のドライバ

VT6122のLinux ドライバは二種類で、どっちも些細なバグが有る。

  1. via-velocity / kernel 本家に取り込まれているもの。性能が低いのがもっぱらの噂。WOL が動かない。
  2. velocityget / VIA 本家作成のドライバ。VIA AREA で公開されているが、ダウンロードページに辿り着くまでが迷路というか、ほんとに無理。現在(2009/09/23)の時点で、1.36 が安定版らしい。 rmmod/insmod を繰り返すと dmesg に 不審な oops を残す不具合あり。
で、修正パッチを作ってみた。
  1. via-velocity の WOL 対応パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-wol.patch
  2. velocityget の procエントリのリークフィックパッチ / velocityget-fixed-proc.patch

via-velocity単体で再構築

via-velocity 単体だけでも再構築できるようにしてみよう。ターゲットは、Debian lenny の 2.6.26-2-686 向けだが、他のディストロでも応用可能かなぁ。

# apt-get install linux-headers-2.6.26-2-686
# apt-get install linux-source-2.6.26

構築用ソースのかき集め

  1. 適当にでっち上げた Makefile / Makefile-via-velocity-only
  2. linux-source-2.6.26 パッケージからvia-velocity.[hc]
# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
あとは再構築してモジュールをインストール。
# cd via-velocity
# make install
make -C /lib/modules/2.6.26-2-686/build SUBDIRS=/usr/src/via-velocity modules
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' に入ります
  CC [M]  /usr/src/via-velocity/via-velocity.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/via-velocity/via-velocity.mod.o
  LD [M]  /usr/src/via-velocity/via-velocity.ko
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' から出ます
mkdir -p /lib/modules/2.6.26-2-686/kernel/drivers/net
*****  Move current driver via-velocity.ko to via-velocity.ko.2009-09-24-1253781710 file
mv /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko.2009-09-24-1253781710

install -m 644 -o root via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net
/sbin/depmod -a || true
最後に rmmod/modprobe してモジュールを更新して完了。

これで機能的には同程度になったので、性能比較でもしますかぁ。

追記 (2009/09/26)

どうも via-velocity には、ネットワーク負荷が高いときにシステムが黙りをする症状(1,2 等々)?が報告されている。velocityget を使えば症状が出ないので、velocitygetを使うべしとなってるらしい。。。

ソースを見比べると、割り込みハンドラ内の処理が問題のようだ。それぞれは、大まかに次のようになっている。

  • via-velocity
    1. 未処理の割り込み要因がなくなるまでループする
    2. ループの一単位は、受信/送信ディスクリプタをそれぞれ最大15ディスクリプタ分を処理する
    3. 処理したディスクリプタ数が int_works を超えたらメッセージを出力する
  • velocityget
    1. 受信/送信ディスクリプタをそれぞれ最大int_worksディスクリプタ分を処理する
    2. 上記の処理を2回繰り返す

要するに via-velocity では int_works の取り扱いが杜撰で、かつネットワーク負荷が高いと割り込みハンドラ内に捕われてしまう。なので、割り込みを共有してるデバイスの処理が滞る症状が現れる。

他のネットワークチップのドライバーを見る限り、割り込みハンドラ内で全部のディスクリプタを処理せずに抜ける実装は多々有るので、バグなんだろうなぁ。

うんで、修正パッチを作ってみた

  1. via-velocity の int_works 関連の修正パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-int_works.patch

上のWOL対応パッチの後に当てればいい

# tar xfz via-velocity-buildpack-nosrc.tgz
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# cd via-velocity
# make install

これで、本当に不具合が無い状態?になったので、性能比較でもしますかぁ。

追記 (2009/09/29)

どうも via-velocity-fixed-int_works.patch の velocity_tx_srv の修正部分がバグってたみたいだ。なので、修正版に差し替えました。申し訳ない。


[全文を読む]

2009年9月10日

Time Machine を iSCSI 経由で使う (3) - 性能比較

ボリュームをiSCSIの載せたときの性能と、IPSecで保護した場合やWiFi経由にした場合の性能劣化を測定してみた。

設定条件

接続の経路に結構余分な機器が挟まっているが、 測定用に別環境は用意していないためである。 実環境ベースと考えて勘弁してもらいたい。

Linux ターゲット側
  • ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
  • onboard Gigabit Ethernet (nVidia MCP51)を利用。
Mac OSX のイニシエータ側
  • MacBookPro5,1 / Intel Core 2 Duo / 2.4 GHz / DDR3-1066 2G x 2
  • onboard Gigabit Ethernet / AirMac(WiFi) を利用。
  • Wifi経由では 802.11n/WPA2でアクセスポイントに接続
接続形態
  • ローカルHDD
    MacBookPro
    ⇔ ExpressCard(GH-EXC-ESA2/eSATA接続) ⇔ HDDケース(LHR-DS02SAU2BU) ⇔ HDD
  • 有線ネットワークでは
    MacBookPro
    ⇔ Gigabit Hub(LSW-GT-8NSR)
    ⇔ Gigabit Hub(GS908M) ⇔ Gigabit Hub(GS908M)
    ⇔ Linux マシン(SATA接続) ⇔ HDD
  • Wifi経由では
    MacBookPro
    ⇔ AirMac Extreme (2007モデル?有線100Baseの奴)
    ⇔ Gigabit Hub(GS908M) ⇔ Gigabit Hub(GS908M)
    ⇔ Linux マシン(SATA接続) ⇔ HDD
測定したHDD
  • SATA 320G HDD(ST3320620AS)
  • 3.0Gbps が有効になる用にジャンパー設定
  • iSCSI/ローカル接続でも同じモデルを利用

測定結果

ローカルHDDGigaEtherWifi経由GigaEtherWifi経由
IPSec 無IPSec 有
SequentialUncached Write [4K blocks]58.1960.515.3413.155.48
Uncached Write [256K blocks]47.5850.827.3312.654.72
Uncached Read [4K blocks]16.166.021.464.751.38
Uncached Read [256K blocks]75.5528.863.3915.864.90
RandomUncached Write [4K blocks]1.251.361.321.351.26
Uncached Write [256K blocks]26.1924.376.1913.106.93
Uncached Read [4K blocks]0.640.610.450.580.43
Uncached Read [256K blocks]26.6823.663.2111.174.63
測定単位は全て MByte/sec

ゴタク

iSCSI を有線/noIPSec で通す場合、シーケンシャル読込み以外はほとんど劣化が無い。 シーケンシャル読込みはキャッシュがほとんど効かない為か、iSCSIターゲット実装の良し悪しが出ていると思う。 また、チューニングを実施せずにデフォルト設定にしているので、それも影響しているのかも。

IPSec で保護すると、約120Mbps (15Mbyte/sec) 程度で頭打ちになっている。IPSec の実効帯域と思われる。Gigabit Ethernet なのに帯域が一割程度とはちょっと情けない。IPSec 固有の問題か、Linux の実装の問題か、iSCSI との組み合わせか、判然としない。何処に文句を言っていいのか分からない。

iSCSI を無線にした場合は、大きな問題は経路の帯域である。iSCSIとか、IPSec の有無とかは、もはや問題ではない。周囲の電波状況によって影響を受けるが、WPA2で50Mbpsくらいは流れるので良いのかなぁ。

結論

iSCSIをIPSecで保護することは、 無線を使って Time Machine でバックアップすることには殆ど影響しないと言えそうだ。 また、差分は一時間に一度であり、有線であっても約 120Mbps 程度の帯域を確保できることを考えると、 目くじらを立てるものではないのかなぁ。


[全文を読む]

2009年9月8日

Time Machine を iSCSI 経由で使う (2) - IPSecで保護

iSCSI はブロックデータが Network 上に流れるので気を付けなくはいけない。 専用のネットワークかVLANとかを組むのが定石らしいが、そうでない場合 IPSec が使うのが望ましいらしい。

設定が面倒で、大抵ノーガードですなぁ。

MacOSX でも普通にIPSecが使えるので、iSCSI のデータのみを保護する設定をしてみよう。

IPSec の設定内容

  1. Linux と Mac OSX の相互にIPSec接続をする。
  2. 既に iSCSI の設定が済んでおり、Linux側のiSCSIターゲットボリュームをMacOSX側のiSCSIイニシエータからマウントできる。
  3. IPSec はトランスポートモードで使い、iSCSI のデータ(3260/tcp)に限定する。
  4. IKE デーモンは racoon (IKEv1) を使う。
  5. 認証は事前共有秘密鍵/aggressive mode を使う。
  6. 暗号はAES/SHA1をなるべく使う。
役割IPアドレスホスト名
Linux 側iSCSIターゲット192.168.0.10/24 (固定)server1
MacOSX 側iSCSIイニシエータ192.168.0.20/24client1

SADの設定

基本的に、上りと下りのそれぞれで、サーバ側のIPアドレスとポート番号を指定すれば、iSCSI通信のみに限定できる。クライアント側は、DHCP等で振れる事を考えて範囲指定にする。

BSDの実装では PF tag なるものがあり「spdadd tagged」と組み合わせてフィルタルールに溶け込ませる事ができるそうなのだが、Linux側では同等の機能が実装されていないようなので残念ですなぁ。。。

Linux ターゲット側
# apt-get install ipsec-tools

/etc/ipsec-tools.conf

...
flush;
spdflush;

spdadd 192.168.0.10[3260] 192.168.0.0/24 tcp -P out ipsec esp/transport//require;
spdadd 192.168.0.0/24 192.168.0.10[3260] tcp -P in ipsec esp/transport//require;

Mac OSX のイニシエータ側

MacOSXでは、setkey 用の設定ファルの置き場がデフォルトでは用意されていないので、適当な場所に保存して、起動時に setkey コマンドで読み込み必要がある。

/etc/racoon/setkey.conf

flush;
spdflush;

spdadd 192.168.0.0/24 192.168.0.10[3260] tcp -P out ipsec esp/transport//require;
spdadd 192.168.0.10[3260] 192.168.0.0/24 tcp -P in  ipsec esp/transport//require;

racoonの設定

Linux/MacOSX ともに、racoon を使うので設定ファイル racoon.conf の内容はほぼ同じになる。ただし、事前共有秘密鍵ファイル psk.txt は、同じ鍵をそれぞれの相手側のものとして書く必要があり、ちょっと注意が必要。

Linux ターゲット側

/etc/racoon/racoon.conf

...
remote anonymous {
	exchange_mode aggressive,main;
	my_identifier fqdn "server1";	# サーバの認識情報
	dpd_delay 20;

	proposal {
		encryption_algorithm 3des;
		lifetime time 2 hour;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
	}
	generate_policy off;
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	encryption_algorithm aes, 3des;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}
/etc/racoon/psk.txt
...
client1	secret1

Mac OSX のイニシエータ側

他にVPNなど IPSec を使うものと衝突する可能性がある気がしないでも無い。。。anonymous の部分をアドレス指定しれば、行けそうな気がするが。。。未検証。

/etc/racoon/racoon.conf

...
remote anonymous {
	exchange_mode aggressive,main;
	my_identifier fqdn "client1";	# クライアントの認識情報
	dpd_delay 20;

	proposal {
		encryption_algorithm 3des;
		lifetime time 2 hour;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
	}
	generate_policy off;
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	encryption_algorithm aes, 3des;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}
/etc/racoon/psk.txt
...
server1	secret1

racoonは自動に起動しないので、適当名タイミングで起動する必要はある。

% sudo setkey -f /etc/racoon/setkey.conf
% sudo racoon
自動起動するには、「マスタリングIPsec 第2版」に記述の方法が簡単である。

確認

IPSec はアプリケーション側の修正の必要の無い物なので、、、普通にボリュームをマウントすると普通に使える。

まぁ気休めに、IPSec_SAをチェックすれば、

# setkey -D
192.168.0.20 192.168.0.10 
	esp mode=transport spi=131341201(0x07d41b91) reqid=0(0x00000000)
	E: aes-cbc  8250b455 59cc8799 c0d0b0b0 71b570a8
	A: hmac-sha1  6ff81843 b28130ed a5722694 32b134ee a0fc5b96
	seq=0x00000000 replay=4 flags=0x00000000 state=dying 
	created: Sep  8 14:51:43 2009	current: Sep  8 15:40:54 2009
	diff: 2951(s)	hard: 3600(s)	soft: 2880(s)
	last: Sep  8 14:51:45 2009	hard: 0(s)	soft: 0(s)
	current: 50750612(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 49393	hard: 0	soft: 0
	sadb_seq=1 pid=1233 refcnt=0
192.168.0.10 192.168.0.20 
	esp mode=transport spi=17664308(0x010d8934) reqid=0(0x00000000)
	E: aes-cbc  5d2d422b fe916f6d 501fedce e3d9650d
	A: hmac-sha1  6cfbf657 2eb74cb3 b64b5074 e34148b9 7bcaf934
	seq=0x00000000 replay=4 flags=0x00000000 state=dying 
	created: Sep  8 14:51:43 2009	current: Sep  8 15:40:54 2009
	diff: 2951(s)	hard: 3600(s)	soft: 2880(s)
	last: Sep  8 14:51:45 2009	hard: 0(s)	soft: 0(s)
	current: 2142076(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 26881	hard: 0	soft: 0
	sadb_seq=2 pid=1233 refcnt=0

ついでに tcpdump でサーバ側のパケットの流れを見れば、ESPパケットが飛び交ってるのが見える。。。

# tcpdump -i eth0 not port 22
...
15:38:24.183860 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0ba), length 116
15:38:24.184162 IP server1 > client1: ESP(spi=0x010d8934,seq=0x68e6), length 116
15:38:24.184625 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0bb), length 68
15:38:27.186886 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0bc), length 116
...

まとめ

SADの設定をちまちま行えば、他の通信もIPSecで保護が出来そうである。気になるのは、パフォーマンスがどこまで劣化するかなのだが。。。あまり期待は出来ないのかなぁ。。。


[全文を読む]

2009年9月3日

Time Machine を iSCSI 経由で使う (1) - 設定

Leopard から実装された Time Machine は非常に使い易い。 ただ、常にノートブックに外付けのHDDをぶら下げるのは、可搬性が損なわれる。 Time Capsule を使えば良いのだが、約10M Byte/s 位しか出ないらしい。

どうも iSCSI 経由で外部ストレージを繋げてバックアップ先に指定すれば、いい感じになれるらしい。

最近 Linux でよく使われているターゲットは「iSCSI Enterprise Target」であり、Debian lenny からカーネルモジュールもパッケージ化されており、apt 一発で使える。また、ストレージ層は Linux に依存しており、フォーマット縛りが無い。そのため、HDD単体をiSCSI経由で接続して使っていた場合、そのHDDをUSB等の変換アダプタで直に接続しても、そのままで使える利点がある。

Mac OSX のイニシエータは標準では用意されていないが、サードベンダー製の「globalSAN iSCSI Initiator for OS X」が無料で制限なしで利用できる。

コイツらを組み合わせると、Time Machine の初期化やリカバリ時だけマシンに直付けして、差分バックアップ運用時はiSCSI経由で行う事が出来る。

Linux で iSCSI target 設定

設定の内容は、

  1. お手軽な単方向CHAP認証を使い、ユーザ名 iscsiadmin /パスワードは12~16文字の適当な文字列にする。
  2. IQN(ISCSI Qualified Name)は iqn.YYYY-MM.domainなんたらをユニークになるように適当に付ける。
  3. デバイスの名前に関しては、固定される用に /dev/sd? ではなく /dev/disk/by-id/? を使う。
  4. イニシエータ制限をサブネット範囲でかけておく。

Debian lenny にバイナリパッケージが用意されている。

# apt-get install iscsitarget iscsitarget-modules-2.6-amd64

/etc/default/iscsitarget

ISCSITARGET_ENABLE=true
/etc/ietd.conf
IncomingUser iscsiadmin 123456789012

Target iqn.2009-09.com.example:stroage.fileserver.timemachine
	IncomingUser iscsiadmin 123456789012
	Lun 0 Path=/dev/disk/by-id/scsi-XXXXXX,Type=blockio
/etc/initiators.allow
ALL xx.xx.xx.xx/24
うんで、/etc/init.d/iscsitargt start で、iSCSI ターゲットのサービスを有効化する。

Linux の Open-ISCSIを使って確認

適当な iSCSI イニシエータが必要なので、Open-iSCSI を設定して確認する。

# apt-get install open-iscsi
/etc/iscsi/iscsid.conf
...
node.session.auth.authmethod = CHAP
node.session.auth.username = iscsiadmin
node.session.auth.password = 123456789012
...
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = iscsiadmin
discovery.sendtargets.auth.password = 123456789012
...
うんで、/etc/init.d/open-iscsi start で、iSCSI イニシエータのサービスを有効化する。

取り敢えず、検索すると

# iscsi_discovery xx.xx.xx.xx
iscsiadm: No active sessions.
Set target iqn.2009-09.com.example:stroage.fileserver.timemachine to automatic login over tcp to portal xx.xx.xx.xx:3260
Logging out of session [sid: 5, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Logout of [sid: 5, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
discovered 1 targets at xx.xx.xx.xx
何となく、ターゲットが発見できる。

ついでに、ノードに接続して確認すると

# iscsiadm -m node -p xx.xx.xx.xx -l
Logging in to [iface: default, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Login to [iface: default, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
# cat /proc/scsi/scsi
...
Host: scsi27 Channel: 00 Id: 00 Lun: 00
  Vendor: IET      Model: VIRTUAL-DISK     Rev: 0   
  Type:   Direct-Access                    ANSI  SCSI revision: 04
...
# iscsiadm -m node -p xx.xx.xx.xx -u
Logging out of session [sid: 7, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Logout of [sid: 7, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
まぁ、ディスクが見える!

Mac OSX 上での設定

globalSAN iSCSI Initiator for OS Xから、パッケージをインストールして再起動し、GUIに従って設定すれば良い。

  1. 「システム環境設定」から「globalSAN iSCSI」を選択
  2. 「Portals」タブで、ターゲットマシンのIPを追加する。このとき、「Advanced Settings」で、CHAP認証を有効にして、User Name/Target Secret をISCSIターゲットで設定したものにする。
  3. 「Targets」タブにISCSIターゲットのIQNが見えるようになる。
  4. ISCSIターゲットのIQNを選択して「Log On」をする。
  5. 後の扱いはローカル接続のHDDと同じで、必要に応じて「ディスクユーティリティ」で初期化する。

Time Machine の設定は、ローカル接続のHDDと同じような扱いで、HFS+のボリュームを作って指定すれば普通に使える。。。快適じゃぁ。。。


[全文を読む]

2009年7月21日

Linux でボリュームを暗号化する (3) - 性能比較

ボリュームを暗号化する上で気になることは、どれくらいIOの性能が落ちるかである。

普通にそこら辺にある2台でベンチを取ってみた。

  • ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
  • EPIA-EN12000EG (C7 1.2GHz) / DDR2-533 1G
暗号化するのは、ちゃっと起動用とは別に確保してた SATA 320G HDD(ST3320620AS) を使った。次いでなので、VIA PadLock の有無も比較してみた。

測定は hdparm -t を使って3回で最も良い値を使った。

読み込み速度(MB/sec)
M2NPV-VM (2GHz) - 素74.82
M2NPV-VM (2GHz) - cryptoあり71.650.96
M2NPV-VM (1GHz) - cryptoあり36.100.48
EPIA-EN12000EG - 素76.04
EPIA-EN12000EG - cryptoあり/PadLock 有43.260.57
EPIA-EN12000EG - cryptoあり/PadLock 無12.640.17

格段に劣化する訳では無さそうで、 ファイルシステムが絡めば DiskIO と暗号化処理が並列化しそうなので、 気にならない程度に落ち着くのかなぁ。。。

あと VIA PadLock は結構効果があり、in-order 1.2G だけだと非力なのかぁ?

Intel Atom だとどの程度になるか気になるなぁ〜。。。それとも Atom 系に AES-NIが実装されるのを気長に待つ方がいいのかなぁ。。。

修正(2009/09/08)

Athlon64X2 は cpufreq の ondemand governor を使ってたため、どうも結果が怪しかったので、クロックを固定して再度計測し直した。

結果、Athlon64X2に関しては 結構クロック周波数に比例した性能であり、2GHz 程度の性能があれば汎用CPUには苦にならないようである。C7は PadLock を使うとやっと一人前であるが、他を凌駕する性能とかは無さそうだなぁ。。。


[全文を読む]

2009年7月20日

Linux でボリュームを暗号化する (2) - LVMの保護

最近は、起動用の小容量HDD/SSDと複数データ用の大容量HDDの組み合わせでPCを組んでいる。SSDが手頃な価格になれば、その傾向も大きくなると思う。起動用のHDDの暗号化は、手法が多く、それぞれに結構面倒設定が多いし、どんどん新しい手法が出てきそうだし、枯れるまで様子見の方がいいかなと思う。なので、データ用の大容量HDDを暗号化することのみを考える。

次のサイトを参考に設定した。

PC
- 起動用 HDD/SDD
  /dev/sda
- データ用 大容量HDD (今はこっちだけ暗号化)
  /dev/sdb
古いデータの消去とパーティションの作成

新品のHDDを買ってきたのならば必要は無いが、念のため古いデータを乱数で上書きする。全容量を一つのパーティションに割り当てる構成にする。

# shred -n 3 -v /dev/sdb
# echo "0,,8e" | sfdisk -D /dev/sdb
LUKSパーティションの作成

LUKSパーティションには2種類のキースロットを割り当てる

  1. パスフレーズ(難解で長文なもの)を使う奴 -- 運用上何かと必要
  2. キーファイルを使う奴

# cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdb1
...
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: <= パスフレーズを入力
Verify passphrase: <= パスフレーズを入力
...
# mkdir -m 700 /etc/luks
# dd if=/dev/random of=/etc/luks/data01.key bs=1 count=32
# chmod 400 /etc/luks/data01.key
# cryptsetup luksAddKey /dev/sdb1 /etc/luks/data01.key
Enter LUKS passphrase: <= パスフレーズを入力
key slot 0 unlocked.
...
起動時にキーファイルを使って自動的に開始する設定

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-sdb1 /dev/sdb1 /etc/luks/data01.key luks
...

後は再起動するか、次のコマンドで暗号化を開始しとく。

# cryptdisks_start crypt-sdb1
VGの作成

出来上がったブロックデバイスを使って、LVMを組めば良く。

# pvcreate /dev/mapper/crypt-sdb1
  Physical volume "/dev/mapper/crypt-sdb1" successfully created
# vgcreate Data01 /dev/mapper/crypt-sdb1
  Volume group "Data01" successfully created

Volume Group が作成まで出来れば、あとは普通のLVMの使い方そのものなので、略。。。

まとめ

キーファイルを起動用ディスク内に保存することで、データ用ディスクが単体で切り離された場合にデータが保護できるようになるし、先頭ブロックの1MBくらいを消去することで完全に破棄することも可能になる。

これで 1T級HDD の破棄する場合のデータ消去が簡単になるんかいなぁ!?


[全文を読む]

2009年7月16日

Linux でボリュームを暗号化する (1) - swapの保護

Linux のブロックデバイスの暗号化は結構昔から行われている。鍵の管理が貧弱なので、使ってはいなかった。初回に選んだパスワードを未来永劫使うのは、どう考えても高リスクだろう。

諸々の要求に応える為に、Linuxでは LUKS(Linux Unified Key Setup) という珠玉の成果がある。コイツを使えば、パスワードの変更だけでなく、複数のパスワードを持つことも出来るという有り難い代物。

再三設定してるので、ちょっとメモっとかないと、禿げの進行が年2ミリ位 早くなってしますので、取り敢えず書いとく。

swapの暗号化

LUKSと言いながら、そうでないものを最初に書くのは何だが、メモリのベタ情報を swap から平文で読まれたくない人は、必ずすべき設定ですね。。。

Debian の cryptsetup 付属の文書 /usr/share/doc/cryptsetup/README.Debian.gz のそのまんまですねぇ。

現在のスワップの無効化

先ず、現在のシステムで /dev/sda2 が swap デバイスとして、swapを無効化し、中身を全消去する(新品で何にも書かれていない場合は、消さなくても構わない)。

# swapoff -a
# shred -n 1 /dev/sda2
設定ファイルを変更する

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-swap /dev/sda2 /dev/random swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
...
/etc/fstab
...
/dev/mapper/crypt-swap none swap sw 0 0
...

暗号化スワップの有効化
# cryptdisks_start crypt-swap
# swapon -a

仮想化環境のゲストOSはメモリ割当が少ない場合が多々あるので、要設定かと思う。

何でも無いが、Linux KVM 上のゲストOSの乱数エントロピーが溜まるの遅くないかぁ。時々、暗号化スワップの開始で4〜5分くらい止まることがときどきある。。。

おやぁ、virtio_rng とか言うモジュールがあるなぁ。。。あるよなぁ。。。コイツが kvm-85 ではまだサポートされていないからなのかぁ。。。KVM に virtio_blk, virtio_net, kvm-clock, virtio_rng の四つ揃えば、準仮想化と変わらんなぁ。。。取り敢えず、待つべし!


[全文を読む]

2009年7月9日

debian lenny の kvm はバグってる?

以前 Ubuntu に乗り換え宣言したのだが、マイナーなパッケージが無かったり、古いままだったり(まぁコミュニティーベースだから仕方ない)で、Debian lenny に再度乗り換えた。

一番の難点は、、、言わないのが約束だなぁ。

Debian lenny だと kvm-72 がパッケージングされているので、サクサクインストールして使えるのだが、どうも2個以上のゲストOSを立ち上げると何故だか次のメッセージをだしてゲストOSがフリーズしてしまう。

 BUG: soft lockup - CPU#0 stuck for 4096s!

なんすかねぇ?

症状としては、下記のバグ報告と同じっぽい。

で、kvm-84 だと直ってるらしい。。。

ぐふぅ。取り敢えずは、適当に sid からkvm/libvirtのソースパッケージを取ってきてビルドして諸々更新したら、複数のゲストOSがフリーズせずに安定した、、、気がする。

またもや debian squeeze 待ちかなぁ


[全文を読む]

2009年7月7日

HDDの内容を全部消去する

掃除をしたら多量にPATAのHDDも出てきた。

今まで簡単に特殊なドライバでサクサク開封して磁性体に多量の傷を付けて不燃ゴミにしていた。 個人で使っていたもので重要な機密とかが入ってる訳ではないが、少々心もとない。

shred を使って2回の乱数埋めと1回のゼロクリアでHDDの内容を全消去するのが、簡便で良い方法らしい。

# shred -n 3 -z -v /dev/hdb

だが、本当に遅い!

Debian/lenny のバージョンの GNU shred どうも必要な乱数全部を /dev/urandom から読み込むため、乱数生成の帯域で制限されてるっぽい。

shredのあれこれ』 によれば、coreutils-5 では利用する乱数は内部で生成しており、coreutils-6 から /dev/urandom から利用する形になり、6倍遅くなったよという。。。つまり別の乱数発生器の openssl rand を使えと。

で、使ってみたが、、、途中で終ってしまいます。。。

なんでやぁ!!

暫し、熟考の結果 openssl rand の引数は int32_t だったらしく、100Gとかの HDD の消去とかには使えないですなぁ。。。。次のようにすれば完遂できますなぁ

# mkfifo rnd
# while true ; do openssl rand  $((2**31-1)) ; done > rnd &
# shred --random-source=rnd -n 3 -z -v /dev/hdb

大体、上の方法で 300G で 10時間くらい?

ここまではバットノウハウの話。

coreutils の git レポジトリをつらつら流し見たところ。

と言う訳で、coreutils 7.3 からは coreutils-5 の頃の内部乱数(ISAAC)生成が復活し、パス数のデフォルトが 3 pass になるという。

要するに、shred を何も考えずに使った奴が勝者!

それよりも、320G HDD が8台もある敗北者の僕は 100MB/secくらいでるハードウェア乱数生成ボードが欲しい。。。


[全文を読む]

2009年6月29日

ReadyNAS の HDD の内容を普通のPCで読む

最近、HDDを整理してたら 320G SATA HDD (Seagate製) が 8台も出てきた。

うちで使っている ReadyNAS Duoには 2台の750G SATA HDD を載せているが、ボリュームの使用率が10%未満なので宝の持ち腐れな気がするので、ちょっと入れ替えてみた。

ReadyNAS Duoで実装されているX-RAIDは、HDDの容量を大きくする方向の変更は出来ても、小さくする変更は出来ない。まぁしょうがないので、大人しく別途バックアップを取って入れ替えた。

使っていた 750G HDDがフリーになったので、もの試しに読めるかどうか調べてみた。

LVMへのアクセス

普通のPCに繋いでみると、 一台のみにIBM PCベースのパーティションテーブルらしきある。

どうも先頭の2セクタを除いてミラーリングされているっぽく、2台中1台のみにパーティションテーブルが書かれているようだ。まぁ、同じ内容のディスクが変に認識されて混乱するのを避ける為なんだろうなぁ。

パーティションの最後が LVM のボリュームになっており、論理ボリューム上にデータ領域が確保されている。

# sfdisk -l -uS /dev/sdd

Disk /dev/sdd: 91201 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdd1             2   4096001    4096000  83  Linux
/dev/sdd2       4096002   4608001     512000  82  Linux swap / Solaris
/dev/sdd3       4608002 1465112305 1460504304   5  Extended
/dev/sdd4             0         -          0   0  Empty
/dev/sdd5       4608003 1465112305 1460504303  8e  Linux LVM

個々のパーティションは、シリンダ境界で区切られておらず、パーティションが無いもう一台に再現するのは、先頭2セクタをコピーするか、sfdisk を駆使するか、ちぃと面倒。

X-RAIDで容量の拡張とかしていなければ、dmsetup を使うのも良いかも。

# lvmsize=$((`blockdev --getsz /dev/sdd` - 4608003))
# echo 0 $lvmsize linear /dev/sdd 4608003 | dmsetup create readynas-pv 
# pvscan
# lvchange -ay -pr c/c
# lvs
  LV        VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  c         c      -ri-a- 696.41G                                      

ファイルシステムへのアクセス

LVMの論理ボリュームがアクセスできるようになったら、何にも考えずに ext2/ext3 でマウントをしてみると上手く行かない。

# mount -t ext3 -oro /dev/c/c /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/c-c,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
# dmesg | tail -1
[ 3446.561022] EXT3-fs: bad blocksize 16384.

man を見ると、ブロックサイズは1024,2048,4096の3種類しか有効でないが、いつの時点で実装されたか分からないが、ext2/ext3のブロックサイズはCPUアーキテクチャのページサイズまで拡張されている。ReadyNAS で使われていたext2/ext3 ファイルシステムはブロックサイズが 16K なので、普通にはマウントできなかったようである。

ext2/ext3でブロックサイズが大きすぎる場合、読むだけなら2通りの方法がありそうである。

dump/restore でのアクセス

まぁ何も考えずに dump/restore を使えば、ブロックサイズを気にせずにファイルシステム全体をコピーできるので、ファイルを取り出すことが出来る。容量が大きいHDDが用意できるのならば、安定したアクセスが出来る。

# dump 0f - /dev/c/c | ( cd /backup ; restore rf - )

fuse ext2 でのアクセス

fuse 様にお伺いすると、ext2/ext3 にアクセスできる奴がある。。。コイツもブロックサイズの制限を気にせずにアクセスできる。ただ、、、まぁ、、、枯れきっていない感があるなぁ。

# apt-get install fuseext2
...
# fuseext2 -o ro /dev/c/c /mnt
# mount | grep mnt
fuseext2 on /mnt type fuse.fuseext2 (ro,nosuid,nodev)

まとめ

取り敢えず、ReadyNAS Duo からサクサクとファイルを抜き出せるようになりましたと。。。まぁ、ファンが五月蝿いから捨てますかねぇ。


[全文を読む]

2009年4月21日

ファイルサーバのHDDを省エネHDDに変更

VIA EPIA-EN が安定運用?の見込みが出てきたので、ちょっくら省エネを追求してみた。

今使っている Mini-ITX ケースは、「Be Silent GAWA6200」で、今使っている EPIA-ENシリーズにまさに対応しており、ファンレス運用が可能。ただ、どうも安定しないので12cmファンをぽこっと載せ、風量を確保する為に、エアフロー用の金網部分を外していた。するとちょうどいい具合に、オンボードの SATA ポートにアクセス出来る。なので、eSATA接続の外付けHDDが使える!!

P1010640

eSATA接続の外付けHDDは、USB接続みたいに速度が出ないことは無く、各社多様に製品群が発売されており、いろいろ選べてお得だし!安いし!速いし!良いこと尽くめ!

交換可能で静かなのが欲しいので、「LogitecのLHR-DS02SAU2」とWD10EADSの組み合わせを選んでみた。


"Logitec クレードルタイプ HDDリーダー/ライター LHR-DS02SAU2BU" (ロジテック)

さっと入れ替えてみると、、、アイドル時に約23W程度で、かつHDD が spindown? すると 20W 弱。負荷をかけても 30 W程度くらい。

P1010639

いい感じだぁ。全部が収まる Mini-ITXケースがあればいいのかぁ。


[全文を読む]

2009年4月19日

MacOSX で USB-RS232 アダプタを使う

USB-RS232 アダプタで MacOSX 対応のドライバを提供してるのはあまり見かけない。 初期設定を RS232 経由で行うルータとかハブとかがあり、その時だけWindowsとか言う奴を使っていた。

しつこく探してみたところ、オープンソースでドライバを作っているところがあった。 Prolific 社の PL2303 チップを使ったUSBアダプタ全般で使えるようである。

手持ちにある以下の二種類のアダプタで問題なく使えた。

  1. CentreCOM VT-Kit2 plus
  2. I/O DATA USB-RSAQ2

アレイドの奴は使えて結構嬉しい。

端末エミュレータには、MacPorts から screen を使えばよい。

% screen /dev/tty.PL2303-XXXXXXXX 9600 cs8
端末から抜けたいときはつかさず C-a C-\ とかやる。


[全文を読む]

2009年4月13日

VIA EPIA-EN で watchdog を設定

iPod Touch のアプリに某掲示板の専用ビューア BB2C がある。 結構使い勝手が良いので、最近ぱらぱら見るようになった。 その中で、自作PC板の低消費電力なんとかスレッドを覗いたら、 PCのアイドル時の消費電力が 20W〜30W の報告があり、10Wとかもある。 ちょっとビックリ。

なんやかんやで、ここ2年くらいCPUもマザーボードも買っていないので、 すっかり取り残されてしまったようである。 手持ちのパーツの Athlon64X2 3800+/M2NPV-VM/DDR2-800 2Gx4 を組み合わせて、 アイドル時の消費電力が 70W となど浮かれていたのは、どうも井戸の中の蛙だったようである。

はぁ〜〜。金欠だし、どうしてくれようかぁ

しょうがないので、箪笥の奥に眠っていた EPIA-EN12000EGを引っ張りだしてきたのだが、 コイツは Linux では時々ちょっと原因不明のハングアップして常時運用とか向かないので ゴミかなと思っていた代物である。

動かせるように組み直して計測してみると、アイドル時の消費電力が 15Wくらいである。 某 Early2009 とほぼ同じ。でもあっちは Core2Duo 、、、懐が淋しいので我慢しよう。

P1010634P1010635

最新のカーネルであれば、問題が修正されているかと思って様子を見たが、 頻度は多くないがハングアップする現象はあるようである。

マニュアルには「Watchdog Timer」の記述があり、コイツがなんとかできればハングアップしても強制再起動ができ、常時運用が出来そうである。

、、、えっと、ドライバはどれ?

ググるところ、小一時間。下記のURL のフォーラムにズバリの回答があった。
tkArena Forums > VIA Arena > VIA EPIA (Mini-ITX, Nano-ITX, Pico-ITX) Arena - hardware watchdog

Super I/Oチップの w83697hf に watchdog timer が実装されており、そいつがどっかにリセットのシグナルを出すらしい。

watchdog モジュールのロード

EPIA-EN12000EGの場合、watchdog はデフォルトI/Oポートにいないので、 w83697hf_wdtをロードしても、次のようなログが残り使えない。

[   30.529537] w83697hf/hg WDT: WDT driver for W83697HF/HG initializing
[   30.529550] w83697hf/hg WDT: Looking for watchdog at address 0x2e
[   30.529573] w83697hf/hg WDT: watchdog not found at address 0x2e
[   30.529580] w83697hf/hg WDT: No W83697HF/HG could be found

なので watchdog の I/Oポートを検索するために、wdt_io=0 を指定してロードすると、結果がdmesgに出力される。

[  202.597226] w83697hf/hg WDT: WDT driver for W83697HF/HG initializing
[  202.597241] w83697hf/hg WDT: Looking for watchdog at address 0x4e
[  202.597260] w83697hf/hg WDT: watchdog found at address 0x4e
[  202.597401] w83697hf/hg WDT: initialized. timeout=60 sec (nowayout=0)

再起動後に発見したI/Oポートを探すように、/etc/modprobe.d/local に書き出しておく。

options w83697hf_wdt wdt_io=0x4e timeout=60

watchdog パッケージの設定

Debian lenny なので、パッケージをサクッとインストールする。

# apt-get install watchdog

/etc/default/watchdog にモジュールの指定を書く。

watchdog_module="w83697hf_wdt"

今回は死活のみを監視するので、 /etc/watchdog.conf は下手にいじらないで次の行のみ有効化する。ただ、watchdog自体の負荷が気になるならば interval を多めに取ればいい(ドライバ指定のtimeout以下になるように)。

watchdog-device	= /dev/watchdog

watchdogデーモンを立ち上げると完了する

# /etc/init.d/watchdog restart

watchdog の確認

あぁ、、、「killall -9 watchdog 」で暫くして強制再起動がかかれば確認完了。。。

まとめ

なにげにSSD-IDEを載せたので、内蔵ストレージに書き込みが頻発するのは避けたい気がするので、箪笥の中から掘出した3年ものの外部ストレージをつけてみた。

P1010636

なに!PCの同じだけ電力を食うのかこの外付けHDDは!

なにげに、VIA EPIA-EN を使いこなしているような気がする。


[全文を読む]

2009年2月1日

NetBSD 4.0.1 の amd64 版の boot-big.fs はどこ?

最近、Debain/NetBSD/OpenBSD/FreeDOSの安定版のインストーラー(amd64版があればそいつを含んだ奴)を一つにまとめた DVD を欲しくて作ってみた。

grub2 は USB-CD/DVD のアクセス対応のコードがまだ天から降ってこないので、まだ isolinux を使う必要がある。(grub2のbsd系のブートコマンドは、まだ 64bit ELFをサポートしていないので、まだまだなんだがなぁ。。。)

Linux 以外では、floppy イメージをsyslinux の memdiskでエミュレートすることで、インストール作業ができる。ただし、floppy ディスクの交換までエミュレートできないので、一つにまとまったイメージが必要になる。

で、

NetBSD/amd64 4.0 には、boot-big.fs はあったのだが、4.0.1 では提供されていないぞっと。。。なんでかぁ

困ったなぁ

コイツらは普通につくれるのかぁ、、、、Linux システム上で!

小一時間考えて、作ってみた。

NetBSD 4.0.1 のバイナリファイル群を取ってくる。下のスクリプトのTOPDIRに指定して、スクリプトを走らせると。。。memdisk でブートできる boot-big.fs を出来る。。。

#!/bin/sh

TOPDIR=/path/to/NetBSD-4.0.1/amd64

BOOTBIGFS=${TOPDIR}/installation/floppy/boot-big.fs

[ -e $BOOTBIGFS ] && exit

#VOLSIZE=5760  # blocks

workdir=/tmp/work$$
mkdir $workdir
mkdir $workdir/USTAR

tar xfz ${TOPDIR}/binary/sets/base.tgz -C $workdir ./usr/mdec

cp $workdir/usr/mdec/boot $workdir/USTAR
cp $workdir/usr/mdec/bootxx_ustarfs $workdir
cp ${TOPDIR}/binary/kernel/netbsd-INSTALL.gz $workdir/USTAR/netbsd

if [ "x$VOLSIZE" = "x" ] ; then
	needblocks=`du -s -B512 $workdir/USTAR | awk '{print $1}'`
	VOLSIZE=`expr $needblocks + 20`
fi

OVOLSIZE=`printf "%o" $VOLSIZE`
touch $workdir/USTAR/USTAR.volsize.$OVOLSIZE
tar --posix -cf $workdir/USTAR.tgz -C $workdir/USTAR boot USTAR.volsize.$OVOLSIZE netbsd

dd if=$workdir/bootxx_ustarfs of=$workdir/boot-big.fs
dd if=$workdir/USTAR.tgz of=$workdir/boot-big.fs seek=16

cp $workdir/boot-big.fs $BOOTBIGFS

rm -rf $workdir

USTARFSは、initrd で cpio イメージを使うっぽい感じで tar を扱う奴らしい(ちょっと違うけど)。ボリュームのサイズは含まれる特殊なファイル名(USTAR.volsize.XXXX)で指定され、かつ8進数を使うのは、、、如何にも歴史を感じられるなぁ~

で、目的のDVDを無事ゲットできましたとさぁ。。。

まぁ、ついでに Ubunut 8.04.2 LTS Desktop/Server i386/amd64 も作ってもうたぁが、それは別の話。


[全文を読む]

CPANでインストールしたモジュールは?

Linux 上で Perl を使う場合、 自前ではビルドせずに大抵ディストロのパッケージ(rpm/deb)を使うのがほとんどである。 CPAN上のモジュールでも対応するディストロの方を使うのが、僕は好みである。 ディストロ側に対応するパッケージが無い場合は、仕方なく cpan コマンドを使ってインストールして使っている。

cpan -i モジュール名

cpan コマンドでインストールしたモジュールをアンインストールしたいとか思っても、いまいち方法が分からなかった。。。

「cpan help」 とかやると、よくわからん help モジュールがインストールされたり、「cpan list」とやっても、list モジュールが、、、以下略。

で、CPANを使うと運用状態が続くと /usr/local 以下が何故だか意味不明な状態になってしまう。

私だけだろうけど、、、どうしたもんだろうかなぁ。

cpanコマンドでインストールされたもののリスト

ExtUtils::Installed モジュールを組み合わせると取得できるようなので、次のようにスクリプトを組んでみた。

cpan-list

#!/usr/bin/perl

use ExtUtils::Installed;

$inst = ExtUtils::Installed->new();

for $module (sort $inst->modules()) {
	$version = $inst->version($module);
	print "$module $version\n";
}

どっかの御大ならば一行スクリプトに仕立てるんだろうけどねぇ。。。
そこまで Perl 臭が染み付いていないので、これでいいかなぁ。。。

実行例

# ./bin/cpan-list      
HTML::Perlinfo 1.54
Perl 5.8.8

cpanコマンドでインストールされたもののアンインストール

同様に ExtUtils::Installedとかを組み合わせると、アンインストールするスクリプトが作れる。

cpan-uninstall

#!/usr/bin/perl

use ExtUtils::Installed;
use ExtUtils::Install;

$module = $ARGV[0];

$inst = ExtUtils::Installed->new();
@modules = $inst->modules();

(grep $module,@modules) || die "$module is not install...";

uninstall($inst->packlist($module)->packlist_file());
print "uninstalled $module\n";

削除したいものを指定すれば削除できる。

実行例

# ./cpan-uninstall Module::Name
uninstalled Module::Name

まとめ

果たして、これで良いのか疑問に残るが、目的は達したので良いのかなぁ。。。
取り敢えず、ディストロとCPANの組み合わせは怖くなくなったぞぃと。


[全文を読む]