OpenSolaris 2009.06でWD*EARS(WD15EARS)を使用する その３
その２の続きです。
だいぶ時間が経ちましたが、前回からさらに調べて判った事を書きます。
１．前回対策の問題点
前回の結論としては、Solarisのfdiskコマンドにて参照できる情報のうち「Rsect」を8の倍数にする、というものです。具体的には
# fdisk -W - c8d0p0
実行結果が
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect 191 128 0 1 3 254 63 1023 48195 2930207805
となっていたのを
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect 191 128 0 6 3 254 63 1023 48200 2930207805
となるように変更する、というものでした。
ただ、ここで見落としがありました。「Numsect」という、パーティションが使用可能なセクタ数の値を変更していなかったので、
「Rsect」を5足した分、「Numsect」は5減らして「2930207800」とするべきだったのでは？
という事です。
実際、当時の作業ログを見直すと、
root@tpc5160:~# fdisk -F test.txt c8d0s2
WARNING: Device /dev/rdsk/c8d0s2:
The device does not appear to include absolute
sector 0 of the PHYSICAL disk (the normal location for an fdisk table).
Fdisk is normally used with the device that represents the entire fixed disk.
(For example, /dev/rdsk/c0d0p0 on x86 or /dev/rdsk/c0t5d0s2 on sparc).
Are you sure you want to continue? (y/n) y
Warning: only -1 bytes written to clear backup VTOC at block 2930255817!
Warning: only -1 bytes written to clear backup VTOC at block 2930255819!
Warning: only -1 bytes written to clear backup VTOC at block 2930255821!
Warning: only -1 bytes written to clear backup VTOC at block 2930255823!
Warning: only -1 bytes written to clear backup VTOC at block 2930255825!というように、「Warning: only -1 bytes written to clear backup VTOC」というやばげなメッセージが出ていました。
さらに、前回の手順実施済みのDISKに対してprtvtocコマンドでパーティション情報(Solaris用語で言うところの『スライス』)を確認すると、
$ pfexec prtvtoc /dev/rdsk/c7d0s0
* /dev/rdsk/c7d0s0 partition map
*
* Dimensions:
* 512 bytes/sector
* 189 sectors/track
* 255 tracks/cylinder
* 48195 sectors/cylinder
* 60799 cylinders
* 60797 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* Unallocated space:
* First Sector Last
* Sector Count Sector
* 0 48195 48194
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 48195 2930063220 2930111414
2 5 01 0 2930111415 2930111414
8 1 01 0 48195 48194となっており、スライスは0、2、8の三つが存在する事がわかります。
対策実施前のDISKは
$ pfexec prtvtoc /dev/rdsk/c8d0s2
〜中略〜
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 144585 2929918635 2930063219
2 5 01 0 2930063220 2930063219
8 1 01 0 48195 48194
9 9 00 48195 96390 144584という事でスライスは0、2、8、9の四つが存在します。
つまり、前回の対策ではスライス9番がなくなってしまったという事です・・・。
ただ、それでも特に問題なくOSインストールできて動いているのでした。
Sunのサイト(今はOracleだけど)
http://docs.sun.com/app/docs/doc/805-5854/6j5h9ja1e?l=ja&a=view
を参照すると、スライス9番は
「代替ディスクブロック用に予約された領域であり、代替セクタースライスと呼ばれる。」
という事で、通常のデータを格納する用途には使われていないためのように思われます。
ただ、やはり普通の状態ではないので、違う方法を考えたいものです。
２．新たな対策
そこで、上述の通り「Rsect」を足した分、「Numsect」は5減らすというやり方でやってみることにしました。「Rsect」を5足して「48200」とするなら、「Numsect」は5引いて「2930207800」にします。こうするとスライス9番は消えませんでした。ただし、性能も向上しませんでした。
そこで、今度は
- 一つ「Rsect」を足す、かつ「Numsect」を減らすようにfdiskによるパーティション変更実施
- zpoolでデバイス作成
- sambaでWindowsからマウントして「CrystalDiskMark」でパフォーマンス測定
- 一旦アンマウント
- 一つ「Rsect」を足す、かつ「Numsect」を減らすようにfdiskによるパーティション変更実施
- 以下繰り返し
という手順で気長に確認してみました。
結果は
Rsect：48199、 Numsect：2930207801の場合
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect 191 128 0 5 3 254 63 1023 48199 2930207801
および、
Rsect：48207、 Numsect：2930207793の場合
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect 191 128 0 13 3 254 63 1023 48207 2930207793
にRandom Write 4KB (QD=1)の数値の向上が見られる
というものでした。原理は不明*1ですがセクタ8個毎の周期ではあるようです。
３．新しい対策の効果
前回も書きましたが、対策をしない状態での結果は以下の通りです。
-----------------------------------------------------------------------
CrystalDiskMark 3.0 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 9.989 MB/s
Sequential Write : 11.525 MB/s
Random Read 512KB : 9.950 MB/s
Random Write 512KB : 11.612 MB/s
Random Read 4KB (QD=1) : 3.258 MB/s [ 795.5 IOPS]
Random Write 4KB (QD=1) : 0.376 MB/s [ 91.9 IOPS]
Random Read 4KB (QD=32) : 11.626 MB/s [ 2838.5 IOPS]
Random Write 4KB (QD=32) : 1.405 MB/s [ 343.1 IOPS]
Test : 1000 MB [Y: 7.9% (104.0/1320.8 GB)] (x5)
Date : 2010/08/30 12:06:20
OS : Windows XP Professional SP3 [5.1 Build 2600] (x86)
今回の対策を行った場合の結果は以下の通りです。
■Rsect：48199、 Numsect：2930207801の場合
-----------------------------------------------------------------------
CrystalDiskMark 3.0 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 9.626 MB/s
Sequential Write : 11.677 MB/s
Random Read 512KB : 10.159 MB/s
Random Write 512KB : 11.618 MB/s
Random Read 4KB (QD=1) : 3.268 MB/s [ 797.9 IOPS]
Random Write 4KB (QD=1) : 3.736 MB/s [ 912.1 IOPS]
Random Read 4KB (QD=32) : 11.633 MB/s [ 2840.1 IOPS]
Random Write 4KB (QD=32) : 2.179 MB/s [ 531.9 IOPS]
Test : 1000 MB [Y: 8.2% (108.5/1320.7 GB)] (x5)
Date : 2010/09/03 13:34:31
OS : Windows XP Professional SP3 [5.1 Build 2600] (x86)
■Rsect：48207、 Numsect：2930207793の場合
-----------------------------------------------------------------------
CrystalDiskMark 3.0 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 9.897 MB/s
Sequential Write : 11.664 MB/s
Random Read 512KB : 9.990 MB/s
Random Write 512KB : 11.601 MB/s
Random Read 4KB (QD=1) : 3.198 MB/s [ 780.7 IOPS]
Random Write 4KB (QD=1) : 3.621 MB/s [ 884.1 IOPS]
Random Read 4KB (QD=32) : 11.487 MB/s [ 2804.6 IOPS]
Random Write 4KB (QD=32) : 2.020 MB/s [ 493.1 IOPS]
Test : 1000 MB [Y: 8.2% (108.5/1320.8 GB)] (x5)
Date : 2010/09/07 16:21:18
OS : Windows XP Professional SP3 [5.1 Build 2600] (x86)
未対策の場合はRandom Write 4KB (QD=1)が
0.376 MB/s [ 91.9 IOPS]
でした。
対策を実施した場合はこの値が
3.736 MB/s [ 912.1 IOPS]
3.621 MB/s [ 884.1 IOPS]
という事で、約10倍の性能が出ている事になります。
ちなみに前回実施した対策の結果だと、Random Write 4KB (QD=1)が
1.099 MB/s [ 268.4 IOPS]
だったので、より性能が向上しているとは思います。
４．考察
ただ、しばらく使っていましたが性能劣化の影響を受けないはずのRead(データ読み込み)処理も結構遅いです・・・。そもそもあまり速くないDISKなのではないか、と思い始めています。
あと、こんな面倒くさい事をしないといけないHDDは、そもそも使わない方が良いなあと思います。秋葉原で安く売っているのには訳がある、と思わずにはいられません。
性能を考えなくて良い、バックアップ用途などなら安くて良いかもしれませんが・・・。
SolarisでこのHDDを使う、という人が日本(世界で、でも良いが)にどれくらいいるものなのか判りませんが、興味があればこれらの方法を試してみたらいかがでしょうか。また、より良い方法がありましたら是非、教えていただければと思います。
ではー。
*1:開始セクタを1としたら8の倍数だから？そうすると前回の対策は何故有効そうだったのか？謎だ・・・。
