読者です 読者をやめる 読者になる 読者になる

部屋を掃除したら漫画が沢山出てきたので書く日記

漫画とか合唱とかUNIXとかLinuxとかについて書く日記です。

OpenSolaris 2009.06でWD*EARS(WD15EARS)を使用する その3

その2の続きです。

だいぶ時間が経ちましたが、前回からさらに調べて判った事を書きます。

1.前回対策の問題点

前回の結論としては、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番は

「代替ディスクブロック用に予約された領域であり、代替セクタースライスと呼ばれる。」

という事で、通常のデータを格納する用途には使われていないためのように思われます。
ただ、やはり普通の状態ではないので、違う方法を考えたいものです。

2.新たな対策

そこで、上述の通り「Rsect」を足した分、「Numsect」は5減らすというやり方でやってみることにしました。「Rsect」を5足して「48200」とするなら、「Numsect」は5引いて「2930207800」にします。こうするとスライス9番は消えませんでした。ただし、性能も向上しませんでした。

そこで、今度は

  1. 一つ「Rsect」を足す、かつ「Numsect」を減らすようにfdiskによるパーティション変更実施
  2. zpoolでデバイス作成
  3. sambaでWindowsからマウントして「CrystalDiskMark」でパフォーマンス測定
  4. 一旦アンマウント
  5. 一つ「Rsect」を足す、かつ「Numsect」を減らすようにfdiskによるパーティション変更実施
  6. 以下繰り返し

という手順で気長に確認してみました。

結果は

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個毎の周期ではあるようです。

3.新しい対策の効果

前回も書きましたが、対策をしない状態での結果は以下の通りです。

-----------------------------------------------------------------------
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]
だったので、より性能が向上しているとは思います。

4.考察

ただ、しばらく使っていましたが性能劣化の影響を受けないはずのRead(データ読み込み)処理も結構遅いです・・・。そもそもあまり速くないDISKなのではないか、と思い始めています。
あと、こんな面倒くさい事をしないといけないHDDは、そもそも使わない方が良いなあと思います。秋葉原で安く売っているのには訳がある、と思わずにはいられません。
性能を考えなくて良い、バックアップ用途などなら安くて良いかもしれませんが・・・。
SolarisでこのHDDを使う、という人が日本(世界で、でも良いが)にどれくらいいるものなのか判りませんが、興味があればこれらの方法を試してみたらいかがでしょうか。また、より良い方法がありましたら是非、教えていただければと思います。

ではー。

*1:開始セクタを1としたら8の倍数だから?そうすると前回の対策は何故有効そうだったのか?謎だ・・・。