xfsファイルシステムのマウント

この国は、本当バージョン固定や塩漬けにしたがる。手に入れたソフトウェアは絶対的にバグはなく、セキュリティホールはなく、でも保守費用を払っていれば、機能追加してもらえる、あるいは、機能追加しないと利用を停止するぞと脅すことが可能であると思っている人が多い。保守運用に極力、手間、コストをかけたくないということなのだろう。そんなソリューションなんてないと思うが。。。実は、あるんです。

昔のメインフレーム

昔のメインフレームは、

インターネットに接続されていないので、今いわれているような脆弱性は問題にならない。（ただし、CPUやファームウェアの脆弱性でバグが起きることがある。）
最新型の機種でも何十年前のOSでもブートできてしまうし、サポートされていることがある。（なのでバージョン固定可能。オープンと違って、進化するスピードが遅い。）
かなり周辺機器も接続可能。実際、想定されていない古いデバイスを繋げたことがある。
保守費用が結構高額なので（現代のSIerにどっぷり払っている金額と同じくらい？）、保守料のなかで、パーツ交換、パッチ当ても御用聞レベルでやってくれる。

今のバージョン塩漬け、インターネットへ接続不可という案件にはうってつけだと思うのだが。。。もちろん、アプリもCOBOLだけでなく、CやJavaで作れるので。

一方、オープン系の場合、バージョン固定をしているつもりでも実はできていない。できないのでアップデートをしないというケースもある。そこでよくハマる（そもそもハマっているかどうか気がついているのかも不明だが。）のが、RHEL。

RHELの場合、RHELを初期導入して、yum/dnf updateをすると最新リリースまで上がってしまう。例えば、RHEL7U1をインストールをして、yum updateをすると、RHEL7U9になってしまう。バージョン固定をするには、

echo 7.1 > /etc/yum/vars/releasever
yum update
reboot

とすることで、RHEL7U1に固定できる。がしかし、あくまでもRHEL7U1レベルのupdateしか落ちてきおないので、RHEL7U9で修正されたものは利用できない。自身で個別にRPMであげてもいいが、依存関係でだんだんおかしくなってくるのでお勧めしない。なので、RHELのバージョン固定は最終手段で、可能であれば最新レベルに上げてしまうほうがいいと思う。

RHELは、本来そのバージョンで修正されていない問題もバックポートしてくれるので安心。そう、今回は、バックポートで発見した互換性の話。

閑話休題

xfsでマウントができないことがあったので調べてみた。

調査で必要となる情報

Linux、XFSの互換性をしらべる

cat /etc/redhat-release　あるいはcat /etc/lsb-release
uname -r
rpm -q xfsprogs あるいはdpkg -I xfsprog
mkfs.xfs -V
mkfs.xfs -h
xfs_info <xfsをマウントしているマウントポイント>

mkfs.xfs -h/xfs_infoで以下のパラメータを調べる

