Google Code Prettify

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 ハードウェアのチップの問題?)でサポートされていないので使えないらしい。

削除出来ないファイルって?

ふと気づくと /var/log/weekly.out に変なログが出ていた。

どうも Adobe 製品をアップデートしたときに不正な名前のファイルが出来てしまったようである。

Rebuilding locate database:
find: /Applications/Adobe Illustrator CS2/Legal.localized/Tiếng Việt.html: No such file or directory
find: /Applications/Adobe Photoshop CS2/Legal.localized/Tiếng Việt.html: No such file or directory

"Tiếng Việt.html"ファイルは存在するらしいが、メタ情報にアクセスできないので、No such file らしい。

それは良いのだが Finder でも rm コマンドでも削除が出来ないのは困った(1,2)。

対処方法は 「Disk Utility」 で「ディスクを修復」をすれば、「不正な名前」として検知されて、正しく直される。

但し、Adobe 製品ファイル群は大抵は起動ディスク上にあるので、Apple製品付属インストールDVDなどの別の起動ディスクで立ち上げて Disk Utility を使わなければだめのようである。(シングルユーザモードで立ち上げても良いのかなぁ?)

それにしても不正なファイル名が作れて尚かつ削除操作が不可になるのはいただけない。

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. 等々
まだ、頭の中がごちゃごちゃしてる。

CD-R/DVD-Rに問題なし

Power Mac G5 Quad の付属のSuperDrive で、CD-R/DVD-Rが焼けなくなってしまった。と騒いだが、今日ふと焼いてみると問題なかった。「総容量0バイト」の表記も正しいものらしい。

なんか、「ディスク作成フォルダ」の使い方のミスで、ドツボにはまっていたらしい。。。恥ずかしい。

ディスク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 を比較をしてみたい気がする。

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

久しぶりの投稿

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