4KB セクター・ディスクで Linux を使用する: 実用的なアドバイス

すべてのシリンダーで Linux が起動するようにする

2009年 12月以降、ハード・ディスク・メーカーは通常の 512 バイトのセクターではなく、4096 バイトのセクターを使用するディスクを導入するようになっています。この変化は、オペレーティング・システムのために 4096 バイトの物理セクターを 512 バイト単位の論理セクターに分割するファームウェアによって表面的にはわからなくなっていますが、サイズが大きくなった物理セクターを使用するということは、ディスクのレイアウトやシステムのパフォーマンスに影響をもたらします。この記事ではその影響について、一般的な Linux® ファイルシステムに考えられる実際の影響を示すベンチマーク・テストを交えて検討します。2010年以降、4096 バイトのセクターを使用するディスクが普及するにつれ、これらの新しいディスクに対処するためのストラテジーがますます重要になってくるはずです。

Roderick W. Smith, Consultant and author

Roderick Smith author photoRoderick W. Smith はコンサルタントであり、『The Definitive Guide to Samba 3』、『Linux in a Windows World』、『Linux Professional Institute Certification Study Guide』など、UNIX や Linux に関する数々の著作もあります。彼は現在、ロードアイランドのウーンソケットに住んでいます。



2010年 4月 27日

4096 バイトのセクターに変更する理由

Roderick の他の記事も読んでください

Roderick が書いたすべての developerWorks 記事を閲覧してみてください。または、広範な技術ライブラリーでお気に入りの著者または興味のあるトピックを検索することもできます。製品、トピック、またはコンテンツのタイプを基準にして簡単に検索結果を絞り込めます。

ハード・ディスクの構造を十分に理解している読者の方は、ディスクは通常 512 バイト単位のセクターに分割され、読み取り操作や書き込み操作はこのセクター・サイズの倍数を単位に行われることはご存知のはずです。さらに細かく見てみると、ハード・ディスクはセクターだけでなく、実際にはセクターとセクターの間にもかなりのデータを記録しています。これらの追加のバイトは、ディスクのファームウェアが各セクター内でエラーを検出し、修正するために使用されます。ハード・ディスクの容量が増えるにつれ、ディスクの 1 平方センチメートルあたりに保管しなければならないデータの量はますます増加し、それに伴い下位レベルのエラーが増え、ファームウェアのエラー修正機能が酷使される結果となっています。

この問題を回避する 1 つの方法は、セクターのサイズを 512 バイトから拡大し、より強力なエラー修正アルゴリズムを使用できるようにすることです。こうしたアルゴリズムでは、問題の修正に使用する 1 バイトあたりのデータが少なくなり、しかも 512 バイトのセクターで考えられる問題より重大な問題を修正することができます。したがって、セクター・サイズを大きくすることにより、少なくとも理論上は 2 つの実用上のメリットがもたらされます。1 つは信頼性の向上、もう 1 つはディスク容量の増加です。

エンド・ユーザーが実感できるメリットは、モニターのサイズが大きくなったり、中央演算処理装置 (CPU) の処理速度がアップしたりした場合に得られるメリットのようには明らかではありません。けれども、パリティー専用のスペースが減ることによって、さらに大容量のディスクの導入が促進される結果になったり、ディスクの信頼性が向上する結果になったりすることが考えられます。

残念ながら、ソフトウェア・チェーン全体にわたって、BIOS (Basic Input/Output System) やブート・ローダー、そしてオペレーティング・システム・カーネル、ファイルシステム・コード、ディスク・ユーティリティーなどのツールでは 512 バイトのセクター・サイズが想定されています。セクター・サイズを4096 バイト単位に変更するという計画はこの 10 年ほどありましたが、一部のツールはその変更に対応する準備ができていません。問題が頻繁に発生する例として引き合いに出されるのは Microsoft® Windows® XP ですが、Linux の世界でも、最近になってようやく問題が修正されるようになってきたばかりです。

初期の頃の 4096 バイト・セクターを使用するディスクでは、新しいセクター・サイズに移行しやすいように、各物理セクターを 512 バイト単位の 8 つの論理セクターに変換しています。そのため、ディスクのベースとなる物理セクターのサイズは 4096 バイトであっても、BIOS やオペレーティング・システム、そしてすべてのディスク・ユーティリティーには、512 バイトのセクターであるかのように映ります。そのようなディスクを最初にリリースしたのは、Western Digital です。Western Digital では、4096 バイトの物理セクターをソフトウェアによって 512 バイトの論理セクターに変換するディスクを、Advanced Format という言葉で表しています。この記事では、Western Digital のディスク、そしてこれと同じような技術を使用して他のハード・ディスク・メーカーが将来リリースするディスクとを両方併せて Advanced Format と呼ぶことにします。


パフォーマンスに影響する理由

残念ながら、ファームウェアで見掛けのセクター・サイズを変更すると、パフォーマンスが劣化する恐れがあります。その理由を理解するには、ファイルシステムのデータ構造と、ハード・ディスクでのパーティションの配置について理解する必要があります。

最近のファイルシステムのほとんどは、サイズが 4096 バイト以上のデータ構造を使用するため、大部分のディスク入出力操作はこの値の倍数で行われます。ここで、Linux がこのようなサイズのデータ構造の読み取りまたは書き込み操作を、4096 バイトのセクターを使用した新しいディスクで行うとしたらどうなるか考えてみてください。ファイルシステムのデータ構造が、ベースとなっている物理パーティションのサイズとぴったり合っているとしたら、4096 バイトのデータ構造の読み取り/書き込み操作は、単一のセクターの読み取り/書き込みとなるため、ハード・ディスクのファームウェアが特別な作業を行う必要はありません。けれどもファイルシステムのデータ構造が、ベースとなっている物理セクターと完全に揃うように配置されているのでなければ、読み取り/書き込み操作は 2 つの物理セクターにアクセスする必要があります。これが読み取り操作であれば、2 つの物理セクターにアクセスするために追加で必要となる時間はほとんど、あるいはまったくありません。ディスク上の読み取り/書き込みヘッドは連続する 2 つのセクターにまたがっているのが通常なので、ファームウェアは不要なデータを破棄すればよいだけのことだからです。その一方、物理パーティションと位置が揃っていないデータ構造の書き込み操作の場合は、ディスクのファームウェアが最初に 2 つのセクターを読み取り、両方のセクターの一部を変更してから 2 つのセクターを書き込まなければなりません。この操作には、その 4096 バイトが 1 つのセクターだけを占有している場合よりも時間がかかります。そのため、パフォーマンスが劣化するというわけです。

データ構造が適切に配置されるかどうかを判断するにはどうすればよいのでしょうか。ほとんどのファイルシステムは、データ構造を、そのデータ構造を含めるパーティションの開始位置に揃えます。つまり、パーティションの開始位置が 4096 バイト (8 セクター) の境界であれば、データ構造は適切に配置されることになります。しかし最近まで、Linux パーティショニング・ツールの大部分が作成するパーティションは 4096 バイトの境界に位置合わせされていませんでした。一般的な Linux パーティショニング・ソフトウェアでパーティションを位置合わせする方法については、この後の「パーティションの位置合わせ」のセクションで説明します。


ベンチマークの結果

適切なパーティションの位置合わせが、なぜそれほど重要になるのか不思議に思われるかもしれません。その質問に答えるため、位置合わせしたパーティションと位置合わせしていないパーティションの両方を使った 1TB の Western Digital WD-10EARS Advanced Format ドライブを複数の Linux ファイルシステムで使用してみました。ディスクは GPT (GUID (Globally Unique Identifier) Partition Table) システムを使用してパーティション化し、位置合わせしたパーティションは論理セクター 40 から始まり、位置合わせしていないパーティションは論理セクター 34 (デフォルトのパーティション・テーブル・サイズの GTP ディスクで最初に使用できるセクター) から始まっています。テストしたファイルシステムは、ext3fs、ext4fs、ReiserFS (バージョン 3)、JFS、XFS、および Btrfs です。コンピューターは 64 ビットの 2.6.32.3 Linux カーネルを実行しました。

