2004.08 System update notes
-- 2004年08月のシステム・アップデート・ノート
[→PREV][→NEXT]
[←BACK][↑HOME]
bar
[→ Profile][→ System update notes][→ Computer at random][→ BBS][→ Software library][→ Index page]

このページの記事一覧
2004.08.31 今月のアフターフォロー(2004-08)
2004.08.15 ハードディスクの不良セクタについて
2004.08.08 HDD 4台収納ケース CENTURY グッドフェイスQuat


2004.08.31 今月のアフターフォロー(2004-08)
 まだ残暑は続きそうですが、この夏の暑さはなんとか乗り切れそうです。
 去年の夏(関連記事)は帰省して留守にしている間にサーバが落ちてしまうというトラブルが、今年は大丈夫でした。

 ただ、春先(関連記事-1関連記事-2)に組んだMicro ATXケースのPentium 4マシン(fagot III)は、どうも発熱に関しては弱いようです。

 今のところ普段の使用には不都合はないのですが、LANで大きなファイルの転送を行なうと高確率で飛んでしまいます。LANコントローラ・チップにヒートシンクを付けてみましたが(関連記事-1)、多少の効果はあったみたいですけど、高負荷をかけた状態でLANを使うとやっぱり飛んでしまうようです。

 やっぱりケースが小さいと内部が狭くて空気は流れにくいしケース自体からも多少は放熱するから、ある程度大きいほうが冷却能力は高そうです(ケースが大きいと内部の空気の流れを作るのに協力なファンが必要かもしれませんが)
 問題のMicroATXマシンは、ケース背面に60cm角ファンが2つ付いていて排気能力は十分あるはずなんですが、空気を取り込む吸気能力が弱いような気がします。ケース正面の空気を取り込む口がまったくなく、ドライブ関係のベイも蓋でふさがっています。

 それで、5インチベイの蓋を常にオープンして、取り込み口を作ってやると多少マシになりました。前面の5インチベイは2つありますが一方は未使用でまるまる空いているので、吸気はできているようです。
 ついでにこの部屋では扇風機が動いているので、レイアウトを少し変更して扇風機の風がケース前面から当たるようにしました。
 システムを温度をモニタしても、内部の温度はかなり下がりました。

  この記事へのコメント
コメントはありません。


名前 内容 -9513-を右に入力
 名前は10文字、内容は100文字以内で入力してください(半角の場合は倍の文字数まで)。
 もっと長いコメントや感想は掲示板(BBS)に投稿してください。


2004.08.15 ハードディスクの不良セクタについて
 ハードディスクには不良(欠陥)セクタが発生しても自動的に修復する機能がありますが、どんな具合に動作するのか調べてみました。

 PC雑誌等のハードディスク関連の解説を見ても記録原理のことは説明してあっても、不良セクタに関する処理のことは、あまり見たことありません(不良とか欠陥とか名前のイメージが悪いし、メーカ側はそんな説明はしたくないのはわかるけど)
 SCSIハードディスクについては、不良ブロックを再割り当てするReassin Blocksコマンドや、欠陥位置情報を登録するディフェクト・リストといったパラメータが用意されていて、これらを調べることで不良セクタは交換されることがわかります。しかし、ATA/IDEハードディスクについてははっきりしていませんでした。下記のリンクに示すMicrosoftのサポート技術情報「ディスクに不良ブロックが含まれている場合は…」を見ても、IDEハードディスクにはReassin Blocksのようなコマンドはなく、初期のIDEハードディスクは不良セクタを自動的に交換・修復する機能はなかったようです。
 しかし、最近のIDEハードディスクはSMART(Self-Monitoring Analysis and Reporting Technology)によって、不良セクタや交換されたセクタの情報がわかるようになりました。SMARTはハードディスク内部の信号・情報を監視・分析して故障の発生を予測する技術です。これにより、IDEハードディスクも不良セクタの交換をやっていることがわかります。

