web-dev-qa-db-ja.com

ストレージデバイスの配置-最適に配置された32MiBの後続のパーティションの配置を計算します

概要

通常の_32MiB_(_65535_)ではなく、最適に整列された_1MiB_(_2048 sector_セクター)の後続のパーティションの整列を計算する方法を理解しようとしています。

バックグラウンド

最近SAMSUNG SSD 850 EVO (M.2 1TB)を購入しました。

_# cat /sys/block/sdx/queue/optimal_io_size
> 33553920
# cat /sys/block/sdx/queue/minimum_io_size
> 512
# cat /sys/block/sdx/alignment_offset
> 0
# cat /sys/block/sdx/queue/physical_block_size
> 512
# cat /sys/block/sdx/queue/logical_block_size
> 512
# cat /sys/block/sdx/queue/hw_sector_size
> 512

# fdisk -l
> Disk /dev/sdx: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 33553920 bytes
> Disklabel type: gpt
_

最初のセクターの計算は難しくありません。

アライメントを自動的に計算するためにGNU parted

_(parted) mkpart primary 0% 100%
_

結果は、セクター_65535_(_32MiB_)で始まるアライメントです。

アライメントを手動で計算する

_(optimal_io_size + alignment_offset) / physical_block_size
_

SAMSUNG SSD 850 EVO (M.2 1TB)のデータを使用し、式を適用すると、次のようになります。

_(33553920 + 0) / 512 = 65 535
_

問題

通常、パーティションを作成するときは、前のパーティションの_offset + length_を次のパーティションの開始として追加しました。たとえば、

_(parted) mkpart primary 1MiB   2MiB
(parted) mkpart primary 2MiB   514MiB
(parted) mkpart primary 514MiB 1538MiB
...
_

SAMSUNG SSD 850 EVO (M.2 1TB)について同様のことを試みています

_(parted) mkpart primary 65535s 67582s  # OK ~32MiB 33MiB
(parted) mkpart primary 67583s 100%
or
(parted) mkpart primary 33MiB 100%
_

次の警告が表示されます。

_Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel?
_

療法

ドライブはかなりうるさいです、そして私の最善の試みは正確なセクターを計算することでした。残念ながら、これにより計算が複雑になり、パーティションが最適に配置された理由を説明できません(_align-check optimal <partition number>_)。

_(parted) unit s
(parted) print free
Number  Start        End          Size         File system  Name  Flags
        34s          65534s       65501s       Free Space
 1      65535s       67582s       2048s
        67583s       131069s      63487s       Free Space
 2      131070s      1179645s     1048576s
        1179646s     1245164s     65519s       Free Space
 3      1245165s     9633772s     8388608s
        9633773s     9699179s     65407s       Free Space
 4      9699180s     1953467279s  1943768100s
        1953467280s  1953525134s  57855s       Free Space
_

私が知る限り、各セクターは_65535_間隔で開始する必要があります。これは、〜32MiB(または_65535+1 = 32MiB_)に対応します。バイトオフセットは_0_ではなく_1_であると想定しています。与えられた_1MiB = 2048s_。

最初のパーティションサイズは_1MiB_であるため、停止は_65535 + 2048 - 1 = 67582_です。

_(parted) mkpart primary 65535s 67582s
_

前のパーティションが_32MiB_の下にある場合、次のパーティションは単に_previous partition offset + 32MiB_で始まります。上記の分割された例のパーティション_2_の場合、それは_~64MiB_(_65535s * 2 = 131070s_)で始まります。サイズは_512MiB_(_512 * 2048 = 1048576_)であるため、ストップは_131070 + 1048576 - 1 = 1179645_です。

_(parted) mkpart primary 131070s 1179645s
_

これまでのところ良好ですが、パーティション_3_の最適な開始点は何でしょうか。最初に利用可能な32MiB間隔はどのオフセットですか?

_1179645 / 65535 ~= 18,000223
_

現在18インターバルを使用しており、19日にスピルオーバーします。したがって、次のパーティションは19番目の間隔で開始する必要がありますか?

_19 * 65535 = 1245165
_

サイズは_4096MiB_(_4096 * 2048 = 8388608_)であるため、ストップは_1245165 + 8388608 - 1 = 9633772_です。

_(parted) mkpart primary 1245165s 9633772
_

したがって、次のパーティションでは

_9633772 / 65535 ~= 147,0019
148 * 65535 = 9699180
_

などなど。

これについての議論はこれまで見たことがなく、パーティショニングを複雑にしすぎているように感じます。

3
user212827

GPT fdisk Tutorialgdiskを使用すると、たとえば、プレフィックスが+の場合、後続のパーティションの配置が自動的に計算されます。

Last sector (8390656-15634398, default = 15634398) or {+-}size{KMGTP}: +2G

最後に提供されたセクターから2GiB(ギビバイト)を作成します。

パーティションは2048sに配置されます。 GNU partedは、パーティションがalign-check minimalであることを確認しますが、align-check optimalではないことを確認します。

blockdev --getalignoff /dev/sdx0を返します。

2
user212827

この最適なI/Oサイズは間違っており、バグは buntu上redhat上 のように何度も参照されます。より有益なのは このブログページ かもしれません。

いずれにせよ、この65535は2バイトの最大値にすぎず、4または8 X512バイトのセクターにさえ整列しません。カーネル、parted、lvmが誤ってフォローしています。それに従おうとしないでください。

2
marcz

SSDをERASEBLOCKおよびNANDPAGESIZEに沿って配置することが重要であると言う人もいます。

evo 840には、珍しい消去ブロックとnandパラメーターがあるようです:1536kbと8k 850についてはよくわかりません(samsungはこの情報(企業秘密)の公開に消極的です)...

私は、すべての既知のssdとそれらの消去ブロックおよびnandページサイズをカバーするユニバーサルアライメント値を考え出しました。 6291456バイトのオフセット(セクター12288(6144kb = 6mb)または任意の倍数(12mb、18mb、24mbなど)を使用することをお勧めします。このオフセットは、既知のssd(またはhdd)で機能するはずです。NANDによって異なります。扱っているページサイズREADMODIFY WRITEの問題を回避するために、フォーマット中に可能な場合はアロケーションユニットサイズをNANDページサイズに一致させることをお勧めしますが、必要に応じて、ほとんどすべてのssdで4kも許容値になるはずです。内部でオーバープロビジョニングされています。書き込み増幅の問題を回避するために、ディスクの10%をフォーマットせずに残します(17%OPのままにします)。また、特定のパラメーターを決定した場合は、「クイックフォーマット」を使用しないことをお勧めします。 "オプション、通常のフォーマットを実行します。SSDの場合、それほど時間はかかりません。これが役立つかどうかをお知らせください。お気軽にアイデアを追加してください。..

PS私は別れを使用するのが面倒でgdiskを好むと思います。 gdiskでは、xpertメニューの「l」を使用して「セクターアライメント値の設定」を設定できます。これを行うと、作成されたすべてのパーティションが自動的に計算され、その値の最も近い倍数から開始されます。その結果、指定された値が正しければ、すべてのパーティションが適切に配置されます。

1