スクリプトで実行した一連のディスク入出力操作には、新規ファイルシステムの作成、Linux カーネル tarball のテスト・ドライブへの解凍、ドライブへの tarball のコピー、テスト・ドライブでの解凍直後のファイルの読み取り、ドライブからの tarball の読み取り、そして Linux カーネル・ディレクトリーの削除が含まれます。ソースとする Linux カーネル tarball は別のディスクに保管し、読み取りテストでは出力先を /dev/null に指定しました。また、書き込みテストを行うごとに、テスト・ディスクはアンマウントしました。これは、Linux のディスク・キャッシュに残っている操作がないことを確実にするためです。ここで報告する数値には、このアンマウント操作にかかった時間も含まれます。カーネル tarball のサイズは 365MB です。これは、ディスクのキャッシュ・サイズ 64MB を大幅に超えています。各テスト・シーケンスは、それぞれのファイルシステムに対して 6 回実行しました。そのうち 3 回は正しく位置合わせされたパーティションで実行し、残りの 3 回は正しく位置合わせされていないパーティションで実行しましたが、それぞれの実行結果の差はわずかでした。位置合わせされていないパーティションでの平均時間を、位置合わせされたパーティションでの平均時間で割り、正しく位置合わせされていない場合のパフォーマンス・ヒットの比率を算出しています。値が 1.00 を超える場合は、パーティションが正しく位置合わせされていないとパフォーマンスが低下することを意味します。

テストの多くでは、それほど大きなパフォーマンスの劣化は見られませんでした。ファイルシステムを作成する場合のテストで出た結果は、最小値が 0.96 (XFS の場合) で最大値は 7.94 (ReiserFS の場合)、平均値は 2.79 です。しかし、ファイルシステムの作成はまれにしか行われないため、この影響はそれほど大きくはありません。読み取りテストの結果、比率は 0.95 から 1.25 となり、速度に与える影響は 25% を超えないことを示しています (図 1 を参照)。1.00 の場合、パーティションが位置合わせされていなくてもパフォーマンスが劣化しないことを意味し、値が大きければ大きいほど、それだけパフォーマンスが劣化することを意味します。

図 1. 位置合わせされていないパーティションを使用した場合の読み取り操作のパフォーマンスの劣化
位置合わせされていないパーティションを使用した場合、読み取り操作のパフォーマンスが 5% から 15% 劣化することを示す棒グラフ

大きなファイルの書き込み操作のパフォーマンスも、わずかな影響しか受けませんでした。この場合の最小値は 1.10 (XFS および JFS の場合)、最大値は 6.02 (ReiserFS の場合) で、平均値は 2.10 です。ReiserFS の値が大きいのは、このファイルシステムはパーティションの位置合わせの影響を受けやすいことが主な理由となっています。ReiserFS を抜かした残り 5 つのファイルシステムでの平均値は 1.31 です。ファイルを削除する場合の影響はさらに小さくなり、結果は 1.04 (XFS の場合) から 4.78 (JFS の場合) までの範囲で、平均値は 1.97 です。JFS を外れ値として除外すると、平均値は 1.40 となります。

書き込み操作でパフォーマンスに最も大きな影響が出てくるのは、小さなファイルを作成する場合です (カーネル tarball の解凍)。tarball 解凍での影響は 1.04 (ext4fs の場合) から 25.53 (ReiserFS の場合) に及び、平均値は 10.9 となります。このテストで 2 番目に優秀なパフォーマンスを見せたのは、1.82 の値を出した XFS でした。これらの値は位置合わせしていない場合と位置合わせした場合の比率なので、10.9 という値は、正しく位置合わせされたパーティションでは 10 秒間で行われる tarball 解凍操作が、正しく位置合わせされていないパーティションでは 109 秒かかることを意味します。これはかなりの違いです。具体的な例で言うと、XFS の値は 1.82 なので、正しく位置合わせされたパーティションでは解凍操作に 10 秒かかる場合、正しく位置合わせされていないパーティションでは 18.2 秒かかることになります。

図 2 に、すべてのファイルシステムでの書き込み操作のパフォーマンス・ヒットを要約します。前と同じく、値が 1.00 の場合、パフォーマンスの劣化はないことを意味し、値が大きければ大きいほど、それだけパフォーマンスが劣化することを意味します。

図 2. 位置合わせされていないパーティションを使用した場合に生じる書き込みパフォーマンスの劣化
位置合わせされていないパーティションを使用した場合、書き込みパフォーマンスが劣化することを示す棒グラフ

注意する点として、これらのテストはファイルシステムでの全体的なパフォーマンスを反映していません。したがって、いくつかの操作でのパフォーマンスに最大の差が出ているからと言って、ReiserFS が最もパフォーマンスが悪いと結論付けることはしないでください。ただし、ReiserFS は他のどのファイルシステムよりもパーティションの位置のずれに影響されやすいことは確かです。

