Google Code Prettify

ラベル Disk の投稿を表示しています。 すべての投稿を表示
ラベル Disk の投稿を表示しています。 すべての投稿を表示

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月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 からサクサクとファイルを抜き出せるようになりましたと。。。まぁ、ファンが五月蝿いから捨てますかねぇ。

2008年11月29日

ReadyNAS Duo を購入

ファイルサーバを普通のPCで組み、常時起動して運用すると、月々の電気代がちょっと気になる。

今使っている PC+HDDx4 台の電力消費をワットチェッカで計測すると、ほぼ130W前後になる。コイツが、24時間通電してると、一日 約3kW/h で、約60円程度になる。年間約2万円くらい使ってる計算になる。

RAID0+1の構成が取れるHDDx4台は魅力的だが、、、長期的に見ればHDDx2台(RAID1)のNASに移行するべきですかぁね。。。

HDDx2(RAID1)のNASは、各社多様に製品が展開されている主戦場ですなぁ〜〜

HDDが交換が簡単で扱い易そうなものが良いので、「ReadyNAS Duo」のべアボーンタイプを選択してみた。


"ReadyNAS Duo ホームメディア・サーバー ペアボーンタイプ" (ネットギア)

搭載されているX-RAIDを使えば、容量が同じでない場合でも冗長構成を取れる。余っているSATA HDDとかは容量はまちまちな場合が多いので結構便利だと思う。

最初の初期化は何やらHDD上にファームを展開してるためなのか結構時間がかかる。焦らずに Web管理画面(FrontView) にアクセスできるまで気長に待つ必要がある。

add-onで種々の拡張ができるのも売りで、SSHアクセスやDebian由来のAPTが可能である。 apt が参照してるパッケージ群はベンダーのNETGEAR提供のものに加え、Debian/sarge のものが使える。

ただ sarge 自体はサポート終了してるので、apt-line を debian-archive の近いサイトに変更する必要がある。

deb http://www.readynas.com/packages readynas/

deb http://ftp.riken.jp/Linux/debian/debian-archive sarge main contrib non-free
deb http://ftp.riken.jp/Linux/debian/debian-non-US sarge/non-US main contrib non-free

今更な sarge かぁ。。。

また、NASには珍しく主メモリS.O.DIMMで提供されてより大きなものに交換ができ、より複雑なアプリでもを動かした場合も、結構スラッシングを抑えられる。

でもsargeベースなんだよなぁ。。。

普通にベンダーのファームを使い切るのがベストなんだと思うなぁ。

コイツに使われてる IT3017 は、どうも LEON とか言う Sparc v8 互換のCPUらしい、、、つまり、初めて所有する Sparc になりましたっす。。。 というか Sparc+aptの2点で買いだったのだが、、、

SSH でアクセス出来るので、ローカルでベンチを取ったところシーケンスIn/Outともに、普通のPCの半分以下程度だったっす。ベンチの計測中は、どうもPCに比べてCPUが回りすぎる気がする。

コイツのSATAのバスマスタ転送の実装がヘボイのか、今のx86系のChipsetが優秀すぎるのか、どっちだろう?

今後出てくるだろうATOM系のNASの性能が答えを出してくれるんだろうなぁ。というか、早く優秀なChipset積んで出てこいやぁ!!

まぁ ReadyNAS Duo はNASとしては買っても損はないが、もう少し凝ったことをやりたければ、debian/lenny がインストールできるQNAP NASGLAN Tankとかがお勧めだなぁ。

sarge 止まりなんだよなぁ。。。惜しいなぁ

2006年10月29日

PATAの仕様とLinuxのドライバコード

ATAの仕様書は購入する必要があるが、Final Draft なら読めるので、ここ1週間ばかり齧り付いていた。

で、簡単なドライバコード(linux2.6のdrivers/ide/legacy/hd.c)だけならば読めるようになったが、PCIやらDMAバスマスタなると、ちんぷんかんぷんでまるで分からない。

ざーっと理解したところでは、PATAの1 channel の下に2台のHDDぶら下げる場合、大抵はリクエストをoverlapして発行はできず、1リクエストが完了するまでバスを占有する。

1channelの下に HDDとCD-ROMなどをぶら下げる場合、CD-ROMがATAPI(PACKETコマンドが実装されている)準拠なので、必要に応じてリクエストの途中でバスを解放できるらしいので、そんなにHDDに影響は与えないらしいが、、、本当か?、、、測定しなければ分からんなぁ。

ただ、仕様書ではTCQなりをサポートするHDDでは途中で解放なりキューイングなりができるが、PATA HDDで実装されているものがなく、あったとしてもキューのサイズが1とかだったり、その上Linuxの大抵のIDEのドライバコード?(or ハードウェアのチップの問題?)でサポートされていないので使えないらしい。

2006年10月21日

ディスクIO性能(14) - ベンチマーク再考(2)

シーケンシャルなI/Oの性能とI/Oのレコード処理単位の統計を取ってみた。使ったツールはdebian/etch に含まれている bonnie++ 1.03atiobench 0.3.3 である。

何回も測定すると値が大きく変動するのが気持ち悪いので、10回測定してベストとワーストを除いた8回分の平均を取るようにした。

環境

毎度のこと検証環境は、

  1. Athlon64X2 3800+ (但し、Single CPUとして制限)
  2. M2NPV-VM(GeForce6150+nForce 430MCP)
  3. メモリは512M(カーネルパラメータで制限)
  4. システム用のHDDで Segate ST3500630AS, SATA
  5. Debian/etch Linux-2.6.16
  6. Seagate ST340015A, 40GB, PATA UDMA100, 2MBキャッシュ, 5400 rpm の4台

HDDの設定

4台のHDDは hdparm を使い、下記の様に設定。

# hdparm -d 1 -c 3 -m 16 -W 1 -tT /dev/hda

/dev/hda:
 setting 32-bit IO_support flag to 3
 setting multcount to 16
 setting using_dma to 1 (on)
 setting drive write-caching to 1 (on)
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 using_dma    =  1 (on)

 Timing cached reads:   3936 MB in  1.99 seconds = 1973.79 MB/sec
 Timing buffered disk reads:  130 MB in  3.03 seconds =  42.97 MB/sec
ファイルシステム

RAIDボリュームは 標準的な ext3 に初期化した。

測定コマンド

bonnie については、下記のコマンドを使用(/mntに対象ボリュームをマウント)。

# bonnie -u root -d /mnt -n 0 -f -b -s 1024:4
tiobench については、下記のコマンドを使用(/mntに対象ボリュームをマウント)。
# tiotest -t 1 -r 1 -T -d /mnt/0 -f 1024 -b 4096
上記はI/Oの単位ブロックサイズが 4096 bytes の場合。

測定

測定は、md で下記構成のRAIDボリュームに対して、bonnie++(1.03a)、tiobenc(0.3.3)を使い、I/Oの単位ブロックサイズ 1k,2k,4k,8k,16k,32k,64k,128k,256k,512k,1024kのシーケンシャルなread/write の性能を測定する。また、各測定に関して10回行いベストとワーストの値を除いた8回の平均を取った。

  1. RAID0 のHDDx1台(1u)。
  2. RAID0 のHDDx 2 台(2u-2ch)。但し、IDEの2チャンネルにそれぞれにHDDを割り当てる。
  3. RAID0 のHDDx 2 台(2u-1ch)。但し、IDEの1チャンネルのみにHDDを割り当てる。
  4. RAID0 のHDDx 3 台(3u)。IDEの片方のチャンネルに2台で一方に1台を割り当てる。
  5. RAID0 のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。
  6. linear のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。

結果

数値データはヘボヘボに長いのでグラフのみにした。

blog20061027-write-bonnie
blog20061027-write-tiobench
blog20061027-read-bonnie
blog20061027-read-tiobench

  1. bonnie++を使った場合、2u_1ch/3u/4uの seq. write の性能が単位ブロックサイズ 4k〜256kの間に緩やかに上昇している。512k移行は、tiobenchと同じ傾向になっている
  2. tiobenchを使った場合、seq. read/write 共に単位ブロックサイズ1k〜2kにおいて性能の落ち込んでいる
  3. 上記以外では、I/Oの単位ブロックサイズに性能が左右されてる傾向はない。

ふぅーむ。 よくよくI/Oスケジューラの性質を考えれば、Seq I/O性能はI/Oの単位ブロックサイズに性能が左右されないように思える。

  1. Seq. Write の場合、使用したファイルシステム ext3 は 1ファイルに対してなるべくシーケンシャルな順序でブロック割り当てられる可能性が高い。小さな単位のブロックサイズであっても遅延書き込みのため待たされたリクエストがマージ処理で併合され大きな単位のブロックサイズとして扱われるため、十分RAIDのチャンクサイズを超える。そのため書き込みは並列化される頻度が一様に高く、I/Oの単位ブロックサイズに性能が左右されずに一定(最大実効性能)になる。
  2. Seq. Read の場合、とっても簡単でI/Oスケジューラの設定でHDD単位で128kbytesの先読みが行われ、バッファキャッシュされるで、I/Oの単位ブロックサイズに性能が左右されずに一定になる。
但し、幾つかの前提条件を外していくと陽になる場合もありそう(同時負荷、バッファキャッシュメモリ不足、スケジューラの設定やO_DIRECTの利用 etc)。

うんで、 bonnie++ で測定したときに現れていた 2units/1channel の性能劣化がどうもベンチマークソフトの問題のように思えてくる。 tiobench でさえも問題を抱えていそうである。

さぁて、、、何が出てくるかなぁ。

2006年10月13日

ディスクIO性能(13) - I/Oスケジューラ

Linux の I/O スケジューラは 2.6 から4種類から選択できるようになっている。つい最近まで、anticipatory(as)が標準だった。なので、前回までの検証環境ではこれを使って評価していた。

どのI/Oスケジューラ(1,2,3)が良いかは一概に言えない。。。らしい。

  1. noop 単純なFIFO順。マージンのみを行う。ランダムアクセス時にシーク遅延がないものや独自にスケジューリングを行うデバイスに合う。フラッシュメモリ(CFも含む?)やラムディスク用。
  2. deadline セクタ順でソートし片方向の elevator を行い、同時に期限を設定して応答性を確保する。読み込みを優先する。(2.4までのスケジューラをかなり改良したものかぁ?)
  3. anticipatory deadline がベース。適度に待ちを発生させて、セクタ順でのソートの機会を多くする。このとき読み込みパターンの履歴から予測して待ち時間を決める。結果シーク遅延を減りスループットを向上するらしい(元ネタ)。但し、予想が上手く行かずにボロボロになる場合があるらしい。 小規模なシステム、ディスクトップ向けらしい。ファイルサーバにも良いらしい。RAIDやTCQ/NCQを持つものには向かないらしい。
  4. CFQ(Complete Fair Queuing) リクエストをプロセス毎に均一に割り当てる。Fair Queuing と呼ばれるスケジューラの一族らしい。イマイチ実態つかめず。

なので RAID で anticipatory スケジューラの組み合わせはダメダメな気がする。

これからスケジューラのパラメータでチューニングする場合 deadline か CFQ を当たるのがよさげ。

2006年10月1日

ディスクIO性能(12) - ベンチマーク再考(1)

シーケンシャルな write/read に関しては bonnie++ でも十分意味ある計測が可能だが、ランダムアクセスの性能の測定に関して些か疑問がある。

bonnie++に関して「Random Seek 」という項目があるが、「4つの子プロセスを作成し、合計4000回のシークを発生させ、各シークでReadを行い、また10%については同時にWriteも行う。その時間を測定し1秒間に平均何回シークできたかを測定するもの。」らしく。普通のアプリケーションの一般的なI/O発生パターンを再現しているらしい。がイマイチ分からん。

そろそろベンチマークソフトを変えてみようかと思う。

