web-dev-qa-db-ja.com

Linuxで931.5 GiB外部AdvancedFormatHDDの複数のパーティションの最適な配置を理解する際の問題

[〜#〜]要約[〜#〜]

1TBの内部ディスクを搭載したDellInspiron 17-5767ラップトップを持っていますが、最初に出荷されたWindows 10が引き続き所有し、すべてを支配することを許可しました(これは私のゲームOSです)。さらに、2つの外付けドライブがあり、そこから現在および将来のLinuxOSを起動します。私の現在の設定は次のとおりです。

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

[〜#〜]目標[〜#〜]

/ dev/sdbドライブの/ dev/sdcで行っているようなものを複製しようとしていますが、5つのLinuxディストリビューションを使用しています。私は経験豊富なマルチブーターなので、プロジェクトのその側面について説明しました。しかし、私の目標の他の部分は、/ 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ユーティリティは512のブロックサイズを想定していることがわかります。これは、最適なIO間隔を計算するとき

(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval

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

(33553920 + 0) / 512 = 65535.

ただし、partedは当然のことながら4096ブロックサイズを使用できません。その場合、方程式は次のようになります。

(33553920 + 0) / 4096 = 8191.875.

その答えは高校の代数の教師を満足させるでしょうが、離散値(つまり整数!)を期待するセクター間隔としては明らかに意味がありません。いずれにせよ、私は12個のパーティションを作成したいので、そのうちのいくつかは256MiBのサイズであるため、GNUパーセンテージを使用して分割し、簡単に言えば私は'unit s'に固執し、モジュラー演算を自分で実行して、パーティションが65535秒間隔で開始されるようにするために、align-checksを満たすことができます。私の調査によると、次のようには思われませんでした。パーティションもこれらの間隔で終了するようにすることが重要であるため、ほとんどのパーティション間にギャップ(明らかに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.

だから、別れたものが好きなのに、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

したがって、mkswapは、partedがディスクが最適に整列されているか最小に整列されていると見なすかどうかに関係なく、スワップボリュームが整列していないことを検出します。また、mkswapは、fdiskが整列に満足しているかどうかに関係なく、スワップボリュームが整列していないことも検出します。

[〜#〜]理論[〜#〜]

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

何が起こっていても、パーティションが最適に調整され、mkswap、または少なくとも私が本当に最も信頼すべきユーティリティが調整について不平を言うのをやめたら、実際のLinuxインストールを進めて幸せになります。

[〜#〜]ヘルプ[〜#〜]

なぜ私がpartedや他のディスクユーティリティが最小アライメント(gPartedまたはgdiskのいずれかでパーティション化した場合にのみ達成される)以上のものに同意できないように見える理由を理解するのを手伝ってください、そして私が本当に心配しすぎるべきかどうかについて私にアドバイスしてください私の場合、最小の配置よりも最適な配置の利点についてです。パフォーマンスやディスクの状態にわずかな違いがあったとしても、それ以上の時間を無駄にすることはありません。それ以外の場合は、ディスクの高度なフォーマットの利点を最大限に活用できるようにしたいと思います。

1
gluonman

あなたがまだ奇妙な数65535sによって混乱している場合に備えて。私も最近この質問に混乱しています。私は答えを探して、これに出くわしました: http://gparted-forum.surf4.info/viewtopic.php?id=17839

簡単に言うと、HDがusb-sataアダプターを使用してPCに接続されている場合、optimal_io_sizeは無効になる可能性があります。

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

1
McDull Hall