リフレッシュ&リアサイン

 注意しなければならないのは、代替セクタが用意されているからといって常に不良セクタが修復できるわけではないという点です。
 SCSIハードディスクのReassin Blocksコマンド等によってOSやユーザが明示的に再割り当てを行なう別ですが、自動的に修復したり再割り当てを行なうには条件があります。これについては、下記のリンク先にあるNewtechのコラム「ハードディスクの大容量化にはRAIDアルゴリズムの強化が必要」が参考になります。
 ハードディスクは読み取りエラーが一度発生しても、何度もリトライ(再度読み取りを試す)します。リトライがある回数を超えて読み取りに成功すると、データが読みにくくなっていると判断してデータを上書きします(リフレッシュ)。上書きしたときに、再度データが読めるかどうか確認(ベリファイ)し、ここでもエラーが発生した場合は不良セクタとして、予備領域への再割り当てを行ないます(リアサイン)。
 これらの処理はハードディスク(のファームウェア)が自動的に行いリフレッシュやリアサインをユーザが意識することはありません。注意深く観察していると、速度低下には気がつくかもしれませんが、OSやアプリにはエラーは通知されません。
 何度リトライしても読み取りに失敗する場合は不良セクタとして残りOSやアプリには読み取りに失敗したことがエラーとして通知されます。
 ユーザが読み取りエラーに気がついたということは、データの回復ができないためにリフレッシュもリアサインも実行できずに、そこに保存したあったデータは消失したということです。
 ユーザにとって大切なのはセクタという格納場所ではなく中身のデータです。たとえデータの回復が出来なくてもデータを消失したことがOSやユーザにわかるようにわざと不良セクタとして残すわけです。

 このような不良セクタはいくら読み取りを繰り返しても成功しない限りいつまでも不良セクタとして残ったままになります。
 ただし、このような不良セクタは読み取りはできなくても書き込みできることがあります
 不良セクタは読み取りに成功しない限りそのまま残ってしまいますが、そこにデータを書き込む場合には、保存してあったデータは必要ないというか、新しいデータで上書きすることになります。このため、書き込みに関してはデータを修復する必要はなく、読めないセクタであっても問題ないわけです。
 また、いったん読み取りに失敗した不良セクタはペンディング・セクタ(未解決で保留されているセクタ)としてハードディスク(のファームウェア)が把握しています。ペンディンクセ・セクタに新たにデータを書き込む場合にはリフレッシュや場合によってはリアサインも行ないます。

 このように読み取り時に解決できなかった不良セクタは書き込み時に修復されます。

ゼロフィルと物理フォーマット

 リフレッシュやリアサインという機能がなかった時代のハードディスクでは、不良セクタを修復するためには、物理フォーマット(ローレベル・フォーマット)を行なう必要がありました。しかし、最近のハードディスクには不良セクタが発生しても自動的に修復できるため、物理フォーマットは必ずしも必要ありません。また最近のハードディスクの物理フォーマットは、全領域を0(ゼロ)で埋めるというゼロフィルに近いというか、ゼロフィルそのものということもあります。
 物理フォーマットの内容や処理方法についてはメーカによって異なると思いますが、リフレッシュやオートリアサインがあれば、いったん読み取りして不良セクタ(ペンディング・セクタ)を調べてからゼロ・フィルすれば修復できます。逆にゼロフィルしてから読み取り(ベリファイ)を行なう方法もあるかと思います。

***

 理屈では不良セクタは交換されるはずだと分かっていても、実際に確認するのはなかなかできませんでした。そうそう都合よく不良セクタは発生してくれないからです(発生しないほうがいいに決まっているし)
 それで、春頃(関連記事)にファイルサーバに使用していたハードディスク(DiamondMax D540X 4G120J6)を交換したときに不良セクタが発生したのを思い出して、それがそのまま状態で眠っていたので調べてみました。
 拙作のDevTestで全領域の読み取り検査をしてみると、リードエラーが5つ発生しています。

 DevTestはソフトウェアライブラリ に登録しています。
  DevTest

■ DevTestでの読み取り検査
C:\>devtest disk1 --surfscan
***** DevTest - Device Benchmark Test Program for Windows NT/2000/XP *****
                                           Version 1.03a edition #03
***** Surface Scan *****