benchmark は広く深い泥沼や。

  1. bonnie
  2. Bonnie++
  3. iozone
  4. Iometer
  5. tiobench
  6. UnixBench
  7. dbench
  8. nbench
  9. ubench
  10. LMBench
で、どれが良いのだろう。

、、、tiobenchあたりが丁度よさげである。

再度、tiobench を使ってデータを取り直そうかと思ったが、以前のデータが致命的な欠陥が合ったことが分かってしまった、、、。bonnie++ のchunk sizeが 8M bytes だと思っていたのだが 8K bytes の誤りだった、、、情けなさぁ。この測定パラメータだと、RAID0 の chunk size 64K より小さいため適度にI/Oが分散されないため、正しい結果が得られそうにない。

何をともあれ bonnie++/tiobench/iozone3の評価をやり直そう。

  1. RAIDで指定した chunk size とベンチマークでのblock I/O単位のchunk sizeの関係は?
  2. シーケンシャル・ランダムのI/Oのスループットは?
  3. 各I/Oスケジューラの性能は?
  4. 等々
まだ、頭の中がごちゃごちゃしてる。

ディスクIO性能(11) - 性能向上に重要な事

「ディスクI/O性能はどのようにすればあげられるのか」を考えてみよう。

そんな本題を考える上でよさげな資料「Performance Comparison of IDE and SCSI Disks 」を見つけた。直接的には、IDEとSCSIを比較した物だが、パフォーマンスを考える上で着眼しなくては行かない点を示してくれる。

ちょー適当にまとめると

  1. ランダムアクセスを向上するには、Tagged Queuing が重要である。ディスク内部のスケジューラが寄与する部分である(つまりはディスクのファームの支配領域)。SCSIとIDEともに TCQ/NCQ として知られており、シーク性能に応じてこれを深くすると良い。但し、IDEのシーク性能が若干劣るのでTCQ/NCQの最大の深さ32では足りなそう。
  2. kernel側のスケジューラは重要。例ではFreeBSDなのでパットしない(デバドラ内にスケジューラがあるのかぁ、、、?)が、ランダムアクセスやインタリーブアクセス?が向上するらしい。多分、複数プロセスで発生するI/Oを捌くには重要な事らしい。
  3. ファイルシステムの種類によって同じ負荷時に発生するI/Oのパターンが変わるらしい。IDE/SCSIはその発生パターンに応じて性能の善し悪しがあるらしい。。。のかぁ?
  4. RAID0/RAID5は使った方がよろしい。HardwareRAID(隠れたSoftwareRAIDを含む)のI/Oスケジューラは馬鹿に出来ないらしい。出来ればベンダー提供のドライバを使った方が吉か!?

つまりは、TCQ/NCQとI/O elevatorとファイルシステムが重要で、ベンダー提供のRAID用ドライバはI/Oスケジューラの改良が入ってる場合があるので馬鹿にならないのかぁ、、、最後が微妙。

ディスクの並行実行性とスケジューリングが性能向上に重要といえば当たり前に聞こえる。検索に結構この問題に対する論文が引っかかってくる(1)。

  • Linux では、SCSI では TCQ は設定出来るが、IDE (/dev/hd?になるデバドラ)にはTCQは入ってい無さそう。SATAのドライバ(libata??)からNCQが使えそうだが詳細は不明だし。
  • Linuxの各種ファイルシステムの善し悪しはどうなんだろう。。。ext3 で良いじゃんと思うが。
  • ベンダー提供RAID用ドライバのI/Oスケジューラの向上はどれくらい入っていたのかも気になる。
  • Linux, Solaris, WindowsNT, FreeBSD/NetBSD 間で I/O elevator を比較をしてみたい気がする。

さて、どれやろうかなぁ。

2006年9月29日

ディスクIO性能(10) - PDC20270/ITE8212/430MCPの比較

取り敢えず PDC20270/ITE8212/430MCPのmdベースのRAID0性能を比較をしてみる。

blog20060928-RAID0-all

  1. 2units(2channel)で明らかなRAID0性能向上の傾向がread/writeともに見られる。但し、PDC20270のwriteの向上は鈍い。
  2. 実際の2units(1channel)の性能は1unit比べてやはり劣化がある。
  3. サウスブリッジ内蔵(430MCP)とPCI直下のChip(PDC20270/ITE8212)の性能の違いは無い。

2units/1channel の性能劣化の良い説明が思いつかない(嘆いているっぽいはいる)。IDE channelの共有による調停とかのボトルネックなのかなぁ? IDEインターフェース自体やPCIのDMA転送の仕組みが分からないとイマイチ理解できないなぁ。。。

本題の「ディスクI/O性能はどのようにすればあげられるのか」を考えると、経験則としてストックすべきなんだろうなぁ。

2006年9月27日

ディスクIO性能(9) - 430MCP上でのRAID0の性能

M2NPV-VM の onBoard のPATAであるnForce 430MCPに4台のHDDを繋いで幾つかのベンチマークを取ってみた。

果たして、Chipset に組み込まれているIDEは早いらしいとか言うのは正しいのだろうか?

環境

毎度のこと検証環境は、

  1. Athlon64X2 3800+ (但し、Single CPUとして制限)
  2. M2NPV-VM(GeForce6150+nForce 430MCP)
  3. メモリは512M(カーネルパラメータで制限)
  4. システム用のHDDで Segate ST3500630AS, SATA
  5. Debian/etch Linux-2.6.16
  6. Seagate ST340015A, 40GB, PATA UDMA100, 2MBキャッシュ, 5400 rpm の4台

Chipset のサウスブリッジ 430MCPには、IDEインタフェースが組み込まれている。

# lspci -s 00:0d.0 -v
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1) (prog-if 8a [Master SecP PriP])
        Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at f400 [size=16]
        Capabilities: [44] Power Management version 2
 

測定