crc=0/1 (xfs v4かv5かどうか)
reflink=0/1 (reflinkをサポートしているかどうか）
bigtime=0/1 (Y2038問題に対応しているかどうか)
inobtcount=0/1 (マウント時間が高速になるinode btreeサイズの保存しているかどうか。)

mkfs.xfsは、デフォルトで上記のオプションを有効にする。mkfs.xfs のバージョンによってまちまち。xfs_info <マウントポイント>でも調べる必要があるということがわかった。

xfsがマウントできないのは、環境による非互換があるためで、必ずしもバックアップデータが壊れているわけではない。

RHEL7からはデフォルトのファイルシステムがext4ではなく、xfsに変更されているので、この問題に当たりやすい。今回は、RHELでの互換問題を調べてみる。（ちなみに、RHELはDeveloperサブスクリプションを利用。）

xfsファイルシステムは、カーネルレベルでのサポートとユーザランドであるxfsprogsの２つを理解する必要がある。

xfsprogsは、xfsファイルシステムの操作(フォーマットなど）を行う。そのフォーマット時の設定をカーネルがサポートできるかどうかが重要になる。xfsprogsで設定したファイルシステムオプションを動作しているカーネルが理解できるとマウントが成功するが、カーネルがファイルシステムのオプションを理解できない場合は、マウントに失敗をする。

また、RHELなどのベンダーカーネルは、新しいVanilla カーネルからのバックポートをしているので、単純なカーネルバージョンの比較ができない。

RHELでの比較

以下のRHELは全て、リリースチャネルでのyum/dnf updateをかけてある環境。

RHEL7U9のファイルシステム

crc=1がかろうじて設定されているので、xfs v5ファイルシステムに対応している。reflinkすら認識できない。もちろんmkfs.xfs -m reflink=0/1すら受け付けない。

RHEL8U5のファイルシステム（RHEL8からRHELU4までを含む。以後RHELU5として表記する。）

RHEL8U6のファイルシステム

RHEL8U5もRHEL8U6もcrc=1なので、xfs v5ファイルシステム。

RHEL8U5

bigtime=0 inobtcount=0が存在しない。

bigtime、inobtcountが有効なxfsファイルシステムはマウントできない。

RHEL8U6

bigtime=0 inobtcount=0が存在している。ただし、bigtime、inobtcountはデフォルトオフになっている。

bigtime、inobtcountが有効なxfsファイルシステムはマウントが可能。

さらに、RHEL9U1では、

crc=1なので、xfs v5ファイルシステム。

bigtime=1 inobtcount=1が存在している。また、bigtime、inobtcountはデフォルトオンになっている。

bigtime、inobtcountが有効なxfsファイルシステムはマウントが可能。

Redhatのドキュメントかrの考察

RHEL9のドキュメントには、

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index

14.1. ファイルシステム

xfs ファイルシステムが、bigtime 機能および inobtcount 機能に対応するようになりました。

xfs ファイルシステムが、ディスク上の新機能 2 つに対応しました。各機能は、RHEL 9 の mkfs.xfs でデフォルトで有効になっています。この 2 つの新機能は以下のとおりです。

2038 年以降のタイムスタンプへの対応 (bigtime)

inode btree counters (inobtcount) – 大きなファイルシステムでのマウント時間を短縮します。

この更新により、デフォルトの mkfs.xfs パラメーターで作成されたファイルシステムは、RHEL 8 システムにはマウントできなくなりました。

RHEL 8 カーネルと互換性のある新しいファイルシステムを作成する場合は、mkfs.xfs コマンドラインに -m bigtime=0,inobtcount=0 を追加して、この新しい機能を無効にします。この方法で作成したファイルシステムは、2038 年以降のタイムスタンプに対応しません。

RHEL8U8に含まれるkernelのChange Logを確認

rpm -q --changelog kernel

リリースタイミングと比較すると以下のタイムラインでxfsの変更が行われている。

RHEL8U5 4.18.0-348.el8

* Tue Dec 28 2021 Augusto Caringi <acaringi@redhat.com> [4.18.0-358.el8]

– xfs: drop experimental warnings for bigtime and inobtcount (Bill O’Donnell) [2022903]

RHEL8U6 4.18.0-372.9.1.el8

* Fri Apr 29 2022 Jarod Wilson <jarod@redhat.com> [4.18.0-388.el8]

– xfs: remove the unused xfs_icdinode_has_bigtime helper (Brian Foster) [2072552]

RHEL8U7 4.18.0-425.3.1.el8

結論からすると、以下が影響した様子。

* Tue Dec 28 2021 Augusto Caringi <acaringi@redhat.com> [4.18.0-358.el8]

– xfs: drop experimental warnings for bigtime and inobtcount (Bill O’Donnell) [2022903]

RHEL9でフォーマットされたxfsは、デフォルトでbigtime=1 inobtcount=1にしてしまう。

RHEL8U5(4.18.0-348.el8)は、bigtime=1 inobtcount=1を理解できないので、RHEL9のxfsをマウントしようとするとエラーになる。

RHEL8U6(4.18.0-372.9.1.el8)は、デフォルトだと、bigtime=0 inobtcount=0でフォーマットするが、RHEL9のbigtime=1 inobtcount=1を理解できるので、マウントができる。

ちなみに、RHEL7ではreflink=1でフォーマットされているxfsファイルシステムはマウントできないため、RHEL8/RHEL9でフォーマットされたxfsファイルシステムはマウントできない。

https://access.redhat.com/solutions/4582401

まとめるとRHELのxfsファイルシステムの互換性は以下のようになる。

		RHEL7.9 (3.10.0-1160.90.1.el7)	RHEL8U5 (4.18.0-348)	RHELU6 (4.18.0-372.9.1)	RHEL9U1 (5.14.0-162.23.1)
マウントされる側のRHEL	xfsprogs ver.
RHEL7.9 (3.10.0-1160.90.1.el7)	4.5.0-22	マウント可能 (デフォルト)	マウント可能	マウント可能	マウント可能
RHEL8U5 (4.18.0-348)	5.0.0-9	reflink=0 bigtime=0 inobtcount=0	マウント可能 (デフォルト)	マウント可能	マウント可能
RHELU6 (4.18.0-372.9.1)	5.0.0-10	reflink=0 bigtime=0 inobtcount=0	マウント可能	マウント可能 (デフォルト)	マウント可能
RHEL9U1 (5.14.0-162.23.1)	5.14.2-1	reflink=0 bigtime=0 inobtcount=0	bigtime=0 inobtcount=0	マウント可能	マウント可能 (デフォルト)

ちなみに、RHEL9U3だと、xfsprogsは、5.19.0-4なので、さらに新しくなっている。

解決策

RHEL8U5にRHEL8U6のカーネルを入れる。

Redhatの有効なサブスクリプションを持っていて、事前にサーバにサブスクリプションが設定されていることが前提。

KERNELVER=4.18.0-372.9.1.el8
dnf -y install kernel-${KERNELVER} kernel-tools-${KERNELVER} kernel-tools-libs-${KERNELVER} kernel-core-${KERNELVER} kernel-modules-${KERNELVER} bpftool-${KERNELVER}
reboot

あるいは、リリースバージョンをRHEL8U6以上にする。

Redhatの有効なサブスクリプションを持っていて、事前にサーバにサブスクリプションが設定されていることが前提。

以下、RHEL8U6にする場合

echo 8.6 > /etc/yum/vars/releasever
dnf update
reboot

RedhatのBugzillaでも、バグとしてレポートされており、解決策はRHEL8U6以降にすることとなっている。（Backport?）

https://bugzilla.redhat.com/show_bug.cgi?id=2046431

RHELのバージョンを最新リリースバージョンにする。(これがお勧め）

rm /etc/yum/vars/releasever
dnf update
reboot

Vanillaカーネルでの比較

https://speakerdeck.com/matoken/try-xfs-bigtime?slide=25

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10

commit 4ea1ff3b49681af45a4a8c14baf7f0b3d11aa74a

Author: Darrick J. Wong <darrick.wong@oracle.com>

Date: Mon Aug 17 09:59:51 2020 -0700

xfs: widen ondisk quota expiration timestamps to handle y2038+

Enable the bigtime feature for quota timers. We decrease the accuracy

of the timers to ~4s in exchange for being able to set timers up to the

bigtime maximum.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

Reviewed-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Allison Collins <allison.henderson@oracle.com>

Reviewed-by: Dave Chinner <dchinner@redhat.com>

実際にxfsのbigtime=1 inobtcount=1を正式サポートしているのはKernel 5.10以降となる。

xfsprogsのChangelogをみると

https://fossies.org/linux/xfsprogs/doc/CHANGES

224 xfsprogs-5.10.0-rc1 (04 Dec 2020)

225 – xfsprogs: Add inode btree counter feature (Darrick Wong)

226 – xfsprogs: Add bigtime feature for Y2038 (Darrick Wong)

116 xfsprogs-5.15.0-rc1 (11 Mar 2022)

117 – mkfs: enable inobtcount and bigtime by default (Darrick J. Wong)

つまり、xfsのマウント問題に遭遇しないためには、RHELであれば、RHEL8U6あるいは、RHEL9を使う、Vanillaカーネルレベルであれば、すくなくとも、kernel 5.10できれば、kernel-5.15以降(もしくは、それらを備えたディストリビューション）を使うこと。Ubuntuの場合、Ubuntu 22.04.3とかなら、kernelは、5.15.0-91-genericなので問題ない。それ以外は危険を伴うとも言える。

実は、これ、だいぶ前にまとめたのだが、なかなか書く機会がなかった。xfsって、Linuxユーザからしてみれば新しいファイルシステムなんだけど、もとは、SGIのもので結構歴史が古いんですよね。SGIというば、O2というものをメンテしていたことがあるが、OSに入っているパッケージがリンク前のオブジェクトファイルで、インストールするのに1日仕事だった。。。まぁ、それはそれでいいんだけどw

しかし、こんなのは、氷山の一角で、バージョン固定をこだわる人が少なくなって欲しいがこの国では無理かもしれない。自分の周辺環境が変わったので、そろそろ仕事とかも変わらなきゃならない（実は家の会社の代表になってしまった。。。）から、こういうことにハマることはないことを祈りたい。

RHELでの比較

Vanillaカーネルでの比較

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル