☰

Linux で 931.5 GiB の外付け Advanced Format HDD 上の複数のパーティションの最適な配置を見つけるのに苦労する

tag-icon • tag-icon linux partitioning alignment advanced-format parted
Linux で 931.5 GiB の外付け Advanced Format HDD 上の複数のパーティションの最適な配置を見つけるのに苦労する

まとめ

私は 1TB の内蔵ディスクを搭載した Dell Inspiron 17-5767 ラップトップを所有しており、元々出荷された Windows 10 が引き続き独占的に使用することを許可しています (これは私のゲーム用 OS です)。さらに、現在および将来の Linux OS を起動する 2 つの外付けドライブがあります。現在の設定は次のとおりです。

  1. USB 3.0 ポート #0: Seagate Expansion+ 931.5 GiB (1000204885504 バイト) 外付け HDD が /dev/sdb として認識されました
    • 現在、1 つのフルサイズの空の ext4 パーティションを格納していますが、これを 12 個のパーティションの最適に整列されたパーティション スキームに置き換えるのに苦労しています (苦労のポイントは、整列です)。
  2. USB 3.0 ポート #1: 238.5 GiB (256060514304 バイト) Samsung SSD 840 Pro は /dev/sdc として認識されます
    • Fedora LiveCD のインストーラー (「カスタム」オプション付き) を使用してパーティション分割され、共有スワップ領域、共有ユーザー領域、個別のルート、個別の外部ブート パーティション (ここでの外部とは、LVM ではなく、同じディスク上の別の場所にある独自の個別のプライマリ パーティションを意味します) を含む単一の LVM 内に、Fedora LXDE と Lubuntu Linux ディストリビューションの両方が格納されています。
    • このドライブは、物理ブロック サイズと論理ブロック サイズの両方が 512 で、parted の「align-check opt x」ユーティリティによると最適にアラインされており、fdisk もアラインメントに満足しています (どのユーティリティからもアラインメントに関する苦情はありません)。
  3. UEFI BIOSは内部より先にUSBから起動しようとするので、利用可能なすべてのオプションとともにgrubがポップアップ表示されます。

ゴール

私は、/dev/sdb ドライブの /dev/sdc で実行しているのと同じようなことを、5 つの Linux ディストリビューションで再現しようとしています。私は経験豊富なマルチブート ユーザーなので、プロジェクトのその側面についてはカバーしています。しかし、私の目標のもう 1 つの部分は、/dev/sdc の場合と同じように、/dev/sdb のパーティションを最適に配置することです。ここで問題が発生しています。

環境

私は現在、比較的新しくアップグレードした Fedora LXDE のインストール内で作業していますが、得られた結果は、同様に比較的新しくアップグレードした Lubuntu のインストールでも完全に再現可能です。

報告されたディスクパラメータ