パーティション構成のファイルシステムのテストとは別に、LVM 構成のファイルシステムで、LVM パーティションが正しく位置合わせされている場合と、正しく位置合わせされていない場合とでの抜き取り検査を行いました。その結果は、パーティションをそのまま使った場合のテスト結果と同様でした。

以上のことから実用上の問題として言えるのは、まずはディスクの物理セクターのサイズを判別しなければならないということです。Advanced Format ドライブを使用していることがわかったら、パーティションを正しく位置合わせする必要があります。


物理セクターのサイズを判別する方法

理論上、Linux カーネルは物理セクター・サイズの情報を /sys/block/sdX/queue/physical_block_size 擬似ファイルに返し、論理セクター・サイズの情報を /sys/block/sdX/queue/logical_block_size 擬似ファイルに返します (ここで、sdX はデバイスのノード名 (通常は sda、sdb などの名前) です)。けれども実際には、物理ブロック・サイズの情報は、少なくとも Western Digital Advanced Format ドライブの第 1 世代では当てになりません。残念ながら、ディスク・ユーティリティーはこのようなディスクの存在を正しく検出できないということです。

実際のところ、物理セクターのサイズを知るには、ハード・ディスク・メーカーの Web サイトや他の何らかの手段でドライブの仕様を調べなければなりません。/sys/block/sdX/device/model 擬似ファイルにデバイスの型番が記載されているので、型番を調べた上で、メーカーに確認してください。

現行の第 1 世代の Advanced Format ドライブの場合、Western Digital は Advanced Format ドライブであることを示すステッカーを貼っています。これらのステッカーは、Advanced Format ドライブが問題になるのは Windows XP だけであることをほのめかしていますが、上記のベンチマークの結果から明らかなように、Linux ユーザーも Advanced Format ドライブには十分注意する必要があります。


パーティションの位置合わせ

RAID パーティションの位置合わせ

RAID (Redundant Array of Independent Disks) レベル 5 およびレベル 6 にも、Advanced Format ドライブと同じような位置合わせの問題がありますが、その原因は、配列を作るときに用いられるデータ・ストライプのサイズ (通常は 16KB から 256KB) に関連しています。RAID 配列を使用するときには、ストライプ・サイズの倍数でパーティションを位置合わせしてください。新しい標準となってきているデフォルトの 2048 セクター (1024KB) での位置合わせは、一般的なすべての RAID ストライプ・サイズに有効です。

公開されているテスト結果には、正しく位置合わせされていない場合のパフォーマンスは約 5% から 30% 劣化することが示されています。これは、Advanced Format ドライブの場合のパフォーマンス劣化に比べ、はるかに小さな規模です。Advanced Format ディスクから RAID 配列を作成する場合、追加手順は必要ありません。RAID の位置合わせの値は、Advanced Format ドライブでの位置合わせに使用しなければならない 4096 バイトの倍数です。したがって、512 バイトの物理セクターを使用するディスクの RAID 配列に関してパーティションを位置合わせする場合、両方の技術のニーズは一致します。

現行の Western Digital ドライブには、Windows XP に対応するように設定できるジャンパーが組み込まれています。このジャンパーにはセクター番号を 1 だけシフトさせる効果があるため、(シリンダーの位置合わせの場合に) セクター 63 から始まるものとしてコンピューターが認識するパーティションは、実際には論理セクター 64 に配置されます。これは、Windows での一般的なパーティション構成 (ドライブ全体を 1 つのパーティションとして使用) で生じるセクターの位置合わせ問題に対する、まにあわせ的な修正措置です。残念ながら、複数のパーティションを作成すると、最初のパーティション以外のパーティションはすべて位置がずれることになります。したがって、ほぼ間違いなくこのジャンパーを使用するべきではありません。代わりに、Linux パーティショニング・ソフトウェアを使って正しく位置合わせされたパーティションを作成してください。

Linux では、それぞれに独自の方法でパーティションを位置合わせする、よく知られた 3 つの MBR (Master Boot Record) および GPT パーティショニング・ツール・ファミリーを使用することができます。Advanced Format ドライブを使用している場合には、最新の Linux パーティショニング・ソフトウェアを実行することが最善の選択肢です。