測定は、md で下記構成のRAIDボリュームに対して、シーケンシャルなread/write の性能を 、bonnie++(1.03)を使い測定する。

  1. RAID0 のHDDx1台(1u)。
  2. RAID0 のHDDx 2 台(2u-2ch)。但し、IDEの2チャンネルにそれぞれにHDDを割り当てる。
  3. RAID0 のHDDx 2 台(2u-1ch)。但し、IDEの1チャンネルのみにHDDを割り当てる。
  4. RAID0 のHDDx 3 台(3u)。IDEの片方のチャンネルに2台で一方に1台を割り当てる。
  5. RAID0 のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。
  6. linear のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。

HDDの設定

4台のHDDは hdparm を使い、下記の様に設定。

# hdparm -d 1 -c 3 -m 16 -W 1 -tTi /dev/hda  

/dev/hda:
 setting 32-bit IO_support flag to 3
 setting multcount to 16
 setting using_dma to 1 (on)
 setting drive write-caching to 1 (on)
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 using_dma    =  1 (on)

 Model=ST340015A, FwRev=3.01, SerialNo=5LAJS1TX
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 * signifies the current active mode

 Timing cached reads:   3936 MB in  1.99 seconds = 1973.79 MB/sec
 Timing buffered disk reads:  130 MB in  3.03 seconds =  42.97 MB/sec
ファイルシステム

RAIDボリュームは 標準的な ext3 に初期化した。

# dumpe2fs -h /dev/md0
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   
Last mounted on:          
Filesystem UUID:          8ba1a4a7-9a35-4a2a-994b-721745dbdb8b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              19546112
Block count:              39081472
Reserved block count:     1954073
Free blocks:              38419937
Free inodes:              19546101
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Thu Sep 28 22:43:21 2006
Last mount time:          Thu Sep 28 22:45:13 2006
Last write time:          Thu Sep 28 22:45:13 2006
Mount count:              1
Maximum mount count:      25
Last checked:             Thu Sep 28 22:43:21 2006
Check interval:           15552000 (6 months)
Next check after:         Tue Mar 27 22:43:21 2007
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      9b620d96-95a0-48e6-9336-5d9cb21f847f
Journal backup:           inode blocks
Journal size:             128M
測定コマンド

bonnie については、下記のコマンドを使用(/mntに対象ボリュームをマウント)。

# bonnie -u root -d /mnt -n 0 -f -b

結果

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
430MCP
md-raid0(1u)     1G           37910   8 18697   3           47355   4 164.6   0
md-raid0(2u-2ch) 1G           75550  18 30762   6           85096   8 260.1   0
md-raid0(2u-1ch) 1G           32792   8 13865   2           28791   2 171.0   0
md-raid0(3u)     1G           51519  14 19736   4           42076   4 248.8   0
md-raid0(4u)     1G           78513  20 25605   5           50256   4 287.6   0
md-linear(4u)    1G           37635   8 18120   3           47276   4 168.8   0
blog20060927-RAID0-430MCP

  1. 2units(2channel)で明らかなRAID0性能向上の傾向がread/writeともに見られる。3units/4unitsは、RAID0性能向上の傾向が見られるが、2units(2channel)よりは性能向上は劣っている。
  2. 実際の2units(1channel)の性能は1unit比べてやはり劣化がある。

ほとんどITE8212/pass through mode の挙動と同じである。若干、3units/4units での性能向上が見られる。 やはり、IDEの1チャンネルに2台ぶらさがる事が並列化を妨げ「劣化」させる要因になっているようである。

結論

PATAでは1チャンネルに複数のデバイスをぶら下げるとRAIDの性能向上を妨げるので、1チャンネル1台にしよう。

2006年9月25日

ディスクIO性能(8) - ITE8212上でのRAID0の性能

IO-DATA UIDE-133R(ITE8212) に4台のHDDを繋いで幾つかのベンチマークを取ってみた。

環境

毎度のこと検証環境は、

  1. Athlon64X2 3800+ (但し、Single CPUとして制限)
  2. M2NPV-VM(GeForce6150+nForce 430MCP)
  3. メモリは512M(カーネルパラメータで制限)
  4. システム用のHDDで Segate ST3500630AS, SATA
  5. Debian/etch Linux-2.6.16
  6. IO-DATA UIDE-133R(ITE8212)
  7. Seagate ST340015A, 40GB, PATA UDMA100, 2MBキャッシュ, 5400 rpm の4台

ITE8212は、430MCP配下のPCIバス(32bit/33Mhz)にぶら下がっている。

04:08.0 RAID bus controller: <pci_lookup_name: buffer too small> (rev 11)
        Subsystem: Integrated Technology Express, Inc. IT/ITE8212 Dual channel ATA RAID controller
        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 209
        I/O ports at 9c00 [size=8]
        I/O ports at 9800 [size=4]
        I/O ports at 9400 [size=8]
        I/O ports at 9000 [size=4]
        I/O ports at 8c00 [size=16]
        Expansion ROM at fda00000 [disabled] [size=128K]
        Capabilities: [80] Power Management version 2

測定

測定は、pass through mode で md を使ってRAIDを組んだ場合とsmart modeでBIOSでRAIDを定義した場合のそれぞれで下記構成のRAIDボリュームに対して、シーケンシャルなread/write の性能を 、bonnie++(1.03)を使い測定する。

  1. RAID0 のHDDx1台(1u)。
  2. RAID0 のHDDx 2 台(2u-2ch)。但し、IDEの2チャンネルにそれぞれにHDDを割り当てる。
  3. RAID0 のHDDx 2 台(2u-1ch)。但し、IDEの1チャンネルのみにHDDを割り当てる。
  4. RAID0 のHDDx 3 台(3u)。IDEの片方のチャンネルに2台で一方に1台を割り当てる。
  5. RAID0 のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。
  6. linear のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。

HDDの設定

HDDの設定は hdparm を使っても多く設定が出来ないので、デフォルト値のままにした。

# hdparm  /dev/hda

/dev/hda:
 multcount    =  0 (off)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 19462/255/63, sectors = 312661432, start = 0
# hdparm  -i /dev/hda

/dev/hda:

 Model=Integrated Technology Express Inc, FwRev=, SerialNo=%
 Config={ }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=268435455
 IORDY=no
 PIO modes:  pio0
 DMA modes:  mdma0 mdma1 mdma2
 AdvancedPM=no

 * signifies the current active mode
