3月版　2TBを超えろ！ ATAディスクの4Kセクタ問題とは？

小崎資広
2010/4/7

アライメント問題のディスクベンダからの奇妙な回答

　さて、このままでは4KiBセクタHDDは使い物になりません。

　誰がいい出したのか分かりませんが、これを解決するために、ATA規格には「アライメントオフセット」という概念が導入されています。

　どういうコンセプトの機能かというと「どうせ論理セクタはHDD内ファームウェアで作られた仮想的な概念なのだから、物理セクタで使わない場所があってもいいではないか」という発想の下、物理セクタ0に論理セクタを7個しか入れず、LBAを1つずつずらすのです。これにより、LBAの物理セクタ境界は「8、16、24、32、40、48、56、64」のような8×nのLBAかから、「7、15、23、31、39、47、55、63」のような（8×n）－1のLBAとなり、LBA63は物理セクタ境界にピタリと収まります。

通常の4kセクタ

アライメントオフセット（アライン対策）

LBA63から8セクタ書き込む場合、通常のドライブでは物理セクタ7と8（LBA56～71）の合計8KiBを読み込み、LBA63～70の範囲の4KiBを修正したあと、また物理セクタ7と8を書き込むため、内部的に書き込み量が2倍に増えてしまう（つまり、性能が半分に見える）。アライメントオフセットありの場合は、LBA63～70の4096bytesの書き込みがきれいに物理セクタ8の書き込みに変換でき、read-modify-writeが発生しない

　もちろん、このテクニックは第1パーティションでしか意味はありません。けれど、大半のWindowsマシンはパーティションを1つしか持たないことを考えれば許容範囲という考え方もできます。

　問題は4KiBセクタ対応ソフトウェアがパーティション境界（つまりI/O開始LBA）を8の倍数に合わせると、逆にアライメントがずれてしまい、性能が落ちてしまうことです。誰が考えたんだこれ。

　結局、ディスクユーティリティやパーティション設定ツールは、物理セクタサイズとアライメントオフセットの両方をドライブから取得し、適切なアライメントにそろえないと性能が出ないということです。

　驚くべきことにWindowsはVistaにおいて過去の互換性を完全に捨て（注9）、パーティションを1MiB境界にそろえるよう仕様を変更しました。またアライメントオフセットがあるHDDの場合は、1MiB＋アライメントオフセット（普通は3584bytes（＝512×7））をパーティション境界にします。

　つまり、Vista以降でパーティションを切った場合、XPを直接インストールすることはできませんし、HDDによって最適なアライメント位置が異なるので、ディスククローンツールでOSイメージをコピーすると性能が大幅に劣化する可能性があるということです（注10）。

注9：http://support.microsoft.com/kb/931760

注10：ちなみにWD社のハードディスクは、ジャンパ設定により、このアライメントオフセットのON／OFFを変更できるようになっています。

Linuxの対応状況は？

　Tejun Heoのまとめ記事の投稿を受け、LKMLのストレージ関係者のディスカッションが始まりました。

　口火を切ったのはJames Bottomley（SCSIメンテナ）です。彼によると、

そもそも512bytesセクタと2TiB制限には本来何の関係もない。DOSパーティションがLBAを32bitで管理しているのが原因なので、GPT（GUID Partition Table）に移行するべきだ
論理4KiBセクタは完全にうまく動作するが、BIOSとブートローダの対応は不完全だ
論理512bytesには、Tejunがいったような問題が存在する
アライメントオフセットはもっと複雑な問題を引き起こすので、むしろ抹殺するべき

と述べ、結論として非ブートパーティションではGPT＋4KiB論理セクタを勧める、と結びました。

　またH. Peter Anvin（hpa、x86メンテナ兼syslinux開発者）は、「本来BIOSはパーティションテーブルを読まないし、読んではいけないのだが、現実には腐っているBIOSが多数あり、CHSを推測しようとDOSパーティションテーブルをパースしようとする。このため、ブートデバイスをGPTにすると、BIOSがおかしくなることがある。また、4KiB論理セクタ長に関してはブートローダ側も対応が必要で、syslinuxは対応が終わっていない」と報告し、リファレンスハードウェアを入手したいものだと嘆きました。

　なお別の開発者からの報告によると、LILOはおそらくブート可能だがテストはされていないのではないかという状態で、GRUB2の状況はまったく不明のようです。

　さらに、Linuxのパーティション設定ツールのあるべき動作についても議論が行われました。

　一見するとWindowsに合わせればいいようにみえますが、Tejunは、Linuxの場合はそう簡単ではないと指摘しました。普通のWindowsユーザーは、XPからVistaにアップグレードするときはXPを消してしまうことが多いため、パーティション非互換は表面化しません。しかしLinuxのユーザーはWindowsとのデュアルブート環境で運用することが多いため、XPとVista、両方に対する互換性が必要になるというのです。これに対して、「fdisk側でデフォルトはVistaと同じ挙動、DOS互換モードでXPと同じにするのがいいのではないか」と回答されました。

　これに対して、Denys Vlasenkoは「互換性を考えるなら1MiBなんて変な数字じゃなくて、8×63の倍数にアライメントを合わせるべきだ」と主張しました、その方がXPとVistaの両方に互換性を持てるではないかというわけです。

　しかしhpaは、「SSDの物理セクタが256KiBであることを忘れないでほしい。またRAIDも同じように大きなストライプ幅（注11）を持つ。消えゆくOSであるXPのために、これらを犠牲にするのは感心しない」と、このアイデアを制しました。

