XFSがsunit / swidthのraid5セットアップの代わりにlvmキャッシュチャンクサイズを使用するのはなぜですか

Question

sdb、sdc、sdd、およびsdeをテストするために仮想マシンで4つのディスクを使用できます。

最初の3つのディスクはRAID5構成に使用され、最後のディスクはlvmキャッシュドライブとして使用されます。

私が理解していないのは次のとおりです。

チャンクサイズが64KiBの50GBのキャッシュディスクを作成すると、xfs_infoは次のようになります。

[vagrant@node-02 ~]$ xfs_info /data meta-data=/dev/mapper/data-data isize=512 agcount=32, agsize=16777072 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 data = bsize=4096 blocks=536866304, imaxpct=5 = sunit=16 swidth=32 blks naming =version 2 bsize=8192 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=262144, version=2 = sectsz=512 sunit=16 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

ここでわかるように、sunit = 16とswidth = 32は正しく、raid5のレイアウトと一致しているようです。

lsblk -tの結果

[vagrant@node-02 ~]$ lsblk -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 512 0 512 512 1 deadline 128 4096 0B ├─sda1 0 512 0 512 512 1 deadline 128 4096 0B └─sda2 0 512 0 512 512 1 deadline 128 4096 0B ├─centos-root 0 512 0 512 512 1 128 4096 0B ├─centos-swap 0 512 0 512 512 1 128 4096 0B └─centos-home 0 512 0 512 512 1 128 4096 0B sdb 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_0 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 65536 131072 512 512 1 128 4096 0B └─data5-data5_corig_rimage_0 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 65536 131072 512 512 1 128 4096 0B sdc 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_1 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 65536 131072 512 512 1 128 4096 0B └─data5-data5_corig_rimage_1 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 65536 131072 512 512 1 128 4096 0B sdd 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_2 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 65536 131072 512 512 1 128 4096 0B └─data5-data5_corig_rimage_2 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 65536 131072 512 512 1 128 4096 0B sde 0 512 0 512 512 1 deadline 128 4096 32M sdf 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-cache_data5_cdata 0 512 0 512 512 1 128 4096 32M │ └─data5-data5 0 65536 131072 512 512 1 128 4096 0B └─data5-cache_data5_cmeta 0 512 0 512 512 1 128 4096 32M └─data5-data5 0 65536 131072 512 512 1 128 4096 0B sdg 0 512 0 512 512 1 deadline 128 4096 32M sdh 0 512 0 512 512 1 deadline 128 4096 32M

そして、lvdisplay -a -m dataは私に次のことを与えます：

