3月版 2TBを超えろ！ ATAディスクの4Kセクタ問題とは？
小崎資広
2010/4/7
前回書いたsys_membarrier()ですが、なかなかマージされない状態が続いています。だいたい議論も出尽くして後はマージするだけだと思っているのですが、どうもIngoは気に入らないご様子。たぶんオレ専用APIっぷりが美的感覚に合わないのでしょう。いつも「Genericに使えるように」っていいますから。
Compactionパッチは、マージの一番のネックだったkosakiがなかなかレビューしない問題は先月若干進展して、マージする方向で進んでいるみたいです。
さて、今月は久しぶりにハードウェアのお話です。ハードディスクの容量が2TiB（編注：テビバイト、1024GiB）を超えるのと前後して、4KiB（編注：キビバイト、1024bytes）セクタのハードディスクが出回り始めています。これについてハードウェア、Windows、Linuxそれぞれの対応状況についてお伝えしようと思います。
それでは、どうぞ。
そもそもの始まりは
Western Digital社（割と有名なハードディスクのメーカーです。以下WD社と略します）のエンジニア、Daniel Taylorは「4K disk block and disks larger than 2TiB bugs」というスレッドで、WD社の4KセクタHDD製品（注1）がLinuxでいくつかの不具合を引き起こすと報告しました。
「まあ、当たり前の話なんだけど、2TiB以上のディスクをWindows XPで使うためには、MBR（Master Boot Record）に4KiB論理セクタを使う必要があるんだよね。でもそのようなUSB-HDDをLinuxマシンにつないでも認識できないって問題があるんだ」「EFI（Extensible Firmware Interface）関係にはもっと大きな問題があって、非常に多くの個所で、セクタ長が512bytesだと仮定しているように見える」
それに対してChristoph Hellwigが「後者は2.6.32で修正済みだよ」と即答。前者についてもしばらく後に、Daniel自身の手によって修正されました。
それと前後してTejun Heoは「ATA 4 KiB sector issues」と題した包括的なまとめ記事を投稿しました。それに応じてさまざまなドライバツール開発者が、その時点での4KiBセクタ対応状況を報告し、長い長い議論になりました。以下、抜粋してお伝えしようと思います。
なお、さまざまな情報が追記された最新版が以下のページで公開されています。4KiBセクタHDD製品の購入を考えている人は一読しておくといいかもしれません。
| 【関連リンク】 http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues |
| 注1：製品としては「Advanced Format Architecture」という機能名を使っているようです。 |
HDD容量増加の裏側で
ハードディスクの容量はここ20年ぐらいで100万倍ぐらいに増えましたが、物理的なサイズは大きくなっていません（むしろ減っています）。ドライブの大きさが変わらないのに容量が増えているということは、内部的にプラッタの記憶密度を上げることにより容量を増やしているということです。これは、1セクタ当たりの物理サイズは小さくなるということであり、セクタ読み書き時の電気信号のS/N比が悪化するということを意味します。
HDDメーカーは従来、ヘッドの仕組みを改善して読み取り精度を上げたり、セクタにECCを付加してエラー訂正をしたりして、このエラー問題に対応してきました。しかし、それもそろそろ限界と、HDD業界は悲鳴を上げ始めているようです。
現在ATAのセクタサイズは512bytes固定であり、通常、1セクタにつき40bytesのECCが付加されています。これで約1割の容量ロスが生じます（さらに40bytesのリードイン／セクタギャップがあるので、実際には2割のロスになります）。そろそろECCを80bytesに増やさないとこれ以上の高密度化は無理、という声が聞こえ始めていますが、合計3割ものロスは許容できないというのです。
IDEMA（The International Disk Drive Equipment and Materials Association、注2）の資料（注3）、および規格策定途中のディスカッション資料を読むと、いろいろと興味深い記述が見つかります。
IBMの資料（注4）によると、ECCに必要なbyte数はセクタ長と正比例はしないので、仮にセクタ長を4096bytesに増やしてもECC長は100bytesで、512bytesセクタの40bytesECCと同等のエラー訂正能力を持つことができるそうです。
また日立GSTの資料（注5）によると、セクタ長が512bytesの場合、ECC長を50bytesくらいまでは増やしても、その分記憶密度を上げられるため、全体として大容量化できるそうです。しかし、それ以上ECCを増やしてもそれほど記憶密度は上がらないので、データ＋ECCのトータルの記憶密度は逆に下がってしまい、メリットはありません。逆にいうと、これ以上大容量化したかったら、ヘッドなどの別の部分で革新を行うか、記憶密度を犠牲にしてプラッタサイズ総面積を（物理的に）大きくする方向で大容量化するしかないとのことです。
……という状況では、セクタ長を大きくするのは魅力的な選択肢であることがお分かりいただけるでしょう。セクタ長を4096bytesにすれば、データ＋ECC＋リードイン／セクタギャップの総バイト数は、
512＋40＋40＝592bytes
から
4096＋100＋40＝4236bytes
に変更されます。比率にすると4236／（592×8）≒0.89で、約11％ほど記憶領域が稼げます。最近のHDD容量は2TBあたりがトレンドのようですから、11％は意外と侮れない量です。
また将来的にもさらにECC長を増やす余地があり、さらなる大容量化の余地がある、ということになります。
ソフトウェア互換性について
さて、セクタ長を大きくするのは、HDDのハードウェア的な要件からの要請でした。では、その大きさがなぜ8KiBや16KiBではなく4KiBかというと、これはソフトウェア側からの要請です。
x86のCPUアーキテクチャではメモリのページサイズが4KiBになっており、OSの仮想記憶サブシステムはすべて4KiBの倍数で処理を行っています。OS内のファイルキャッシュが4KiB単位で管理されているので、ファイルシステムから見ると、リード／ライトはほぼ常に4KiBの倍数で要求されます。そのため現代的なファイルシステム（NTFS、HFS+、ext[234]など）は、性能を最適化するためディスク上のデータも4KiBサイズのブロック（NTFS、HFS用語では「クラスタ」）で管理します（ファイルシステム作成時のオプションで変更できますが、普通の人はまず変えないと思います）。
つまりI/Oは、例外的なケースを除いて常に4KiBの倍数で出るし、どれだけ小さなデータでも少なくとも4KiBのディスク容量を使うということです。これは逆にいうと、4KiBまではセクタ長を増やしてもI/Oサイズはまったく増えず、性能劣化も容量の無駄も発生しないということです。
なんだかとてもいい話に聞こえますね。ところが、もうかれこれ20年以上も「1セクタ＝512bytes」でやってきてしまったので、コントローラ、ブリッジチップ、BIOS、ブートコード、ドライバ、パーティション設定ツール、ディスクユーティリティなど、ありとあらゆるレイヤに512bytesを仮定している処理があり、簡単に変更できる状態ではありません。
そこでHDD業界は、物理セクタ長は4Kに変更するが、ソフトウェアから見える論理セクタ長は512bytesに据え置き、HDDのファームウェアでエミュレーションするという対策を取ることにしました（注6）。
もし、ドライバが「LBA2048から64セクタ分読み込む」ことを要求したならば、内部的には「物理LBA256から8物理セクタの読み込み」に変換するのです（対応アプリケーションが最適化を行えるように、物理セクタ長を取得できるコマンドも新設されています）。
もちろん、性能が劣化しないのは、I/Oの開始LBAとI/O長の両方が8の倍数（4K/512）のときのみです。それ以外の場合は、内部的に
- 4KiBセクタを読み出し
- HDD内の作業メモリで書き換え
- 4KiBセクタを再度書き込み
という処理を行うことになるため（以降これをread-modify-writeと呼びます）、最悪の場合、性能が半分程度になってしまいます。
しかしこれは、
A. ファイルシステムを介するI/Oでは、ファイルシステムの開始位置（＝パーティション開始位置）を8の倍数にすれば、全データが8の倍数になる
B. それ以外の、ファイルシステムを経由しないI/Oを発行するアプリケーション（DirectIO使用アプリやディスクユーティリティ）は少数なので個別対応が可能
と思われていました。
ところが、実はPCの世界では、Aの仮定はまったく成り立っていなかったのです。問題はDOSパーティションのフォーマットにありました。DOSパーティションとはPCで一般的に使われているディスクのパーティションフォーマットで、その名のとおり、MS-DOSの時代に作られました。
昔のハードディスクはLBA（Logical Block Address）ではなく、CHSアドレッシング（注7）を採用していました。その影響で、いまとなっては時代遅れの制約がいくつか残っており、その1つに「パーティション境界はシリンダ境界に一致しなければならない」という制約があります。厳密にいうと、パーティション境界をシリンダ境界ではない場所に設定すること自体は、対応ツールさえあれば可能でした。でもそれではWindowsがブートしないので、誰もそんなことはしませんでした。
またLBA導入時には、互換性に関するさまざまなゴタゴタがあり、現在はHDDの内部構造にかかわらず、セクタ63個＝シリンダ1個として取り扱うことがデファクトスタンダードになっています（注8）。つまり、LBAが63の倍数ならばシリンダ境界ということです。これは、パーティションは63の倍数のLBAから始まるということを意味します。
しかし63は8の倍数ではありません。この結果、少なくとも第1パーティション（開始アドレスはLBA63）は4KiB境界に合っておらず、第2パーティション以降も8分の7という高確率で境界が合わないということが問題になります。これでは、ほぼすべてのケースでI/O性能が劣化してしまいます。
これが4KiBセクタアライメント問題です。
| 注6：もちろんこの方法を取らない物理セクタ用＝論理セクタ長＝4KiBのドライブも存在します。4KiB対応パッチが投稿されてくるところを見ると、少なくともWD社は商品化を検討しているようです。 注7：http://en.wikipedia.org/wiki/Cylinder_Head_Sector 注8：http://en.wikipedia.org/wiki/Master_boot_record |
| 1月版へ |
1/2 |
 |
|
||||
|
||||
 |
連載 Linux Kernel Watch |
| Linux Squareフォーラム Linuxカーネル関連記事 |
 |
連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします |
|
連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する |
|
特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する |
|
特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する |
|
特集：仮想OS「User
Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説 |
|
Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った |
|
- 【 pidof 】コマンド――コマンド名からプロセスIDを探す （2017/7/27）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。 - Linuxの「ジョブコントロール」をマスターしよう （2017/7/21）
今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です - 【 pidstat 】コマンド――プロセスのリソース使用量を表示する （2017/7/21）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 - 【 iostat 】コマンド――I/Oデバイスの使用状況を表示する （2017/7/20）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。
 |
|
|
|
|