　また、Mikael Abrahamssonは、Vista以降ではWindowsの動作が変わっているという報告に疑問を呈しました。「XPではパーティションが63の倍数でないといけないというのが本当ならば、WDが配布している、パーティションアラインをずらして8の倍数にそろえるツール（注12）では、XPの速度が向上するどころか、起動しなくなるではないか」と。

　これに対して、Windows XP SP2以降は任意のパーティションから起動できるため、あのツールはSP2とのインストール順序さえ気を付ければ問題ないだろうとの回答が付きました。

　Claudio Scordinoは、論理セクタ長が512bytes時のread-modify-write動作について、根本的な疑問を投げ掛けました。「いままで512bytes単位でアトミックに書き込めていたのであれば、512bytes論理セクタ時でもアトミックに変更できるべきだ。そうでなければ電源断時にデータ破壊の危険があるではないか」というのです。

　Martin K. Petersen（OracleのLinuxエンジニアで、IDEMAの内部事情に詳しい）は、「もともと512bytesでも保証はなかった。ベンダは努力はしていたが、実際には、例えば書き込みセクタを調整することでホットスポットを分散させたりしてたから、そういう処理が原因でアトミックに処理できなかった。そういう訳で、非揮発性キャッシュ付きのRAIDをみんな使っていたのさ」と説明。これについては、「アトミック書き込み保証問題は、サーバ業界が4KiB論理セクタ長に向かっている理由の1つである」とコメントが付きました。

　Martinは結びとして、「4KiBセクタなんて誰もうれしくないよ。ドライブベンダを除いてね。業界は512bytes論理セクタを維持するように努力している。おそらく最初のステップは、ミスアラインドアクセスおよびセクタ長の倍数でないアクセスを報告する機能を追加することで、次のステップは適切にアライメントされていないwriteを拒否することだ」と見解を述べました。

　最後にユーザーランドツールの開発者らから、さまざまなツールの対応状況について報告が行われました。まず、Karel Zak（util-linuxng開発者でredhat社所属）が、さまざまなパーティション設定ツールの最近の動向について説明しました。

- libblkidはトポロジを扱う統合されたAPIを提供する
　　　　　- ioctls（kernel >= 2.6.32）
　　　　　- sysfs（kernel >= 2.6.31）
　　　　　- DM、MD、LVMのためのストライプチャンクサイズ、ストライプ幅
- またlibpartedおよびfdiskは、libblkidをリンクして使うようになっている
- fdiskは4KiB論理セクタサイズを以下のバージョンからサポート
　（util-linux-ng >= 2.15）
- fdiskは4KiB物理セクタサイズを以下のバージョンからサポート
　 util-linux-ng >= 2.17）
- fdiskはnon-DOSモード時に、1MiBアライメント（RAIDなどでoptimal I/O sizeがより大きいときはその値）およびアライメントオフセットを使う
　（util-linux-ng >= 2.17.1）
- partedは4KiB物理セクタサイズをサポート
- partedはディスクのトポロジが不明な場合、1MiBアライメントを使う
　　　　　トポロジ情報が取得できる場合はoptimal（または minimum）I/O sizeに合わせる
　　　　　（parted >= 2.1）
- Linuxカーネル内のEFI GPT コードは4KiBセクタで動作するようアップデートされた
　（kernel >= 2.6.33）
- mkfs（ext、xfs、gfs2、ocfs2）は、トポロジ情報をきちんと扱えるようアップデートされた。また、mkfs（ext、xfs）は互換性のためにlibblkidをリンクしている（RAIDのストライプチャンクサイズ用）。
- Fedora-13／RHEL6（注13）のインストーラは4KiBサポートありのlibpartedを使う
- アライメントオフセットおよび 4KiB はLUKSでもサポートされる予定

　Jim Meyering（Partedの開発者）は、「Partedの変更点のニュースはここから取れるよ」とURLを提示した後、「でも僕はGPTを強く勧めるよ。2^32を超えるオフセットに対してよりよいプロテクション（checksum、ディスク末尾のbackup table）を提供するし、アナクロなプライマリ／エクステンド・パーティションの概念がない（すべてプライマリ）。Windows XP縛りがないなら、新規インストールでDOSパーティションを選ぶ理由がないよ」と補足しました。

　それに合わせるようにMartin K. Petersenが、「hdparmもアップデートが必要なんだけれど、Markはまだhdparmの私のパッチを含む新版をリリースしていないようだ」と愚痴をこぼしたところにMark Lordが登場。「Holy crap. てっきり1カ月前にリリースし終わったと勘違いしてた。いまリリースした」とhdparmのバージョンアップを宣言しました。

　結論としては、4KiB論理セクタ長のブートローダ対応は終わっていないけれども、512bytes論理セクタ長のときの各種ツールの対応はほぼ完了といった状況のようです。いやはや、こんな大きな非互換を導入してしまうHDD業界はホント罪深いですね。

注11：RAID0でディスク2台、ストライプ幅が1MiBの場合、0-1MiBの範囲のI/Oはディスク1に、1MiB-2MiBの範囲のI/Oディスク2に、というように、1セクタよりも大きな幅でディスクにI/Oを振り分けるのが普通です。

注12：http://www.wdc.com/en/products/advancedformat/

注13：RHEL6がFedora-13ベースになるという発表は、Redhat社のサイトから見付けられませんでした。ニュースソース不明。

2/2

Index
Linux Kernel Watch　3月版　2TBを超えろ！ ATAディスクの4Kセクタ問題とは？

	Page 1 　そもそもの始まりは　HDD容量増加の裏側で　ソフトウェア互換性について
	Page 2 　アライメント問題のディスクベンダからの奇妙な回答 Linuxの対応状況は？

連載 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カーネルの開発体制などについて伺った
	more

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

Linux ＆ OSS フォーラム新着記事

【 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」コマンドです。