ファイルシステム

RAIDボリュームは 標準的な ext3 に初期化した。

# dumpe2fs -h /dev/hda1
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          a0060cd1-078c-4212-bc49-849077c18012
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              19546112
Block count:              39082120
Reserved block count:     1954106
Free blocks:              38420585
Free inodes:              19546101
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Fri Sep 22 03:17:52 2006
Last mount time:          Fri Sep 22 03:19:57 2006
Last write time:          Fri Sep 22 03:31:15 2006
Mount count:              1
Maximum mount count:      33
Last checked:             Fri Sep 22 03:17:52 2006
Check interval:           15552000 (6 months)
Next check after:         Wed Mar 21 03:17:52 2007
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      e5fb4626-6e46-4fc3-b806-e372ee6acf41
Journal backup:           inode blocks
Journal size:             128M
測定コマンド

bonnie については、下記のコマンドを使用(/mntに対象ボリュームをマウント)。

# bonnie -u root -d /mnt -n 0 -f -b

結果


Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
IT8212
md-raid0(1u)     1G           37720   9 18515   4           47306   4 174.0   0
md-raid0(2u-2ch) 1G           75696  21 30213   6           69912   6 261.6   0
md-raid0(2u-1ch) 1G           33420   8 14207   3           28919   2 170.7   0
md-raid0(3u)     1G           46685  12 19849   4           42009   3 249.1   0
md-raid0(4u)     1G           64778  15 25630   5           52087   5 280.2   0
md-linear(4u)    1G           37966   8 18337   4           47288   4 171.8   0
bios-raid0(2u-2ch)1G          60544  18 17886   4           36314   3 169.3   0
bios-raid0(2u-1ch)1G          36289  10 13280   3           30567   2 155.3   0
bios-raid0(3u)   1G           32204   9 15470   3           37817   3 164.9   0
bios-raid0(4u)   1G           39150  11 17373   4           42017   3 183.9   0
bios-linear(4u)  1G           38601  10 18587   4           47329   4 170.2   0
blog20060925-RAID0-IT8212

  1. mdの場合、2units(2channel)で明らかなRAID0性能向上の傾向がread/writeともに見られる。3units/4unitsは、RAID0性能向上の傾向が見られるが、2units(2channel)よりは性能向上は劣っている。
  2. md と smart modeのRAIDを比べると、md を使った方が性能が良い。
  3. 実際の2units(1channel)の性能は1unit比べてやはり劣化がある。

全体的にHDDの台数に性能があまりスケールしない。ただし、IDEの1チャンネルに1台のみぶら下がるようにした場合、台数に対する性能向上が見られる。やはり、IDEの1チャンネルに2台ぶらさがる事が、IDEバスかチップかLinuxのITE8212用のドライバかで並列化を妨げ「劣化」させる要因になっているようである。

結論

PATAでは1チャンネルに複数のデバイスをぶら下げるとRAIDの性能向上を妨げるので、1チャンネル1台にしよう。 姑息に性能を上げるためには、pass through mode で md ベースのRAIDを組もう。但し、過度の期待は禁物である。

2006年9月22日

ディスクIO性能(7) - ITE8212 のRAID機能を探る

最近(2006/9)でPATA RAID でまだ入手できるのはITEのチップが載っているものぐらいで、時たま OnBoard で採用されていたりする。ただ、ITE自体はストレージ系のチップはITE8211/ITE8212 のみなので、企業が存続する限りほそぼそと製品が出荷されるのかなぁ。。。

公開されている大まかなチップ仕様書を見る限り、仮想IDE?やRAIDの再構築等を内部の組み込みCPUで実現できたり、結構HardwareRAIDっぽい。ただし、キャッシュがほとんど無いので性能は見るべき物では無さそうである。

ベンダーからLinux 2.4/2.6用の専用ドライバが配布されている。また 2.6.x では別のドライバがkernel本体に取り込まれている。

  • Linux 2.4 系では ITE配布ドライバ
  • Linux 2.6 系では ITE配布ドライバ or it821x(kernel本体のドライバ)
kernel本体に取り込まれてる it821xを使うのが吉かと思う。

it821xを使う

it821x(kernel本体のドライバ)は smart mode/pass through mode の二種類の動作モードをもつ。

smart mode の時はRAIDボリュームは単体のデバイスとしてアクセスできる。 ちなみに dmraid でのサポートはない、というか Hardware RAIDだから、、、。

IT8212: IDE controller at PCI slot 0000:04:08.0
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt 0000:04:08.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 209
IT8212: chipset revision 17
it821x: controller in smart mode.
IT8212: 100% native mode on irq 209
    ide0: BM-DMA at 0x8c00-0x8c07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x8c08-0x8c0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: Integrated Technology Express Inc, ATA DISK drive
hda: IT8212 RAID 3 volume(64K stripe).
ide0 at 0x9c00-0x9c07,0x9802 on irq 209
hda: max request size: 128KiB
hda: 312661432 sectors (160082 MB), CHS=19462/255/63
hda: cache flushes not supported
 hda: hda1

pass through mode ではRAIDボリュームが定義されていても個々のIDEディスクとしてアクセスできる。この場合はモジュールパラメータに noraid=1を指定する。

IT8212: IDE controller at PCI slot 0000:04:08.0
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt 0000:04:08.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 209
IT8212: chipset revision 17
it8212: forcing bypass mode.
it821x: controller in pass through mode.
IT8212: 100% native mode on irq 209
    ide0: BM-DMA at 0x8c00-0x8c07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x8c08-0x8c0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: ST340015A, ATA DISK drive
hdb: ST340015A, ATA DISK drive
ide0 at 0x9c00-0x9c07,0x9802 on irq 209
Probing IDE interface ide1...
hdc: ST340015A, ATA DISK drive
hdd: ST340015A, ATA DISK drive
ide1 at 0x9400-0x9407,0x9002 on irq 209
hda: max request size: 128KiB
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1
hdb: max request size: 128KiB
hdb: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdb: cache flushes supported
 hdb: hdb1
