Tweet

HDD 4KBセクタ化の背景

「HDD が 4KB/セクタ に移行する」という話の続き.

そもそもの疑問は

なぜわざわざ 4KBセクタに移行する必要があるのか

というあたりである.

Big Sector Backgrounder というドキュメントを見る限りでは

  • 誤り訂正
  • 「セクタギャップ」

というあたりが主な理由のようである.

誤り訂正

わかりやすいところで,PC/AT 互換機の歴史に例えてみる.

PC の DRAM の誤り対策として,昔はパリティビットによる誤り検出が一般的であった. データビット 8 bit に対し 1 bit のパリティビットを追加し,1 の数が奇数か偶数かでデータ化けがあるか無いかを検出していたのである. 時代は経て DRAM のデータバス幅がどんどん太くなり,64 bit になったとき,誤り訂正という技術が導入された. 64 bit のデータビットに対し 8 bit の冗長ビットで 1 bit までのデータ化けを正しく訂正できるようになったのである.

8 bit + 1 bit では「検出」しかできなかったのが 64 bit + 8 bit で「訂正」までできるようになった. つまり,データビットに冗長ビットを同じ割合で付加(この場合 8 データビットに 1 冗長ビットの割合)した場合,処理単位が大きければ大きいほど誤り訂正能力が大きくなるということになる. 実はこれは純粋に数学的なレイヤでの問題であって,半導体の集積度がうんぬんといった技術的な問題ではない.

HDD での誤り訂正でも同様のことが言える. 冗長ビットの密度が同一の場合,処理単位が大きければ大きいほど誤り訂正能力は大きくなる. 逆に言えば,同等の誤り訂正能力をキープする場合,処理単位が大きければ大きいほど冗長ビット密度は低く抑えることができ,より多くのデータを詰め込むことができるようになる,と言うわけである.

ドキュメントには SNR なんてキーワードもあるが,意味していることは上記の ECC と同様のことである. S/N と誤り訂正には密接な関係がある.

S/N ←→ 誤り率 ←→ 誤り訂正

間にこんなキーワードをはさんでみるとわかるだろうか?

データ通信の分野では,S/N を横軸にビット誤り率を縦軸にグラフを書いて通信系の評価を行うことが多い. で,当然ながら誤り訂正を導入すると,同じ S/N の通信路でも誤り率を低くすることができる. 見かたを変えると「誤り訂正によって S/N が改善した」という風にも取れるのでこれを「符号化利得」なんて呼ぶこともある. 誤り訂正が強力になれば符号化利得も大きくなり,S/N の(見かけの)改善度も大きくなる,というわけである.

問題の HDD においてであるが,送り手と受け手は同一 PC で,時を隔てたデータ通信と考えれば上記の理屈はそのまま適用できる.

セクタギャップ

正確にいうとサーボ・PLL 同期用のプリアンブルかな. セクタサイズを大きくすればプリアンブルも少なくて済むので,その分データを詰め込むことができる,というわけである.

GPLv3の条文解説書,IPAがクリエイティブ・コモンズで公開

ITpro の記事.

GPLv3の初期の草稿では,DRM(デジタル著作権管理技術)利用について厳しい制限が盛り込まれていた。しかし「最終的にはGPLv3の正式な条文ではコピー・ガードやコピー・プロテクトにDRMを使用することは,実務上はほとんど問題ないところに落ち着いている」(IPA オープンソフトウェア・センター リーガル・タスクフォース委員の上山浩弁護士)。

「ホントかよ」と思い,件のブツをここからダウンロードして,6条まわりの部分を読んでみた.

…やっぱだめじゃん.

まぁ,何か想像しているものがオイラとは違うのかもしれないけど. オイラの場合は以前に知恵を絞った DTCP-IP ストレージ機器を想像してたんだけど,この場合はやっぱりアウトだなぁ. GPLv3 では,例えば「改造した samba をインストールして動作する」ようにしなくてはならない. ということは,telnet を組み込んだ samba の動作を許すことになるわけで,つまり

root でのシェルプロンプトと任意のプログラムの実行

を許すことになってしまう.

この状態で別プログラムが扱っている暗号鍵を守りきれるかというと…オレには無理だなぁ. もちろん,コスト上の制限が無ければ,GPLv3 でも問題ない方法は考え付いてはいるんだけどね.


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2009-04-23 (木) 20:54:32 (3922d)