ヒント: Linux と、シリンダーの位置合わせが必要な古いオペレーティング・システムとの間でデュアルブートを行いたい場合には、すべてのパーティションの開始位置を 8 の倍数シリンダーに合わせるようにしてください。この位置合わせは、最適なディスク・パフォーマンスを得るため、そして古いオペレーティング・システムでのシリンダーの位置合わせに対応するために 8 の倍数セクターでの位置合わせに変換されます。

fdisk ファミリー

ほとんどのディストリビューションで util-linux-ng パッケージに含まれている fdisk ファミリーでは、かなり直接的に MBR データ構造を編集することができます。しかしその一方で、ファイルシステムを作成または変更することはできません。util-linux-ng 2.17 までの fdiskは、8 の倍数セクターでのパーティションの位置合わせを直接サポートしません。また、少なくともバージョン 2.17.2 (この記事を書いている時点で最新のバージョン) までは、デフォルトの位置合わせはシリンダー・ベースのままになっています。

ただし、どのバージョンの fdisk でも、パーティションを正しく位置合わせすることは可能です。それにはメイン・メニューで u と入力し、デフォルトの単位をシリンダーからセクターに変更してください。このように変更すれば、8 の倍数で開始セクターの値を入力できるようになります。原則としては、パーティションを正しく位置合わせするために最初のパーティションの開始セクター番号を 8 に設定することもできますが、最善の策は、最初のパーティションの開始セクターは 64 以降の番号に設定し、MBR と最初のパーティションとの間の未割り当てのスペースにブート・ローダー・コード用のスペースを残しておくことです。Windows Vista および Windows 7 対応の Microsoft のパーティショニング・ツールは最初のパーティションをセクター 2048 で開始するので、クロスプラットフォームの観点からすると、開始セクターは 2048 に設定するのが無難です。実際、util-linux-ng 2.17.1 からは、メイン・メニューで c と入力して DOS 互換性モードを無効にすると、開始セクターはデフォルトで 2048 に設定されるようになっているので、この方法に従うことをお勧めします。

注意する点として、fdisk は以降のパーティションを自動的に位置合わせしません。パーティションのサイズをメガバイト単位やそれ以上の大きさで指定し、後続のパーティションにはデフォルトの値を受け入れると正しい位置に合わせられるはずですが、保証はされません。念のため、すべてのパーティションが 8 の倍数で開始されることを確認してください。

fdisk でのもう 1 つの方法は、これを fdisk -H 224 -S 56 /dev/sda と実行することです。こうすれば、fdisk はシリンダーを位置合わせするときに、デフォルトでの場合と同じく、cylinder/head/sector (CHS) ジオメトリーを変更して正しい 4096 バイト単位の位置に合わせることを保証します。

libparted ライブラリー

libparted ライブラリーは、ファイルシステムの操作をサポートする多くの Linux パーティショニング・ツールのベースとなっているライブラリーです。バージョン 2.1 までは、テキスト・モードの GNU Parted プログラム (コマンド名 parted) は、シリンダー境界以外での位置合わせに対するサポートをほとんど提供していません。そのため、最善の方法としては、unit s と入力して、デフォルトの単位をセクターに変更することが考えられます。このように変更すれば、手動でパーティションの開始位置をセクター単位で入力することで、正確なパーティションの開始位置を確認することができます。

バージョン 2.2 からは、4096 バイトの物理セクターを使用するディスクに有用なポリシーへの移行が開始されています。このバージョンでは、1M の開始値を指定するとセクターが正しく位置合わせされます。また、バージョン 2.2 はパーティションが正しく位置合わせされていないと警告を出すようにもなっています。

GUI GParted プログラムを使用する場合には、「Create New Partition (新規パーティションの作成)」ダイアログ・ボックスの「Round to cylinders (シリンダー単位に丸める)」チェック・ボックスのチェック・マークを必ず外してください (図 3 を参照)。パーティションの開始セクターは前のパーティションの終了位置に相対して設定しなければなりませんが、正しく位置合わせされたパーティションで開始すれば、それですべてが上手くいくはずです。パーティションの情報に関するダイアログ・ボックスを表示すると、パーティションの開始セクターと終了セクターの絶対位置を調べることができます。

図 3. GParted を使用するときには「Round to cylinders (シリンダー単位に丸める)」チェック・ボックスのチェック・マークを外すこと (この図ではチェック・マークが付いたデフォルトの状態になっています)
GUI GParted ツールの「Create new Partition (新規パーティションの作成)」ウィンドウ。最適なパフォーマンスを得るためには、シリンダーに位置合わせするためのチェック・ボックスからチェック・マークを外してください。

GPT fdisk ユーティリティー

GPT fdisk ユーティリティーが役立つのは、GPT ディスクだけです。0.5.2 より前のバージョンは位置合わせを一切行いません。ただし、適切な開始セクター番号を手動で指定することで、パーティションを位置合わせすることはできます。バージョン 0.5.2、およびバージョン 0.6.0 から 0.6.5 までは、大容量のディスク (約 800GB を超えるディスク) については、すべてのパーティションの開始セクターを 8 の倍数セクターの境界に調整しますが、容量の小さいディスクに対してはこの調整を行いません。バージョン 0.6.6 では、パーティション化されていないすべてのディスクに対し、Windows スタイルの 2048 セクター (1MB) の位置合わせを導入し、すでにパーティション化されているディスクに対しては、過去に使用されていた配置を推測しようと試みます。

バージョン 0.5.2 以降は、エキスパート・モードのメニューで l オプションを使用することにより、手動で位置合わせの値を調整できるようになっています。このオプションは、セクターの数をオプションとして取ります。Advanced Format ディスクで正しく位置合わせするには、セクターの数を 8 または 8 の倍数に設定してください。検証オプション (任意のメニューで v を指定) を使用すると、現在の位置合わせの値を基に、正しく位置合わせされていないパーティションがレポートされます。


今後の見通し

現時点で入手可能な Advanced Format ハード・ドライブ・モデルはほんのわずかですが、報道によると、この技術は 2010年以降、主要なすべてのハード・ディスク・メーカーのより多くのドライブで使用されるようになるということです。新しいモデルには、第 1 世代の Advanced Format ドライブとはまた別のパフォーマンス問題が発生することも考えられます。

最終的には、ハード・ディスク・メーカーは 512 バイト単位のセクターのディスクを作成するのをやめるか、あるいはユーザーがこの 512 バイト単位のセクターへの対応を選択できるようにするジャンパーを提供することになるかもしれません。ディスクのセクター・サイズが 4096 バイトで、オプションでこの実際のセクター・サイズを使用できるようになっている場合、そのオプションを使用したいと思うかもしれません。しかし、それに伴ういくつかの問題について十分考慮してください。

問題の 1 つは、前述のとおり、BIOS をはじめとするソフトウェアはハード・ディスクのセクター・サイズを想定して作成されていることです。BIOS でセクター・サイズが想定されている場合、コンピューターは 4096 バイトのセクターを使用するディスクからブートしない可能性があります。その場合、ファームウェアは 512 バイト単位のセクターへの変換を行いません。バージョン 2.2 の GNU Parted を 4096 バイトのセクターを使用するディスクで起動すると、512 バイト以外のセクターを使用しているディスクのサポートは実験段階であるという警告が表示されます。他にも、ソフトウェアに重要な問題が潜んでいる可能性がありますが、最新のソフトウェアを使用することで、問題の回避に役立つ場合があります。最新のソフトウェアでは、従来のディスクがブート・ディスクとして使用されるように、この新しい技術のディスクをデータ・ディスク (/dev/sdb 以上のレベル) としてのみ使用するためです。

概して、これまでにない新しいディスクを扱う場合には注意が必要ですが、そうは言っても、この現在の Advanced Format ディスクのスタイル、そして他の新しいタイプのドライブでの問題は比較的早いうちに解決されることになるでしょう。

参考文献

学ぶために

製品や技術を入手するために

  • GNU Parted の Web サイトでは、テキスト・モードの GNU Parted とその親ライブラリーである libparted をホストしています。GNU Parted は、成熟したテキスト・モードの MBR および GPT パーティショニング・ツールです。
  • Linux の fdisksfdisk、および cfdiskutil-linux-ng パッケージに含まれています。
  • GNOME Partition Editor (別名 GParted) は、libparted をベースにした GUI パーティショニング・ツールです。
  • GPT fdisk プログラムは Linux の fdisk をモデルにした GPT 専用のパーティショニング・プログラムです。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=493253
ArticleTitle=4KB セクター・ディスクで Linux を使用する: 実用的なアドバイス
publish-date=04272010