2009/12/21 月曜日

Advanced Format Architectureの意義

Western Digital’s Advanced Format: The 4K Sector Transition Begins – AnandTech
http://www.anandtech.com/storage/showdoc.aspx?i=3691

AnandTechにWestern Digitalとの取材で得たAdvanced Formatアーキテクチャ関連情報が掲載されていました。

Western Digitalに限らず、他のHDDメーカーもセクタサイズを4KiB※へ移行するようですので、その意義についてAnandTechの記事を参考にちょっと調べてみました。

※今回はHDD関連ですのでkB(1kB=1000Byte)を使用すると紛らわしいのでKiB(1KiB=1024Byte)表記に統一しました。

プラッタの高密度化によるエラー発生率上昇

通常1つのセクタには1つのファイルしか格納できず、現在と比べるとファイルサイズが小さかった1990年代はこれまでのHDDが採用した512Byteセクタがバランスが良かった。

しかし、現在の記録するファイルのサイズが増大し、さらにHDDはプラッタの密度が上昇し、それに伴いプラッタ上に記録される磁気の信号に対するノイズの割合(S/N比)が減少している。

SNR

(引用:http://www.anandtech.com/storage/showdoc.aspx?i=3691)

信号なのかノイズなのかを見分けることが難しくなるため、エラーを防ぐためエラー訂正符号(ECC)を添付するが、S/N比が小さくなればなるほど長いECCが必要となってくる。そのため、現在の高密度プラッタではECCが占める割合が増えてきている。

このまま高密度化を進めていくといずれ実データとECCの量が同じなってしまい、さらに高密度記録が難しくなってしまう。

ECCの効率的な符号化

現在のHDDのECCにどのような符号が使われているのかはわかりませんが、HDDのECCはデータサイズが大きくなるほど効率が高くならしい。つまり、セクタサイズを大きくすることでECCの占める割合を減らすことができる。

※磁気記憶媒体には効率は悪いが高速処理可能な『ファイヤ符号(fire code ECC correction)』を使用していると習ったが今も使っているかは知らない… 知ってたら教えて(^^;)

hgst_eccsectorsize

(引用:WinHEC2005 HGST発表資料より)

例えば、セクタサイズが512Byteであれば40ByteのECCが必要であるとすると、8倍である4096Byteのセクタではこれが100Byteで済む。

何故に4KiB?

データサイズを長くすればするほど効率が向上するなら、4KiBと言わずもっと長くすればいいのに!と思いますが、4KiBというのもワケあり。

多くのPCで用いられているx86アーキテクチャはメモリを4KiB単位でページし記憶している。また、Windowsで用いらているNTFS、LinuxのEXT3、MacOSのHFS+のファイルシステムはいずれも現在はデフォルトでのクラスタサイズが4KiBとなっている。これらとセクタサイズを統一することでより利用効率の向上を図っているわけである。

まとめ

調べてみると、4KiBセクタへの移行準備が始まったのは1990年代後半。BIOSでの対応、OSでの対応などを経て、今年ようやくHDD側が対応。高い信頼性を保ちながら高密度化を進めていくために4KiBセクタが徐々に標準になって行きそうですね。

参考文献等(AnandTech以外)

(PDF) Sample Title Goes In This Space – IDEMA
http://www.idema.org/_smartsite/modules/local/data_file/show_file.php?cmd=download&data_file_id=1699

(PDF) Hard Disk Drive Long Data Sector White Paper – IDEMA Japan
http://www.idema.gr.jp/technical/white/6_13_07.pdf

(PDF) Advanced Format Technology – Western Digital
http://www.wdc.com/wdproducts/library/whitepapers/en/2579-771430-A00.pdf

(DOC) 4K Byte-Sector HDD-Data Format Standard
http://www.idema.org/_smartsite/modules/local/data_file/show_file.php?cmd=download&data_file_id=1259

今井秀樹(1984) 『情報理論』 昭晃堂 ISBN4-7856-1139-1

これまでのAdvanced Format Architecture関連記事

はいじん☆ちゃんねる >> 【注意!】WD10EARSは特殊な物理フォーマットを採用
http://haizin.serveblog.net/?p=5953

はいじん☆ちゃんねる >> 64MB版のCaviar Green WD15EARSが発売
http://haizin.serveblog.net/?p=6086

はいじん☆ちゃんねる >> WD10EARSの比較ベンチマーク
http://haizin.serveblog.net/?p=6092

2009/12/20 日曜日

WD10EARSの比較ベンチマーク

Advanced Format採用の新HDD「WD10EARS」を検証 – ドスパラ
http://review.dospara.co.jp/archives/51757545.html

新物理フォーマット『Advanced Format Structure』を採用したWestern DigitalのCaviar Green (EARS)シリーズの1TBモデル『WD10EARS』のベンチマークがドスパラの製品レビューに掲載されていました。

Advanced Format StructureはこれまでのHDDで使用されてきた物理フォーマットとセクタの境目が異なるため、Windows XP以前で初期化したNTFSパーティションでパフォーマンス低下が発生するとされていますが、ドスパラのベンチマークでそれを検証しています。

Windows 7にてフォーマットした場合とWindows XPでフォーマットした場合で比較してますが、確かにランダムアクセス時に違いが発生している。

ただし、他のサイトでもベンチマークを行っているのを見かけますが、ここまで差が出ているのは始めてみましたねぇ。環境によるのかも…

はいじん☆ちゃんねる >> 【注意!】WD10EARSは特殊な物理フォーマットを採用
http://haizin.serveblog.net/?p=5953

2009/8/9 日曜日

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【目次】

ntfscompress2

先日、こんな記事を書きました。

はいじん☆ちゃんねる >> 『圧縮を有効にする』使ってる人いますか?
http://haizin.serveblog.net/?p=3908

現在のMicrosoft Windowsに採用されているファイルシステム『NTFS』には、パーティションを圧縮することで使用可能容量が増える「圧縮」機能が搭載されている。 ちょっと前までのPCでは圧縮時のCPUへの負荷が大きすぎてあまり使える機能ではありませんでしたが、マルチコアCPUが一般的になった今はどうかと思い、検証してみました。

検証方法

Barracuda 7200.11 ST3320613ASのNTFS圧縮のON/OFFを切り替えてその際の違いを検証しました。はじめに定番のCrystalDiskMarkにより違いが出るかを検証。その後、ファイルコピーにより違いが出るかを検証した。 ファイルコピー比較の際には相手となるHDDがボトルネックになることを防ぐため、ST3500418AS ×2のRAID0アレイを相手に用いた。

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【目次】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【CrystalDiskMark】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【JPEGコピー編】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【BMPコピー編】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【まとめ】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【CrystalDiskMark】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【目次】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【CrystalDiskMark】←今ココ
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【JPEGコピー編】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【BMPコピー編】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【まとめ】

HDDを検証する定番の方法ですが、CrystalDiskMark2.2を用いてNTFS圧縮のON/OFFで違いが出るかを検証しました。

いきなり結果だが…

ntfs_compress9

ほとんど違いが見られませんねぇ。RAMDISKでNTFS圧縮を行うとスコアが落ちているのを見たことがありますが、HDD程度の速度だとCrystalDiskMarkでは違いが出ないのかもしれませんねぇ。

若干がっかりな結果でした。

【JPEGコピー編】へ

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【JPEGコピー編】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【目次】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【CrystalDiskMark】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【JPEGコピー編】
←今ココ
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【BMPコピー編】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【まとめ】

CrystalDiskMarkでは違いが見られなかったNTFS圧縮だが、実際の使用法に近いファイルコピーに要する時間を検証してみました。

また、その際のCPU使用率もCRN Monitorを用いて記録してみました。検証に用いた環境はCore2Quadを用いているため各コアの使用率のログをとり、全コアの平均値を算出しました。

ここではデジカメで撮影した3422枚、総容量24.1GBのJPEGファイルをコピーすることで検証した。

testjpeg

コピー時間(Copy time)は、コピーするファイルをコピー先で放した瞬間から[コピー中]のダイアログが消える瞬間までの時間を示しています。グラフにはコピー終了後30秒分くらいのデータも載せてあります。また、コピー時にウィルス対策ソフトによる影響を避けるため、ウィルス対策等は停止させました。

NTFS圧縮による転送速度変化

まずは、NTFS圧縮が無効の際のコピー。

ntfs_compress1

ntfs_compress2

こうやって見ると、コピーって意外にCPU使用してるんですねぇ。平均で15%くらいですね。

ST3320613ASから読み出しが約115MB/s、書き込みが約98MB/sとなりました。

お次はNTFS圧縮を有効にしたさいの結果。

ntfs_compress4

圧縮有効時の読み出し結果。

圧縮無効では208秒だったコピー時間が246秒かかりました。転送レートにすると約100MB/s。

平均CPU使用率は18%くらいと、若干高くなりました。読み出し時に圧縮されたデータを解凍することになるのだが、解凍にはそれほどCPUに負荷がかからないようですね。

つづいて、圧縮有効時の書き込みの結果。

ntfs_compress3

書き込みに要した時間は989秒。無効時の4倍近くになりました。平均CPU使用率を確認すると25%と一見低いように見えますが、各コアで確認すると常にどれか1つのコアが80%近い働きっぷりを示している。

どうやら、NTFS圧縮はマルチスレッドに対応していないようですね。

また、ファイル転送自体は989秒で終了しているのですが、グラフを良く見ると1020秒くらいまでCPU使用率が高いことが分かる。圧縮はファイルの転送が終了したあともバックグラウンドしばらく続くようですね。

NTFS圧縮の効果

書き込み速度は大幅に下がったNTFS圧縮有効時。時間がかかっても容量節約につながるならオールオッケー!さて、気になる容量はというと…

testjpeg_compressed

100MBしか減ってないorz

これじゃあまり魅力がないですねぇ…

【BMPコピー編】へ

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【BMPコピー編】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【目次】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【CrystalDiskMark】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【JPEGコピー編】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【BMPコピー編】
←今ココ
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【まとめ】

JPEGでは散々な結果だったNTFS圧縮。

もしかして、JPEGは元々かなりの圧縮がかけられているから効果がなかったのでは?!

となると試すべきは圧縮がかかっていないファイル!というわけで、次にビットマップファイル(BMP)を用いて検証してみました。

testbmp

用いたのは1,120枚のBMPファイルで構成される6.49GBのデータ。先ほどのJPEGよりも総容量が少ないですので絶対的時間変化は参考になりませんのでご了承を。べっ、別に時間がかかってめんどくさくなったわけじゃないんだからね

NTFS圧縮による転送速度変化

まずは、NTFS圧縮が無効の場合。

ntfs_compress6

ntfs_compress5

CPU使用率はJPEGの際とほとんど変わりませんね。

読み出しは約116MB/s、書き込みは約95MB/sとなった。

続いてNTFS圧縮有効時。

ntfs_compress8

読み出しでJPEGと違いが出ましたね。JPEGでは18%程度だったCPU使用率は25%に上昇。BMPの場合より高い圧縮が行われているためにCPUへの負荷も高めになったんでしょう。

各コアの使用率も安定していませんが、実は、各コアの使用率の合計を出すと常に100%前後となりました。どうやら、ここでもマルチスレッドに対応していないことにより、制限がかかってしまっているようですね。

コピーに要した時間は72秒。転送レートにすると約92MB/s。1.5倍といったところでしょうか。

最後にNTFS圧縮有効時の書き込みを見ると…

ntfs_compress7

CPU使用率的にはJPEGの際と似たような傾向ですね。いかにもシングルタスク。コピー終了後にしばらくCPU使用率が高めになるのもJPEGと同じですね。

コピーに要した時間は161秒ですので、NTFS圧縮無効時の2.3倍となった。JPEGよりも速いですね。

NTFS圧縮の効果

JPEGではほとんどファイルサイズに変化がありませんでしたが、BMPではどうかというと…

testbmp_compressed

おおっ!総容量6.49GBが3.21GBに!これは効果的だと言って良さそうですね。

【まとめ】へ

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【まとめ】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【目次】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【CrystalDiskMark】
【レビュー的な何か】NTFSの圧縮機能は有効なのか?【JPEGコピー編】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【BMPコピー編】

【レビュー的な何か】NTFSの圧縮機能は有効なのか?【まとめ】
←今ココ

登場から10年近くたっているのに「使えない機能」と思われがちな『NTFS圧縮』。

定番のCrystalDiskMark2.2と実際の使用方法に近いファイルコピーにおいて『NTFS圧縮』の効果を検証してみました。しかし、CrystalDiskMark 2.2では有効・無効による効果の差はみられなかった。

求められるのはマルチスレッド対応?!

ファイルコピーはさすがに速くなることはなく、特に圧縮を行う書き込み時の速度低下はかなり大きいかった。現在はマルチコアCPUが主流となっていてCPUでの高速な圧縮によってファイル転送量が減り、読み書きが高速化されるかと思ってましたが、残念な結果に。その原因と言えるのが、NTFS圧縮がマルチスレッドに対応していないことだろう。せっかくのマルチコアも主に1コアしか利用されていない。

より使える機能とするためにはマルチスレッドに対応することが必須でしょうね。

圧縮効果のほどは?

JPEGとBMPにて検証を行いましたが、JPEGでは圧縮効果はほとんどありませんでした。JPEG自体が元々高度な圧縮がかけられているためでしょう。これに対し、BMPは容量が半分に!

JPEGやMPEGなど高度な圧縮がかけられているファイルに対してはそれほど効果はありませんが、圧縮がかけられていないようなファイルを多く保存する場合は容量節約に貢献しそうです。

どんな場面で使えるか?

転送速度はコピーすると確かに倍以上の時間がかかりますが、通常のファイルを開いたり、セーブしたりといった使い方では必要十分な速度があります。現に、1か月ほど前からBarracuda 7200.11 ST31500341ASをNTFS圧縮有効で使用していますが、遅いと感じることはファイルバックアップ時くらいですね。

データ保存領域では意外と使える機能なのかもしれませんね。

ただし、動画編集等の高速転送が要求される領域では使用しない方が良さそうです。

参考までに…

NTFSの圧縮が有効となっているファイルは以下のように青い字で表示されます。

ntfscompress

パーティション全体だけではなく、ファイル・フォルダ単位での圧縮が可能となっています。

最後に…

使えない機能だと思っていた『NTFS圧縮』でしたが、使い方次第では有効活用できそうですね。自分の使い方にあっているようであれば一度『NTFS圧縮』を試してみてはいかがでしょうか?

2009/8/1 土曜日

【レビュー的な何か】帰ってきたST3320613AS【フォーマット編】

『目次』

【レビュー的な何か】帰ってきたST3320613AS【フォトレビュー編】
【レビュー的な何か】帰ってきたST3320613AS【フォーマット編】
←今ココ
【レビュー的な何か】帰ってきたST3320613AS【CrystalDiskMark編】
【レビュー的な何か】帰ってきたST3320613AS【HDTune編】

フォーマット編

さて、Vistaでのベンチマークの前に準備としてフォーマットを行います。

その前に、CrystalDiskInfo 2.7.4とHD Tune 2.55で正常かどうかを確認っと。

cdi_st3320613as

またしても初起動で電源投入回数が3回になってしまってますが、さすがに電源ユニットの1系統に4つHDDを接続したところ出力不足でスピンアップに失敗しました。別の系統に接続したところ無事起動。

以前のST3320613ASは同じ系統上に別のHDDが接続されていると全く動作しませんでしたが、どうやらハズレの個体を引いてしまっただけだったようですね。

HD Tuneはというと…

hdtune_st3320613as

とくに怪しい挙動はないですねぇ。相変わらずAccess Timeは遅いなぁ(^^;)

やっぱり、Barracuda 7200.11の初期のものの仕様みたいですね。

他にも気になることはあるけど、それは【CrystalDiskMark編】で。

ntfs_st3320613as

NTFSの完全フォーマットを行いました。お時間は53分5秒。容量が少ないと早い(^^)

【CrystalDiskMark編】へ

2009/7/12 日曜日

【レビュー的な何か】7200.12 ST3500418AS 2台目【フォーマット編】

【レビュー的な何か】7200.12 ST3500418AS 2台目【目次】

【レビュー的な何か】7200.12 ST3500418AS 2台目【フォーマット編】←今ココ
【レビュー的な何か】7200.12 ST3500418AS 2台目【CrystalDiskMark編】

前回は、フォトレビューから開始しましたが、まぁ、同じものですから違いはないです(^^;)

まず、今回購入した2台目はDate Codeは『09475』でした。1台目と同じで、2009年5月製造分のようですね。シリアル番号も下2桁以外は同じなので、製造順はかなり近いようですね。

接続してフォーマットする前にCrystalDiskInfo 2.7.4で確認してみました。

cdi_st3500418as2nd

初起動にしては電源投入回数が多いですが、接続した際にRadeonHD3870の電源ケーブルをはずしているのを忘れてて、何度か再起動を繰り返したからです(^^;)

今回も『代替処理済みのセクタ数』はゼロでした。

HD Tune 2.55でも確認してみると…

hdtune_st3500418as2nd

若干ですが、1台目よりも波形が乱れてますねぇ。まぁ、1台目の波形がきれい過ぎた気もしますけどね。

では、Windows Vista x64にてNTFSで完全フォーマット!

st3500418as2nd_format

当然かもしれませんが、バイト数は1台目と全く同じでした。フォーマットに要した時間は1時間22分。1台目が1時間16分50秒だったので、ちょっぴり時間がかかりましたねぇ。

フォーマット後、もう一度CrystalDiskInfo 2.7.4で確認。

cdi_st3500418as2nd_afterfor

異常なし!とっ

HD Tune 2.55もやっておくと…

hdtune_st3500418as2nd_after

これも異常なし!

お次は、CrystalDiskMark 2.2編です。

【レビュー的な何か】7200.12 ST3500418AS 2台目【CrystalDiskMark編】

【レビュー的な何か】7200.12 ST3500418AS 2台目【目次】

【レビュー的な何か】7200.12 ST3500418AS 2台目【フォーマット編】
【レビュー的な何か】7200.12 ST3500418AS 2台目【CrystalDiskMark編】←今ココ

んじゃ、フォーマットも完了しましたので、お次はCrystalDiskMark 2.2ですねぇ。

ベンチマーク環境は1台目と全く同じなので、そちらを参照してください。

【レビュー的な何か】7200.12 ST3500418AS 1台目【CrystalDiskMark編】

まずは、結果をズラッと並べてみました。

cdm50_st3500418as2nd

cdm100_st3500418as2nd

cdm500_st3500418as2nd

cdm1000_st3500418as2nd

あれっ?なんか遅くないか?!

1台目と比較してみると…

st3500418as2nd

※4Kの値は10倍してあります

データサイズによる特性は似てますが、転送レートは明らかに1台目と違いますねぇ。値としてはBarracuda 7200.11の375GBプラッタモデル『ST31500341AS』に近いですね。

1台目と2台目でどれだけ違うかを見るために転送レート低下率(%)で現わしてみると…

st3500418as2nd_21

書き込みはかなり遅くなってますねぇ。とくにランダム512Kでは1割も落ちてます。

【フォーマット編】でフォーマットに要した時間が1時間17分から1時間22分に増えたと書きましたが、この6%程度の時間増加は、シーケンシャル書き込みの差から来ているのかもしれませんね。

ちなみに、指摘を受けそうなので、書いておきますが、このあと、再び1台目のベンチマークを行ったところ、値に変化はありませんでした。よって、ベンチマーク環境のバックグラウンド(動作温度等)による影響ではなく、個体差であると考えられます。

他ブログ様のレビューでは「さすが500GBプラッタ」という結果を見かける半面、今ひとつな結果を見かけることがあります。もしかするとST3500418ASは結構個体差があり、言い方はよくないかもしれませんが、当たりハズレが大きいのかもしれませんねぇ。

次ページへ »

HTML convert time: 0.945 sec. Powered by WordPress