hdc: max request size: 128KiB
hdc: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdc: cache flushes supported
 hdc: hdc1
hdd: max request size: 128KiB
hdd: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdd: cache flushes supported
 hdd: hdd1

smart mode 時にRAIDボリュームに組み込まれていないディスクは単体ディスクとして認識される様であるが、時折発狂するのが見受けられた。

結論

RAIDボリュームと単体ディスクの組み合わせで使わない限り smart mode は安定している。 pass through mode を使えば単なるIDEインタフェースとして普通に使える。何か拍子抜け。

2006年9月21日

ディスクIO性能(6) - PDC20270上でのRAID0の性能

FastTrack100 TX2 (PDC20270) に4台のHDDを繋いで幾つかのベンチマークを取ってみた。

環境

毎度のこと検証環境は、

  1. Athlon64X2 3800+ (但し、Single CPUとして制限)
  2. M2NPV-VM(GeForce6150+nForce 430MCP)
  3. メモリは512M(カーネルパラメータで制限)
  4. システム用のHDDで Segate ST3500630AS, SATA
  5. Debian/etch Linux-2.6.16
  6. FastTrack100 TX2 (PDC20270)
  7. Seagate ST340015A, 40GB, PATA UDMA100, 2MBキャッシュ, 5400 rpm の4台

PDC20270は、430MCP配下のPCIバス(32bit/33Mhz)にぶら下がっている。

# lspci -s 04:09.0 -v
04:09.0 RAID bus controller: Promise Technology, Inc. PDC20270 (FastTrak100 LP/TX2/TX4) (rev 02) (prog-if 85)
        Subsystem: Promise Technology, Inc. FastTrak100 TX2
        Flags: bus master, 66MHz, slow devsel, latency 32, IRQ 209
        I/O ports at 9c00 [size=8]
        I/O ports at 9800 [size=4]
        I/O ports at 9400 [size=8]
        I/O ports at 9000 [size=4]
        I/O ports at 8c00 [size=16]
        Memory at fdbf0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fda00000 [size=64K]
        Capabilities: [60] Power Management version 1
でも、lspci の出力のFlags に 66Mhz とあるがこれは何を意味するのだろう?

測定

測定は、md と dmraid のそれぞれで下記構成のRAIDボリュームに対して、シーケンシャルなread/write の性能を 、bonnie++(1.03)を使い測定する。

  1. RAID0 のHDDx1台(1u)。
  2. RAID0 のHDDx 2 台(2u-2ch)。但し、IDEの2チャンネルにそれぞれにHDDを割り当てる。
  3. RAID0 のHDDx 2 台(2u-1ch)。但し、IDEの1チャンネルのみにHDDを割り当てる。
  4. RAID0 のHDDx 3 台(3u)。IDEの片方のチャンネルに2台で一方に1台を割り当てる。
  5. RAID0 のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。
  6. linear のHDDx 4 台(4u)。IDEの両方のチャンネルに2台を割り当てる。

HDDの設定

4台のHDDは hdparm を使い、下記の様に設定。

# hdparm -d 1 -c 3 -m 16 -W 1 -tTi /dev/hde

/dev/hde:
 setting 32-bit IO_support flag to 3
 setting multcount to 16
 setting using_dma to 1 (on)
 setting drive write-caching to 1 (on)
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 using_dma    =  1 (on)

 Model=ST340015A, FwRev=3.01, SerialNo=5LAJRH73
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 * signifies the current active mode

 Timing cached reads:   3836 MB in  2.00 seconds = 1922.01 MB/sec
 Timing buffered disk reads:  130 MB in  3.03 seconds =  42.87 MB/sec

ファイルシステム

RAIDボリュームは 標準的な ext3 に初期化した。

# dumpe2fs -h /dev/md0
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          568932f0-35b2-4279-b3b9-b99195504002
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              19546112
Block count:              39078016
Reserved block count:     1953900
Free blocks:              38416481
Free inodes:              19546101
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Wed Sep 20 12:44:07 2006
Last mount time:          Wed Sep 20 12:46:16 2006
Last write time:          Wed Sep 20 12:46:16 2006
Mount count:              1
Maximum mount count:      20
Last checked:             Wed Sep 20 12:44:07 2006
Check interval:           15552000 (6 months)
Next check after:         Mon Mar 19 12:44:07 2007
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      d2636c25-d719-4b86-919b-5f4fe97ff8ec
Journal backup:           inode blocks
Journal size:             128M

測定コマンド

bonnie については、下記のコマンドを使用(/mntに対象ボリュームをマウント)。

# bonnie -u root -d /mnt -n 0 -f -b

結果

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
PDC20270
md-raid0(1u)     1G           37924   8 18322   4           47218   4 169.1   0
md-raid0(2u-2ch) 1G           48279  11 26484   5           79672   7 267.5   0
md-raid0(2u-1ch) 1G           32114   8 13687   2           28586   2 166.0   0
md-raid0(3u)     1G           39956  11 18437   4           41578   3 249.1   0
md-raid0(4u)     1G           49674  11 23152   5           50915   4 285.8   0
md-linear(4u)    1G           38235   8 18221   3           47197   4 169.6   0

dm-raid0(1u) 1G 38826 12 18584 4 47295 3 174.2 0 dm-raid0(2u-2ch) 1G 52870 17 22017 5 55090 5 264.0 0 dm-raid0(2u-1ch) 1G 34679 10 12061 2 24026 2 168.0 0 dm-raid0(3u) 1G 42278 13 17619 3 40336 4 249.5 0 dm-raid0(4u) 1G 51228 18 22073 5 50590 5 286.2 0 dm-linear(4u) 1G 38215 11 18678 4 47264 4 171.1 0