[vagrant@node-02 ~]$ Sudo lvdisplay -m -a data --- Logical volume --- LV Path /dev/data/data LV Name data VG Name data LV UUID MBG1p8-beQj-TNDd-Cyx4-QkyN-vdVk-dG6n6I LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:08 +0000 LV Cache pool name cache_data LV Cache Origin name data_corig LV Status available # open 1 LV Size <2.00 TiB Cache used blocks 0.06% Cache metadata blocks 0.64% Cache dirty blocks 0.00% Cache read hits/misses 293 / 66 Cache wrt hits/misses 59 / 41173 Cache demotions 0 Cache promotions 486 Current LE 524284 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:9 --- Segments --- Logical extents 0 to 524283: Type cache Chunk size 64.00 KiB Metadata format 2 Mode writethrough Policy smq --- Logical volume --- Internal LV Name cache_data VG Name data LV UUID apACl6-DtfZ-TURM-vxjD-UhxF-tthY-uSYRGq LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:16 +0000 LV Pool metadata cache_data_cmeta LV Pool data cache_data_cdata LV Status NOT available LV Size 50.00 GiB Current LE 12800 Segments 1 Allocation inherit Read ahead sectors auto --- Segments --- Logical extents 0 to 12799: Type cache-pool Chunk size 64.00 KiB Metadata format 2 Mode writethrough Policy smq --- Logical volume --- Internal LV Name cache_data_cmeta VG Name data LV UUID hmkW6M-CKGO-CTUP-rR4v-KnWn-DbBZ-pJeEA2 LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:15 +0000 LV Status available # open 1 LV Size 1.00 GiB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:11 --- Segments --- Logical extents 0 to 255: Type linear Physical volume /dev/sdf Physical extents 0 to 255 --- Logical volume --- Internal LV Name cache_data_cdata VG Name data LV UUID 9mHe8J-SRiY-l1gl-TO1h-2uCC-Hi10-UpeEVP LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:16 +0000 LV Status available # open 1 LV Size 50.00 GiB Current LE 12800 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:10 --- Segments --- Logical extents 0 to 12799: Type linear Physical volume /dev/sdf Physical extents 256 to 13055 --- Logical volume --- Internal LV Name data_corig VG Name data LV UUID QP8ppy-nv1v-0sii-tANA-6ZzK-EJkP-sLfrh4 LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:17 +0000 LV Origin of Cache LV data LV Status available # open 1 LV Size <2.00 TiB Current LE 524284 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 253:12 --- Segments --- Logical extents 0 to 524283: Type raid5 Monitoring monitored Raid Data LV 0 Logical volume data_corig_rimage_0 Logical extents 0 to 262141 Raid Data LV 1 Logical volume data_corig_rimage_1 Logical extents 0 to 262141 Raid Data LV 2 Logical volume data_corig_rimage_2 Logical extents 0 to 262141 Raid Metadata LV 0 data_corig_rmeta_0 Raid Metadata LV 1 data_corig_rmeta_1 Raid Metadata LV 2 data_corig_rmeta_2 [vagrant@node-02 ~]$ [vagrant@node-02 ~]$ --- Segments --- Df7SLj LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:08 +0000 LV Status available # open 1 LV Size 1023.99 GiB Current LE 262142 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:8 --- Segments --- Logical extents 0 to 262141: Type linear Physical volume /dev/sdd Physical extents 1 to 262142 --- Logical volume --- Internal LV Name data_corig_rmeta_2 VG Name data LV UUID xi9Ot3-aTnp-bA3z-YL0x-eVaB-87EP-JSM3eN LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:08 +0000 LV Status available # open 1 LV Size 4.00 MiB Current LE 1 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:7 --- Segments --- Logical extents 0 to 0: Type linear Physical volume /dev/sdd Physical extents 0 to 0 --- Logical volume --- Internal LV Name data_corig VG Name data LV UUID QP8ppy-nv1v-0sii-tANA-6ZzK-EJkP-sLfrh4 LV Write Access read/write LV Creation Host, time node-02, 2019-09-03 13:22:17 +0000 LV Origin of Cache LV data LV Status available # open 1 LV Size <2.00 TiB Current LE 524284 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 253:12 --- Segments --- Logical extents 0 to 524283: Type raid5 Monitoring monitored Raid Data LV 0 Logical volume data_corig_rimage_0 Logical extents 0 to 262141 Raid Data LV 1 Logical volume data_corig_rimage_1 Logical extents 0 to 262141 Raid Data LV 2 Logical volume data_corig_rimage_2 Logical extents 0 to 262141 Raid Metadata LV 0 data_corig_rmeta_0 Raid Metadata LV 1 data_corig_rmeta_1 Raid Metadata LV 2 data_corig_rmeta_2

セグメント内の64KiBのチャンクサイズを明確に確認できます。

しかし、250GBのキャッシュディスクを作成する場合、lvmは、そのキャッシュディスクがサイズに対応するために少なくとも288KiBのチャンクサイズを必要とします。しかし、xfs_infoを実行すると、sunit/swidthの値が、RAID5レイアウトではなくキャッシュドライブの値と突然一致します。

出力xfs_info

[vagrant@node-02 ~]$ xfs_info /data meta-data=/dev/mapper/data-data isize=512 agcount=32, agsize=16777152 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 data = bsize=4096 blocks=536866816, imaxpct=5 = sunit=72 swidth=72 blks naming =version 2 bsize=8192 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=262144, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

