web-dev-qa-db-ja.com

XFS：マウントはsunitおよびswidthオプションをオーバーライドします

MDADMを使用して、チャンクサイズが256KBのRAID-5アレイ内の4つの3TBディスクで構成される9TBXFSパーティションがあります。

パーティションを作成すると、最適なストライプの単位と幅の値（64ブロックと192ブロック）が自動的に検出および設定されました。これはxfs_infoによって確認されています。

# xfs_info /dev/md3
meta-data=/dev/md3               isize=256    agcount=32, agsize=68675072 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=2197600704, imaxpct=5
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

ただし、転送速度が遅いので、調査中に、パーティションを-o sunit=64,swidth=192で特別にマウントしない限り、ストライプユニットは常に512に設定され、幅は1536に設定されていることに気付きました。例：

# umount /dev/md3
# mount -t xfs -o rw,inode64 /dev/md3 /data
# grep xfs /proc/mounts
/dev/md3 /data xfs rw,relatime,attr2,delaylog,inode64,logbsize=256k,sunit=512,swidth=1536,noquota 0 0

これは意図された動作ですか？毎回sunit=64,swidth=192でマウントを開始できると思いますが、それでは現在のデータ（sunit=512,swidth=1536でマウントされている間に書き込まれた）の位置がずれませんか？

オペレーティングシステムは、カーネル3.2.51を備えたDebianWheezyです。 4つのハードディスクはすべて高度なフォーマットのディスクです（smartctlは512 bytes logical, 4096 bytes physicalと言います）。値に8が掛けられるという事実は、これが問題と関係があるのか​​どうか疑問に思います。これは、512から4096のセクターサイズのディスクの掛け算係数と一致することを示しています。

誰かがこれに光を当てることができますか？ :-)

linuxdebianraidmdadmxfs
2
Sauron

ミステリーに8を掛けるのは、xfs_infoがsunit/swidthをbsizeブロック（通常は4096バイト）で表示するためです。 -oまたはfstabを使用してマウントでsunit/swidthを指定する場合、それらは512バイト単位で指定されます。サンプルのxfs_info出力のsunit/swidth番号の後の「blks」文字列に注意してください。 4096/512 = 8、したがってミステリー乗数。

man 5 xfsは、512Bユニットに関して、mkfs.xfsと同様に、sunitスタンザでこれを詳しく説明しています。

xfs_infoのマンページを兼ねるmanxfs_growfsは、xfs_infoの単位がbsizeバイトである方法を詳しく説明しています。

紛らわしい、はい。はい、UIの観点からは非常に悪いデザインの選択です。

「-osunit = 64、swidth = 192」を指定することは、64/8 = 8および192/8 = 24が本当に必要だったため、おそらく悪い考えでした。 8倍大きい値をFSにハードコーディング」して、より大きな数値でマウントした可能性があります。マニュアルページでは、低いサンティットに切り替えることができないことを明確に示しています。ただし、マウントエラーが発生するかどうかを試してみることができます。XFSのマウントは、データを消費しないように十分に堅牢である必要があります（ただし、保証はありません）。エラーを吐き出してマウントを拒否するか、正常にマウントする必要があります。指定した内容を無視するオプション。最初にバックアップを作成します。

とは言うものの、これはすべて位置合わせに関するものであり、それらの数値はまだ位置合わせされているため、実際には8倍大きいsunit/swidthに問題はない可能性があります。おそらく、ファイルのほとんどが小さい場合、断片化の問題または問題がある可能性がありますか？

余談ですが、私が現在取り組んでいて興味をそそられるのは、1つのディスクを追加してmd RAIDを拡張/再形成するときに、sunit/swidthの値を何に変更するかです。 manページからは、ディスクの数を文字通り2倍にしない限り、sunitを変更できないように見えますが、幅を変更することは可能であるようです。これがほとんどの場合適切な位置合わせをもたらすかどうかはまだ分からない。実際にこれを行っている人々からの情報は不足しているようです。

3
Trevor Cordes