Surface Scan Error! LBA 18453376-18453503 (count 1)      (Remain      51m
Surface Scan Error! LBA 18453479 (count 1)
Surface Scan Error! LBA 120796288-120796415 (count 1)    (Remain      31m
Surface Scan Error! LBA 164100864-164100991 (count 1)    (Remain      21m
Surface Scan Error! LBA 164100878 (count 1)
Surface Scan Error! LBA 164493056-164493183 (count 1)    (Remain      21m
Surface Scan Error! LBA 164493141 (count 1)
Surface Scan Error! LBA 165324160-165324287 (count 1)    (Remain      21m
Surface Scan Error! LBA 165324261 (count 1)
Surface Scan Error! LBA 165339776-165339903 (count 1)    (Remain      37m
Surface Scan Error! LBA 165339865 (count 1)
Read   240074112/240119615( 99.9%)   18677.7kB/s         (Remain          00s
Surface scan completed. (   1h 11m    ) : Error 11

 それで、DevTestを使ってエラーで読めなかった5箇所のセクタにピンポイントで書き込みしてみしまた(公開しているDevTestではこのような書き込みはできません)

■ DevTestでリードエラーの発生した箇所に書き込み
C:\>devtest disk1 --writeBlock  18453479 --count 1 --zeroFill

C:\>devtest disk1 --writeBlock 164100878 --count 1 --zeroFill

C:\>devtest disk1 --writeBlock 164493141 --count 1 --zeroFill

C:\>devtest disk1 --writeBlock 165324261 --count 1 --zeroFill

C:\>devtest disk1 --writeBlock 165339865 --count 1 --zeroFill

 DevTestでリードエラーの発生した箇所にデータを書き込み前のSMART情報と、書き込みした後のSMART情報を調べてみました。SMART情報の取得にはsmartctlコマンドを使いました(smartctlの入手方法や詳細は下記のリンクを見てください)
 上書き前のSMART情報を見てみると、「Current_Pending_Sector」の値が5になっていて、保留されているペンディング・セクタが5つあるのが分かります。
 上書き後は「Current_Pending_Sector」の値は0になって、消えているがわかります。
 「Reallocated_Sector_Ct」が増えていないところを見ると、リフレッシュだけで予備領域への再割り当ては行なわれていないようです。

■ 上書き前のSMART情報
ID# ATTRIBUTE_NAME          RAW_VALUE
  3 Spin_Up_Time            12229
  4 Start_Stop_Count        4140
  5 Reallocated_Sector_Ct   14
  6 Read_Channel_Margin     0
  7 Seek_Error_Rate         0
  8 Seek_Time_Performance   53786
  9 Power_On_Hours          50479
 10 Spin_Retry_Count        0
 11 Calibration_Retry_Count 0
 12 Power_Cycle_Count       90
192 Power-Off_Retract_Count 0
193 Load_Cycle_Count        0
194 Temperature_Celsius     0
195 Hardware_ECC_Recovered  189
196 Reallocated_Event_Count 0
197 Current_Pending_Sector  5
198 Offline_Uncorrectable   0
199 UDMA_CRC_Error_Count    0
200 Multi_Zone_Error_Rate   0
201 Soft_Read_Error_Rate    0
202 TA_Increase_Count       0
203 Run_Out_Cancel          0
204 Shock_Count_Write_Opern 0
205 Shock_Rate_Write_Opern  0
207 Spin_High_Current       0
208 Spin_Buzz               0
209 Offline_Seek_Performnce 0
 99 Unknown_Attribute       0
100 Unknown_Attribute       0
101 Unknown_Attribute       0
■ 上書き後のSMART情報
ID# ATTRIBUTE_NAME          RAW_VALUE
  3 Spin_Up_Time            12229
  4 Start_Stop_Count        4140
  5 Reallocated_Sector_Ct   14
  6 Read_Channel_Margin     0
  7 Seek_Error_Rate         0
  8 Seek_Time_Performance   33277
  9 Power_On_Hours          50486
 10 Spin_Retry_Count        0
 11 Calibration_Retry_Count 0
 12 Power_Cycle_Count       90
192 Power-Off_Retract_Count 0
193 Load_Cycle_Count        0
194 Temperature_Celsius     0
195 Hardware_ECC_Recovered  191
196 Reallocated_Event_Count 0
197 Current_Pending_Sector  0
198 Offline_Uncorrectable   0
199 UDMA_CRC_Error_Count    0
200 Multi_Zone_Error_Rate   0
201 Soft_Read_Error_Rate    0
202 TA_Increase_Count       0
203 Run_Out_Cancel          17
204 Shock_Count_Write_Opern 0
205 Shock_Rate_Write_Opern  0
207 Spin_High_Current       0
208 Spin_Buzz               0
209 Offline_Seek_Performnce 0
 99 Unknown_Attribute       0
100 Unknown_Attribute       0
101 Unknown_Attribute       0
 出力結果は掲載用に加工しています。
 SMARTで表示できる情報はメーカやモデルによって異なります。

不良セクタ回避・修復について

 リフリッシュやリアサインはハードディスクが自動的に行なっており自動的に修復されている限りOSやアプリも関知していませんが、これとは別にOSやファイシステムが不良セクタを回避・修復する機能を持っています。
 OSやファイルシステムが行なう不良セクタの回避・修復はエラーのあったセクタは利用しないというもので、回避・修復した分だけ利用できる容量が減ります。一方、ハードディスクが行なうリフレッシュやリアサインは予備領域を使うのでOSやアプリから見たハードディスク容量は変化しません。
 Windowsではディスクのプロパティ、またはchkdskやscandisk(95/98/Me)によってディスクの検査ができますが、空き領域についてはエラーの修復は必要ないと思います。修復してしまうと利用できる容量が減ってしまいます。
 これまで説明したように不良セクタは読めなくても新しくデータは書き込みできます。利用すべきデータが保存されていないから空き領域になっているわけで、空き領域にアクセスする場合はまず書き込みが行なわれます。したがって、空き領域にある不良セクタは放っておいても大丈夫かと思います。
 検査するにしても空き領域については読み取り検査だけで、不良セクタを洗い出しておくといいでしょう。読み取り時にエラーがあればペンディング・セクタとして認識されますので、次回書き込み時に自動的に修復されるはずです(ただし、ペディング・セクタはいつまで保持されているからわからないので、可能ならば直後に書き込みしたほうが良いかと思います)
 書き込みしてもなお修復できないようなエラーなら寿命か予備領域を使い切ったか、いずれにせよ通常は使用はやめたほうがいいでしょう。

まとめ

 ハードディスクには動作中に起こる故障のリスクと、動作を停止したことでデータを消失するリスクの両方があります。
 前者は簡単に理解できると思いますが、ハードディスクは消耗品で長期間使っていると故障しやすくなります。
 後者については、ハードディスクはリフレッシュやリアサインを行なうことでデータや品質を保持している面があるからです。動作を停止したからといってすぐにデータが消えるようなことはありませんし、数年間使わなかったからといってすべてのデータが消えるわけではありません(記録面が無事でも、ディスクが回転しなかったりヘッドが壊れたといった故障があれば全滅ですけど)
 しかし、ハードディスクの記録面の品質はまったく均一というわけではありません。中には些細なことでデータが消えてしまう、品質的に弱い部分が存在し数ヶ月でデータが読めなくなってしまうことがあります。
 品質的に弱い箇所といってもハードディスク全体からしたら極わずかな箇所ですが、たとえ1箇所でもデータが消えてしまったら場所によっては大変なことになります。
 このようなトラブルを回避するためにハードディスクにはリフリッシュやリアサインによる修復機能がありますが、動作を停止したままだとこれらの機能が働かなくて、修復の機会を失ってしまいます。以前にも書きましたが(関連記事)、ハードディスクに安全にデータを保存するためには定期的にアクセスすることが重要です。

【参考資料】

Microsoft

http://www.microsoft.com/

 ディスクに不良ブロックが含まれている場合は、ソフトウェア ミラーを作成できない

http://support.microsoft.com/default.aspx?scid=kb;ja;325615

Newtech

http://www.newtech.co.jp/

 コラム:ハードディスクの大容量化にはRAIDアルゴリズムの強化が必要

http://www.newtech.co.jp/tech/Column/Column17_1/index.html

○smartmontools Home Page

http://smartmontools.sourceforge.net/

  この記事へのコメント
コメントはありません。


名前 内容 -8042-を右に入力
 名前は10文字、内容は100文字以内で入力してください(半角の場合は倍の文字数まで)。
 もっと長いコメントや感想は掲示板(BBS)に投稿してください。

2004.08.08 HDD 4台収納ケース CENTURY グッドフェイスQuat

CENTURY EX35FUL4
CENTURY グッドフェイスQuat EX35FUL4

 3.5インチ ハードディスクを4台収納できる外付ドライブ ケースCENTURY グッドフェイスQuat (EX35FUL4)を購入しました。
 インターフェースはUSB2.0とIEEE1394に対応し、4台のハードディスクを個別に使うスタンダードモードと、4台をまとめて1つの大容量ハードディスクとして使うジョイントモードを切り替えて利用できます。ちなみに、ジョイントモードはRAID-0(ストライピング)と違って、複数のドライブから同時に読み書きするわけではないので、転送速度は速くなりません。

 ハードディスクは日立グローバルストレージテクノロジーズ160GバイトIDEハードディスクHDS722516VLAT20(7200rpm, UltraATA/100)を2台調達しておきました。グッドフェイスQuatは4台まで収納できるのですが、とりあえず2台で使うつもりです。2台までなら、同シリーズのグッドフェイスTwinでよかったのですが、後々拡張することもあるかと思いQuatモデルを買っておきました。

■使用した主なハードウェア/ソフトウェア
  • マザーボード GIGABYTE GA-8IPE1000 Pro2
  • CPU Pentium 4 2.6CGHz
  • RAM 512Mバイト
  • Intel ICH5 USB2.0
  • Texas Instrument IEEE1394 (オンボード)
  • OS Windows XP Professional
 それでいつものように、ソフトウェアライブラリ に登録しているDevTest でベンチマーク テストを行ないました。ただし、公開しているDevTestは書き込みテストは実行できません(書き込みテストを実行するとファイルシステムを破壊して危険ですので)
 接続インターフェースはUSB2.0とIEEE1394の両方を、ハードディスクはHGST HDS722516VLAT20をスタンダードモードでは1台、JOINモードでは2台を使いました。参考のためHGST HDS722516VLAT20をATA100で接続した場合も調べています。

 以下がその結果です。

グッドフェイスQuat BENCHMARK
TEST USB2.0
STANDARD
(160GB)
USB2.0
JOIN
(320GB)
IEEE1394
STANDARD
(160GB)
IEEE1394
STANDARD
(320GB)
ATA100
(160GB)
Sequential Read/Start 512B 1358.2kB/s 1358.0kB/s 2065.3kB/s 2065.4kB/s 4942.5kB/s
16384B 21802.1kB/s 21795.0kB/s 24925.5kB/s 24943.5kB/s 61075.9kB/s
65536B 32629.2kB/s 32642.3kB/s 32704.6kB/s 32894.7kB/s 61108.6kB/s
Sequential Read/End 512B 1356.7kB/s 1356.9kB/s 2062.6kB/s 2063.6kB/s 4931.2kB/s
16384B 21805.2kB/s 21802.5kB/s 24946.2kB/s 24893.8kB/s 32915.4kB/s
65536B 32666.4kB/s 32101.8kB/s 32864.1kB/s 33709.5kB/s 32899.0kB/s
Sequential Read/Ave. 512B 1357.4kB/s 1357.4kB/s 2064.0kB/s 2064.5kB/s 4936.8kB/s
16384B 21803.7kB/s 21798.8kB/s 24935.9kB/s 24918.6kB/s 46995.6kB/s
65536B 32647.8kB/s 32372.1kB/s 32784.3kB/s 33302.1kB/s 47003.8kB/s
Random Read 512B 39.5kB/s 38.8kB/s 40.1kB/s 39.3kB/s 40.3kB/s
16384B 1226.4kB/s 1193.1kB/s 1240.2kB/s 1206.4kB/s 1254.3kB/s
65536B 4438.5kB/s 4324.9kB/s 4438.9kB/s 4305.7kB/s 4652.5kB/s
Sequential Write/Start 512B 1329.1kB/s 1328.5kB/s 1803.0kB/s 1803.2kB/s 3092.4kB/s
16384B 18512.5kB/s 18490.2kB/s 19616.5kB/s 19625.3kB/s 49233.9kB/s
65536B 27356.3kB/s 27381.6kB/s 26109.5kB/s 26039.6kB/s 48576.7kB/s
Sequential Write/End 512B 1329.0kB/s 1329.0kB/s 1809.9kB/s 1807.0kB/s 3097.6kB/s
16384B 18535.5kB/s 18527.7kB/s 19718.1kB/s 19672.8kB/s 30139.2kB/s
65536B 27501.7kB/s 27508.3kB/s 26269.0kB/s 26070.2kB/s 29687.8kB/s
Sequential Write/Ave. 512B 1329.1kB/s 1328.7kB/s 1806.4kB/s 1805.1kB/s 3095.0kB/s
16384B 18524.0kB/s 18508.9kB/s 19667.3kB/s 19649.0kB/s 39686.5kB/s
65536B 27429.0kB/s 27444.9kB/s 26189.2kB/s 26054.9kB/s 39132.2kB/s
Random Write 512B 71.5kB/s 109.2kB/s 75.6kB/s 112.7kB/s 87.6kB/s
16384B 1835.6kB/s 2881.4kB/s 1981.8kB/s 2791.7kB/s 2255.9kB/s
65536B 5329.9kB/s 8342.4kB/s 5741.5kB/s 8397.2kB/s 5908.7kB/s
Random Read/Write BENCHMARK
TEST USB2.0
STANDARD
(160GB)
USB2.0
JOIN
(320GB)
IEEE1394
STANDARD
(160GB)
IEEE1394
STANDARD
(320GB)
ATA100
(160GB)
50:50 Read Speed 1066.8kB/s 1380.4kB/s 1081.5kB/s 1389.3kB/s 1166.3kB/s
Write Speed 1091.3kB/s 1457.0kB/s 1108.2kB/s 1461.5kB/s 1125.8kB/s
Read Count 32.7io/s 42.3io/s 33.0io/s 42.3io/s 36.0io/s
Write Count 33.3io/s 44.7io/s 34.0io/s 45.0io/s 34.7io/s
90:10 Read Speed 2073.0kB/s 2143.9kB/s 2097.3kB/s 2147.3kB/s 2229.2kB/s
Write Speed 200.2kB/s 209.4kB/s 202.6kB/s 210.7kB/s 194.9kB/s
Read Count 64.0io/s 65.7io/s 64.7io/s 66.3io/s 69.0io/s
Write Count 6.0io/s 6.0io/s 6.0io/s 6.0io/s 5.0io/s
10:90 Read Speed 229.9kB/s 365.7kB/s 236.2kB/s 362.1kB/s 244.9kB/s
Write Speed 2253.5kB/s 3756.2kB/s 2348.2kB/s 3704.4kB/s 2374.5kB/s
Read Count 7.0io/s 11.0io/s 7.0io/s 11.0io/s 7.0io/s
Write Count 69.3io/s 115.7io/s 72.3io/s 114.0io/s 73.3io/s

 以下は65536B単位のシーケンシャル リード/ライトの速度をグラフにしたものです。

 テストに使用したハードディスクは、ATA100接続では読込 61MB/s、書込48MB/sという速度が出ますが、グッドフェイスQuatで使用した場合には33MB/s程度で頭打ちになっています。インターフェースはUSB2.0でもIEEE1394でもたいして速度に違いはありません。ただし、細かくみると512Bや16384Bとか小さな単位の読み込みでは、少しだけIEEE1394のほうが速いようです。

 スタンダードモードとジョインモードの速度の違いもないことがわかります。ただし、ランダムアクセスについては、ジョインモードでは2台のハードディスクを交互に使うケースがあるために、少し速くなっています。


【参考資料】

CENTURY

http://www.century.co.jp/

  この記事へのコメント
コメントはありません。


名前 内容 -9394-を右に入力
 名前は10文字、内容は100文字以内で入力してください(半角の場合は倍の文字数まで)。
 もっと長いコメントや感想は掲示板(BBS)に投稿してください。

bar
[→PREV][→NEXT]
[←BACK][↑HOME]
PAGE HIT: 00019501  外部へのリンクはページ制作時のものです(後日、修正する場合もあります)。URL が変更されたりページが削除された場合はリンクが切れている可能性がありますがご了承ください。