[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size 
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size 
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size 
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size 
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset 
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C

Device     Start        End    Sectors   Size Type
/dev/sdb1  65535 1953467279 1953401745 931.5G Linux filesystem

Partition 1 does not start on physical sector boundary.
[root@frank ~]#

問題

したがって、物理ブロックサイズの報告に基づくと、下位互換性のために論理セクターサイズが512bであるにもかかわらず、ディスクは他のドライブのように512bではなく4k（アドバンスドフォーマット）であるように見えます。GNU partedユーティリティは、最適なIO間隔を計算するときにブロックサイズを512と想定していることがわかります。

(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval

65535 という値を取得し、そこから自動的に最初のパーティションが開始されます。align-check サブユーティリティがパーティションの配置を最適と判断する唯一の方法は、65535 の倍数で開始する場合です。parted の結果が意味を成す唯一の方法は、physical_io_size を 4096 ではなく 512 として扱っていることを考慮することです。

(33553920 + 0) / 512 = 65535.

しかし、partedは4096ブロックサイズを使用することができないのは当然です。なぜなら、その場合、方程式は次のようになるからです。

(33553920 + 0) / 4096 = 8191.875.

この答えは高校の代数の先生なら納得するでしょうが、離散値（つまり整数）が期待されるセクター間隔としては明らかに意味をなさないものです。いずれにせよ、私が作りたいのは 12 個のパーティションで、そのうちのいくつかは 256MiB ほど小さいサイズなので、GNU Parted でパーセンテージを使ってこれを行うのは不可能です。要するに、私は 'unit s' に固執し、parted が要求したようにパーティションが 65535 間隔で始まるように自分でモジュラー演算を行うことで、最適な配置のアラインメント チェックを満たすことしかできませんでした。私の調査によると、パーティションがそれらの間隔で終わることも確実にすることはそれほど重要ではないと思ったので、ほとんどのパーティション間にギャップ（明らかに 65535 を超えない）が残りました。

もう一度、parted は結果が最適に調整されていると判断し、物理ブロック サイズを 4096 ではなく 512 として扱いました。しかし、parted を終了して 'fdisk -l /dev/sdb' を実行した後、出力に次の内容が含まれていました。

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.

つまり、parted が好むものは fdisk が好まないのです。そこで、gParted を使用してパーティション スキームをやり直し、ユニット サイズとして 1 MiB を使用するようにしたところ、他のディスク (/dev/sdc) と同じように、最初のパーティションが 2048 秒で開始されました。fdisk は満足し、セクター アラインメントに関するエラーを言わなくなりましたが、その後、GNU parted は、最小モードでは合格しますが、最適モードでのアラインメント チェック テストには合格しませんでした。

しかし、どちらの場合も、mkswap (/dev/sdb11 に配置した LVM 内にスワップ ボリュームを作成するために使用) によって次の警告が表示されたことがわかりました。

[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned

したがって、parted がディスクが最適にアラインされていると判断するか、最小にアラインされていると判断するかに関係なく、mkswap はスワップ ボリュームがアラインされていないことを検出します。また、fdisk がアラインメントに満足しているかどうかに関係なく、mkswap はスワップ ボリュームがアラインされていないことを検出します。

理論

これらすべてから、少なくとも 1 つのディスク レポート ユーティリティまたはパーティション ユーティリティからの警告を無視する必要があるという印象を受けますが、どれがそうなのかはわかりません。また、HDD を含む USB 互換エンクロージャが少なくとも 1 つのセクター パラメータを誤って報告している可能性があるため、すべてのレポートが最初から信頼できない可能性もあります。たとえば、実際には AF ドライブではないのでしょうか。または、最適な IO サイズが誤って報告されているのでしょうか。あるいは、その両方でしょうか。また、私を信じてください。これは PEBKAC のケースである可能性も考えました。4k ドライブのパーティションをアラインメントする方法について私が誤解しているだけかもしれません。よくわかりません。

何が起こっているにせよ、パーティションが最適に整列され、mkswap、または少なくとも私が最も信頼すべきユーティリティが整列について文句を言わなくなったら、実際の Linux インストールを進めることに満足するでしょう。

ヘルプ

parted や他のディスク ユーティリティで、最小アラインメント (gParted または gdisk でパーティション分割した場合にのみ達成されます) 以上の設定ができない理由を教えてください。また、パフォーマンスやディスクの状態の違いがあまりに小さい場合は、それ以上時間を無駄にしないので、私の場合、最小アラインメントよりも最適なアラインメントの利点についてあまり心配する必要はないかどうかも教えてください。そうでなければ、ディスクの高度なフォーマットの利点を最大限に活用できるようにしたいと思います。

答え1

65535 という奇妙な数字にまだ困惑している方のために。私も最近この質問に困惑しています。答えを探していたら、こんな答えを見つけました。http://gparted-forum.surf4.info/viewtopic.php?id=17839

簡単に言えば、HD が USB-SATA アダプタを使用して PC に接続されている場合、optimal_io_size が無効になる可能性があります。

解決策は、この数値を無視して、1MiB 境界の提案に従うことです。

関連情報