blog20060921-RAID0-PDC20270

  1. mdの場合、1unit に比べてRAID0性能向上の傾向が見られるのは 2units(2channel)の readのみで、それ以外は何かの制限がありそうである。
  2. md と dmraid の傾向の違いは、2units(2channel)のread以外は無い。
  3. 2units(2channel)のwriteの性能向上が思ったほど無い。
  4. IDEの1channelに2台ぶら下げると性能向上は望めないと言われているが、 実際の2units(1channel)の性能劣化は予想以上である。
  5. 4unitsは、2units(1channel) からRAID0の性能向上の傾向が見られる。
  6. 単体HDDとraid0(4units)とlinear(4units)の性能がほぼ変わらない。

全体的にHDDの台数に性能がスケールしていない。PCIバスの制約は 133MB/secであり、 約80MB/secの性能が出る場合もあり、PCIバスに制限されているのでは無さそうである。 単純に考えると、IDEの1チャンネルに2台ぶらさがる事が、IDEバスかチップかLinuxのPDC20270用ドライバかで並列化を妨げ「劣化」させる要因になっているようである。

なんとも納得がいかない結果だなぁ。

ベンダー提供のドライバとの比較も必要かも。。。PATAでそこまでするかなぁ。

結論

PATAでは1チャンネルに複数のデバイスをぶら下げるとRAIDの性能向上を妨げるので、1チャンネル1台にしよう。 mdもdmraidも大きな違いが無いが、このRAIDカードではシーケンシャルなreadの性能はmdの方が高かった。PCI(32bit/33Mhz)でぶら下がる RAIDカードに過度に期待しないでおこう。

シーケンシャルI/OだけでなくランダムI/Oの性能評価が出来るようになろう。

2006年9月19日

ディスクIO性能(5) - PDC20270 のRAID機能(dmraid)を探る(3)

dmraid でサポートされるRAIDボリュームはルートファイルシステムに使えないかと思っていた。 dmraid の新しめの版でinitramfs-tools用のフックスクリプトが取り込まれており、dmraidをサポートした initrd イメージが作成できるので、ルートファイルシステムに使えるようである。また debian-installer 用のバイナリパッケージがあるようなので、d-i でさっくり使えるかもしれない(試して無いが、、、)。

ただ物は試しに、インストール済みのファイルイメージをdump/restore して dmraid上のRAIDボリュームに移してみたが普通に使える。

Debian/etchが出た暁には最強に環境になるんだろうなあぁ。

そう言えば、RAIDを組んだDISKの組のことを何て言えば良いのだろう? RAIDボリューム?RAIDアレイ?RAIDセット?ふぅ〜む。

2006年9月5日

ディスクIO性能(4) - PDC20270 のRAID機能(dmraid)を探る(2)

FastTrack100 TX2 (PDC20270)のBIOS画面で RAID Array を定義すると、grubの様なブートローダから一つのディスクとしてアクセスできる。この機能はRAID上のBIOSで提供され、ディスクに障害が発生しても異常停止することなく起動出来るらしい。RAID1 or RAID10などの障害復旧のときの再構築の機能も大抵ある。

そんな素敵な機能を無視して、単体HDDとして扱うために1台のみLinear Arrayとして定義して使うとき気をつけなければいけないことは何だろうか?

RAIDセットの情報は何処?

何か元ディスクのCHSが違うけどどうすればいいの?

マニュアルにはどこにも書いていないが、隠れソフトウェアRAIDのmetadataはディスクの最後尾ほどに書かれている。特にPromise の RAID では最終トラックの最初のセクタ(大抵最後から63セクタ前)にあるらしい。

これを確かめるには、元HDDのセクタ数とdmraidで認識される単体HDDのセクタ数の差を比較すれば良く。

# hdparm -g /dev/hdf
/dev/hdf:
 geometry     = 65535/16/63, sectors = 78165360, start = 0
# dmraid -r /dev/hdf
/dev/hdf: pdc, "pdc_dhgiffaf", linear, ok, 78165297 sectors, data@ 0
# expr 78165360 - 78165297
63

dmraid 経由で扱う場合は気をつける必要は無いのだが、 RAID metadata を踏まない様にパーテションを切る必要がある。

次に、RAIDセットのCHS情報は、元になった単体HDDとは異なる。 正しくはRAIDセットのCHS情報に基づいて、パーテション情報を書かなければならない。

昔ディスクのCHS情報は重要なものだったが、いまはLBA/LBA48なりを拡張INT13Hでアクセスするのが定石らしく、パーテションテーブルには、CHSベースとLBAベースの両方の値がかかれている(参考ディスク情報パーテションテーブル)。

ディスクアクセスにCHSを使うのはDOSか古いブートローダぐらいなので、元になった単体HDDのCHSベースでパーテションを切っても問題無いかと思う(違うかも)。

ただ安全を考えると、dmraid で有効かされたディスクに対して fdisk を実行してパーテションを切った方がよい。その場合、自動的にRAID metadataを外すように割り当ててくれるので、一石二鳥である。

結論

単体HDDとして扱うために1台のみLinear Arrayとして定義して使うときのパーテション切りは、dmraid経由に使わない場合でも、一度 dmraid で有効化させたRAIDセットに対して fdisk を実行しよう。

但し、RAID機能を無効に出来るならばそっちを使おう。

2006年9月1日

ディスクIO性能(3) - PDC20270 のRAID機能(dmraid)を探る(1)

昔 Promise technology とはLinux界隈では物騒な話があった。そのためか IDE controller が本来の性能が出せなかった時期が長かった。また、Promise社はATA RAIDの雄で良くオンボードRAIDチップとして乗っていた。HardwareRAIDとして売られているが、OSドライバとカード上のBIOSが、RAID機能の100パーセントを提供するHardwareRAIDもどきなので、ベンダーからLinux用の専用ドライバを組み込まないといけない。これが面倒であった。

ただし、オープンソースでのRAIDドライバは開発は進んでおり

  • Linux 2.4 系では ataraid
  • Linux 2.6 系では dmraid
が使える。但し、dmraid は比較的新しいのでディストリビューション側でまだinitrdに組み込まれていないので、ルートファイルシステムに使いたい場合は、手動でなんとかしなければいけないようだ。

dmraid を試す

Debian etch に dmraid 1.0.0 rc9 が含まれるので手軽に試してみよう。

  • ASUS M2NPV-VM
  • Athlon64X2 3800+
  • CD1G-D2U667/ELP (但し、DDR2-533で運用)
  • FastTrack100 TX2 (PDC20270)
  • Seagate ST340015A, 40GB, PATA UDMA100, 2MBキャッシュ, 5400 rpm

RAID0のテスト

  1. カードのBIOS設定(FastBuild Utility)にて 4台HDDの Stripe Array を定義する。
  2. 別HDDにインストール済み Debian/Linux etch システムを起動する。 下記のようにRAIDカードとHDDが認識されているのを確認する
    # dmesg
    ...
    PDC20270: IDE controller at PCI slot 0000:04:09.0
    ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
    ACPI: PCI Interrupt 0000:04:09.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 209
    PDC20270: chipset revision 2
    PDC20270: ROM enabled at 0xfda00000
    PDC20270: 100% native mode on irq 209
        ide2: BM-DMA at 0x8c00-0x8c07, BIOS settings: hde:pio, hdf:pio
        ide3: BM-DMA at 0x8c08-0x8c0f, BIOS settings: hdg:pio, hdh:pio
    ...
    Probing IDE interface ide2...
    hde: ST340015A, ATA DISK drive
    hdf: ST340015A, ATA DISK drive
    ide2 at 0x9c00-0x9c07,0x9802 on irq 209
    Probing IDE interface ide3...
    hdg: ST340015A, ATA DISK drive
    hdh: ST340015A, ATA DISK drive
    ide3 at 0x9400-0x9407,0x9002 on irq 209
    ...
    hde: max request size: 128KiB
    hde: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
    hde: cache flushes supported
     hde: unknown partition table
    hdf: max request size: 128KiB
    hdf: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
    hdf: cache flushes supported
     hdf: unknown partition table
    hdg: max request size: 128KiB
    hdg: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
    hdg: cache flushes supported
     hdg: unknown partition table
    hdh: max request size: 128KiB
    hdh: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
    hdh: cache flushes supported
     hdh: unknown partition table
    ...
  3. dmraidをインストール
    # apt-get install dmraid
  4. RAIDセットとデバイスを確認する。
    # dmraid -s
    *** Set
    name   : pdc_gddhfeaj
    size   : 312660992
    stride : 128
    type   : stripe
    status : ok
    subsets: 0
    devs   : 4
    spares : 0
    # dmraid -r
    /dev/hde: pdc, "pdc_gddhfeaj", stripe, ok, 78165248 sectors, data@ 0
    /dev/hdf: pdc, "pdc_gddhfeaj", stripe, ok, 78165248 sectors, data@ 0
    /dev/hdg: pdc, "pdc_gddhfeaj", stripe, ok, 78165248 sectors, data@ 0
    /dev/hdh: pdc, "pdc_gddhfeaj", stripe, ok, 78165248 sectors, data@ 0
  5. RAIDセットの有効化
    # dmraid -a yes -v
    INFO: Activating stripe RAID set "pdc_gddhfeaj"
    これでRAIDセット /dev/mapper/pdc_gddhfeaj として1つのブロックデバイスに見えるようになる。
  6. fdisk でパーティションを切る。パーティションを再認識させるためには、該当RAIDセットの無効化&有効化を行う。
    # fdisk /dev/mapper/pdc_gddhfeaj
    ...
    # /etc/init.d/dmraid restart
    Shutting down DMRAID devices... RAID set "pdc_gddhfeaj1" is not active
    INFO: Deactivating partition RAID set "pdc_gddhfeaj1"
    INFO: Deactivating stripe RAID set "pdc_gddhfeaj"
    .
    Setting up DMRAID devices...INFO: Activating stripe RAID set "pdc_gddhfeaj"
    INFO: Activating partition RAID set "pdc_gddhfeaj1"
    .
  7. ファイルシステムを作る。
    # mkfs.ext3 -E stride=16 /dev/mapper/pdc_gddhfeaj1
    ext3 では、RAIDセットのchunk sizeをファイルシステムのブロック単位で指定すると、少し適した配置をしてくれる。
  8. 再起動を行い問題なく立ち上がるか確認する。

再起動後に、下記のようなメッセージが出る場合は運用は諦めよう!似たようなバグ報告があるのでそのうち直るかも。

hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hde: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=156393776, sector=156328497
ide: failed opcode was: unknown
PDC202XX: Primary channel reset.
ide2: reset: success
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hde: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=156393776, sector=156328497
ide: failed opcode was: unknown
end_request: I/O error, dev hde, sector 156328497
上記は実際、2台のRAID0を構築したときに発生した。単体HDDより大きなサイズのパーティションを作成した場合のみ起き、上記のエラーログが延々出力され、起動が完了しない(shellも使えない)。運良く KNOPPIX 5 だとエラーを吐きながらも起動が完了するので、fdisk等でパーティションを書き換えることができた。4台では起きないのでかなりレアな条件が重なるとエラーになるっぽいなぁ。

RAID1のテスト

  1. カードのBIOS設定(FastBuild Utility)にて 2台HDDの Mirror Array を定義する。
  2. あとはRAID0と変わらない
    
    # dmraid -s
    *** Active Set
    name   : pdc_gdijjjaf
    size   : 78165248
    stride : 128
    type   : mirror
    status : ok
    subsets: 0
    devs   : 2
    spares : 0
    # dmraid -a yes -v
    INFO: Activating mirror RAID set "pdc_gdijjjaf"
    # fdisk /dev/mapper/pdc_gdijjjaf
    ...
    # /etc/init.d/dmraid restart
    ...
    # mkfs.ext3 /dev/mapper/pdc_gdijjaf1
    
RAIDセットと元の単体HDDの総セクター数は、RAIDセットの方が必ず小さくなるのでRAID0であったような起動時の異常は起きそうにはない。

結論

安全を考えるとまだdmraidの安定運用はRAID1以外では期待できないのだろうなぁ。運が良ければ、RAID0/RAID10/RAID5が運用できそうだなぁ。

久しぶりの投稿

かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...