突然、キャッシュドライブの288KiBのチャンクサイズに一致する72のsunitとswidthがあり、これはlvdisplay -m -aで確認できます。

[vagrant@node-02 ~]$ Sudo lvdisplay -m -a data --- Logical volume --- LV Path /dev/data/data LV Name data VG Name data LV UUID XLHw3w-RkG9-UNh6-WZBM-HtjM-KcV6-6dOdnG LV Write Access read/write LV Creation Host, time node-2, 2019-09-03 13:36:32 +0000 LV Cache pool name cache_data LV Cache Origin name data_corig LV Status available # open 1 LV Size <2.00 TiB Cache used blocks 0.17% Cache metadata blocks 0.71% Cache dirty blocks 0.00% Cache read hits/misses 202 / 59 Cache wrt hits/misses 8939 / 34110 Cache demotions 0 Cache promotions 1526 Current LE 524284 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:9 --- Segments --- Logical extents 0 to 524283: Type cache Chunk size 288.00 KiB Metadata format 2 Mode writethrough Policy smq --- Logical volume --- Internal LV Name cache_data VG Name data LV UUID Ps7Z1P-y5Ae-ju80-SZjc-yB6S-YBtx-SWL9vO LV Write Access read/write LV Creation Host, time node-2, 2019-09-03 13:36:40 +0000 LV Pool metadata cache_data_cmeta LV Pool data cache_data_cdata LV Status NOT available LV Size 250.00 GiB Current LE 64000 Segments 1 Allocation inherit Read ahead sectors auto --- Segments --- Logical extents 0 to 63999: Type cache-pool Chunk size 288.00 KiB Metadata format 2 Mode writethrough Policy smq --- Logical volume --- Internal LV Name cache_data_cmeta VG Name data LV UUID k4rVn9-lPJm-2Vvt-77jw-NP1K-PTOs-zFy2ph LV Write Access read/write LV Creation Host, time node-2, 2019-09-03 13:36:39 +0000 LV Status available # open 1 LV Size 1.00 GiB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:11 --- Segments --- Logical extents 0 to 255: Type linear Physical volume /dev/sdf Physical extents 0 to 255 --- Logical volume --- Internal LV Name cache_data_cdata VG Name data LV UUID dm571W-f9eX-aFMA-SrPC-PYdd-zs45-ypLksd LV Write Access read/write LV Creation Host, time node-2, 2019-09-03 13:36:39 +0000 LV Status available # open 1 LV Size 250.00 GiB Current LE 64000 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:10 --- Logical volume --- Internal LV Name data_corig VG Name data LV UUID hbYiRO-YnV8-Gd1B-shQD-N3SR-xpTl-rOjX8V LV Write Access read/write LV Creation Host, time node-2, 2019-09-03 13:36:41 +0000 LV Origin of Cache LV data LV Status available # open 1 LV Size <2.00 TiB Current LE 524284 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 253:12 --- Segments --- Logical extents 0 to 524283: Type raid5 Monitoring monitored Raid Data LV 0 Logical volume data_corig_rimage_0 Logical extents 0 to 262141 Raid Data LV 1 Logical volume data_corig_rimage_1 Logical extents 0 to 262141 Raid Data LV 2 Logical volume data_corig_rimage_2 Logical extents 0 to 262141 Raid Metadata LV 0 data_corig_rmeta_0 Raid Metadata LV 1 data_corig_rmeta_1 Raid Metadata LV 2 data_corig_rmeta_2

そして、lsblk -tの出力

[vagrant@node-02 ~]$ lsblk -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 512 0 512 512 1 deadline 128 4096 0B ├─sda1 0 512 0 512 512 1 deadline 128 4096 0B └─sda2 0 512 0 512 512 1 deadline 128 4096 0B ├─centos-root 0 512 0 512 512 1 128 4096 0B ├─centos-swap 0 512 0 512 512 1 128 4096 0B └─centos-home 0 512 0 512 512 1 128 4096 0B sdb 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_0 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-data5_corig_rimage_0 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sdc 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_1 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-data5_corig_rimage_1 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sdd 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_2 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-data5_corig_rimage_2 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sde 0 512 0 512 512 1 deadline 128 4096 32M sdf 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-cache_data5_cdata 0 512 0 512 512 1 128 4096 32M │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-cache_data5_cmeta 0 512 0 512 512 1 128 4096 32M └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sdg 0 512 0 512 512 1 deadline 128 4096 32M sdh 0 512 0 512 512 1 deadline 128 4096 32M

ここでいくつかの質問が発生します。

XFSは明らかにこれらの設定を自動検出しますが、なぜXFSはキャッシュドライブのチャンクサイズを使用することを選択するのですか？最初の例で見たように、RAID5レイアウトを自動検出できます。

su/swオプションをmkfs.xfsに渡して、正しいsunit/swidth値を取得できることは知っていますが、この場合はこれを行う必要がありますか？

http://xfs.org/index.php/XFS_FAQ#Q:_How_to_calculate_the_correct_sunit.2Cswidth_values_for_optimal_performance

私は何日もグーグルで検索し、XFSソースコードを調べましたが、XFSがこれを行う理由の手がかりを見つけることができませんでした。

したがって、発生する質問：

XFSがこのように動作するのはなぜですか？
su/swを実行するときに、mkfs.xfsを手動で定義する必要があります
キャッシュドライブのチャンクサイズはRAID5セットアップに影響を与えますか？これは何らかの方法で調整する必要がありますか？

shodanshok · Accepted Answer

最適な割り当てポリシーは、さまざまなブロックレイヤーが相互作用する方法に依存するため、複雑な問題です。

最適な割り当てポリシーを決定する際に、mkfs.xfsは libblkid によって提供される情報を使用します。 lsblk -tを発行して同じ情報にアクセスできます。 lvs（実際にはmkfs.xfs）のため、device-mapperが288K割り当てアライメントを使用するのはveryである可能性があります。その値をスタックに渡すだけです。

シンプロビジョニングでも非常によく似た動作が見られました。mkfs.xfsは思考チャンクサイズでファイルシステムを調整します。

編集：だから、これはlsblk -t ..の出力です。

[vagrant@node-02 ~]$ lsblk -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 512 0 512 512 1 deadline 128 4096 0B ├─sda1 0 512 0 512 512 1 deadline 128 4096 0B └─sda2 0 512 0 512 512 1 deadline 128 4096 0B ├─centos-root 0 512 0 512 512 1 128 4096 0B ├─centos-swap 0 512 0 512 512 1 128 4096 0B └─centos-home 0 512 0 512 512 1 128 4096 0B sdb 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_0 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-data5_corig_rimage_0 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sdc 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_1 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-data5_corig_rimage_1 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sdd 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-data5_corig_rmeta_2 0 512 0 512 512 1 128 4096 32M │ └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-data5_corig_rimage_2 0 512 0 512 512 1 128 4096 32M └─data5-data5_corig 0 65536 131072 512 512 1 128 384 0B └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sde 0 512 0 512 512 1 deadline 128 4096 32M sdf 0 512 0 512 512 1 deadline 128 4096 32M ├─data5-cache_data5_cdata 0 512 0 512 512 1 128 4096 32M │ └─data5-data5 0 294912 294912 512 512 1 128 4096 0B └─data5-cache_data5_cmeta 0 512 0 512 512 1 128 4096 32M └─data5-data5 0 294912 294912 512 512 1 128 4096 0B sdg 0 512 0 512 512 1 deadline 128 4096 32M sdh 0 512 0 512 512 1 deadline 128 4096 32M

ご覧のとおり、data5-data5デバイス（その上にxfsファイルシステムを作成）は、294912バイト（288K、キャッシュチャンク）のMIN-IOおよびOPT-IOを報告します。デバイスは、RAIDアレイのチャンクサイズ（64K）を報告します。これは、device-mapperが基になるIO情報を現在のキャッシュチャンクサイズで上書きしたことを意味します。

mkfs.xfsは、libblkidが報告した内容を単純に使用します。これは、使用されている特定のキャッシュデバイスマッパーターゲットによって異なります。