「XFS」の版間の差分
(→パフォーマンス: 一部英語版から転載) |
(→管理: 英語版から転載) |
||
200行目: | 200行目: | ||
{{Note|[[編集]]{{ic|xfs_scrub_all.timer}}:タイマーは毎週日曜日の午前3時10分に実行され、失敗した場合は [[systemd/タイマー#リアルタイムタイマー|すぐにトリガー]] されます。最後の開始時間、つまりシステムの電源がオフになっているため。}} |
{{Note|[[編集]]{{ic|xfs_scrub_all.timer}}:タイマーは毎週日曜日の午前3時10分に実行され、失敗した場合は [[systemd/タイマー#リアルタイムタイマー|すぐにトリガー]] されます。最後の開始時間、つまりシステムの電源がオフになっているため。}} |
||
+ | |||
+ | === Repair === |
||
+ | |||
+ | {{Note|<q>Unlike other Linux file systems, ''xfs_repair'' does not run at boot time, even when an XFS file system was not cleanly unmounted. In the event of an unclean unmount, ''xfs_repair'' simply replays the log at mount time, ensuring a consistent file system.</q>[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/xfsrepair]}} |
||
+ | |||
+ | From [https://docs.oracle.com/en/operating-systems/oracle-linux/6/adminsg/ol_repair_xfs.html Checking and Repairing an XFS File System]: |
||
+ | |||
+ | <q>If you cannot mount an XFS file system, you can use the '''xfs_repair -n''' command to check its consistency. Usually, you would only run this command on the device file of an unmounted file system that you believe has a problem. The '''xfs_repair -n''' command displays output to indicate changes that would be made to the file system in the case where it would need to complete a repair operation, but will not modify the file system directly.</q> |
||
+ | |||
+ | <q>If you can mount the file system and you do not have a suitable backup, you can use '''xfsdump''' to attempt to back up the existing file system data, However, the command might fail if the file system's metadata has become too corrupted.</q> |
||
+ | |||
+ | <q>You can use the '''xfs_repair''' command to attempt to repair an XFS file system specified by its device file. The command replays the journal log to fix any inconsistencies that might have resulted from the file system not being cleanly unmounted. Unless the file system has an inconsistency, it is usually not necessary to use the command, as the journal is replayed every time that you mount an XFS file system.</q> |
||
+ | |||
+ | First [[unmount]] the filesystem, then run the {{man|8|xfs_repair}} tool: |
||
+ | |||
+ | # xfs_repair ''device'' |
||
+ | |||
+ | <q>If the journal log has become corrupted, you can reset the log by specifying the '''-L''' option '''to xfs_repair'''.</q> |
||
+ | |||
+ | {{Warning|<q>The ''xfs_repair'' utility cannot repair an XFS file system with a dirty log. To clear the log, mount and unmount the XFS file system. If the log is corrupt and cannot be replayed, use the {{ic|-L}} option ("force log zeroing") to clear the log, that is, {{ic|xfs_repair -L /dev/device}}. Be aware that this may result in further corruption or data loss.</q>[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/xfsrepair]}} |
||
+ | |||
+ | {{Warning|<q>Resetting the log can leave the file system in an inconsistent state, resulting in data loss and data corruption. Unless you are experienced in debugging and repairing XFS file systems using '''xfs_db''', it is recommended that you instead recreate the file system and restore its contents from a backup.</q>[https://docs.oracle.com/en/operating-systems/oracle-linux/6/adminsg/ol_repair_xfs.html]}} |
||
+ | |||
+ | <q>If you cannot mount the file system or you do not have a suitable backup, running '''xfs_repair''' is the only viable option unless you are experienced in using '''xfs_db'''.</q> |
||
+ | |||
+ | <q>'''xfs_db''' provides an internal command set that allows you to debug and repair an XFS file system manually. The commands allow you to perform scans on the file system, and to navigate and display its data structures. If you specify the '''-x''' option to enable expert mode, you can modify the data structures.</q> |
||
+ | |||
+ | # xfs_db [-x] device |
||
+ | |||
+ | <q>For more information, see the {{man|8|xfs_db}} and {{man|8|xfs_repair}}, and the '''help''' command within '''xfs_db'''.</q> |
||
+ | |||
+ | See also [https://xfs.org/index.php/XFS_FAQ#Q:_Which_factors_influence_the_memory_usage_of_xfs_repair.3F Which factors influence the memory usage of xfs_repair?] and [https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-repair.html XFS Repair]. |
||
+ | |||
+ | === Data rescue === |
||
+ | |||
+ | Even when being mounted read-only with {{ic|mount -o ro}} an XFS file system's log will be replayed if it has not been unmounted cleanly. |
||
+ | |||
+ | There may be situations where a compromised XFS file system on a damaged storage device should be mounted read-only, so that files may be copied off it hopefully without causing further damage, yet it cannot be mounted because it has not been unmounted cleanly and is damaged to such an extent that the log cannot be replayed. |
||
+ | Also, consider that replaying the log means writing to the compromised file system, which might be a bad idea in itself. |
||
+ | |||
+ | To mount an XFS file system without writing to it in any way and without replaying the log, use {{ic|mount -o ro,norecovery}}. |
||
+ | |||
+ | === Undelete === |
||
+ | |||
+ | {{AUR|xfs_undelete}} can recover (under certain conditions) deleted files on an unmounted or read-only mounted XFS filesystem. See https://github.com/ianka/xfs_undelete for more information. |
||
== トラブルシューティング == |
== トラブルシューティング == |
2022年3月12日 (土) 23:01時点における版
関連記事
XFS は Silicon Graphics, Inc によって開発された高性能ジャーナリングファイルシステムです。XFS はアロケーショングループを使って設計されているため並列化された IO で特に性能を発揮します。このため複数のストレージデバイスを使用するときは IO スレッド, ファイルシステムの帯域, ファイルとファイルシステムのサイズ全てをスケーリングすることが可能です。
準備
XFS ユーザースペースユーティリティ xfsprogs パッケージを インストール して下さい。 XFS ファイルシステムを管理するために必要なツールが含まれています。
設定
デバイス に新しいファイルシステムを作成するには、次を使用します。
# mkfs.xfs device
一般に、デフォルトのオプションは一般的な使用に最適です。[1] [2]
サンプル出力:
meta-data=/dev/device isize=256 agcount=4, agsize=3277258 blks = sectsz=512 attr=2 data = bsize=4096 blocks=13109032, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=6400, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
チェックサム
xfsprogs 3.2.0 では、新しいディスクフォーマット (v5) が導入され、Self-Describing Metadata というメタデータのチェックサムスキームが含まれています。
CRC32 に基づいており、例えば予期せぬ停電の際にメタデータが破損しないようにするための追加保護を提供します。チェックサムは xfsprogs を使用している場合、デフォルトで有効になっています。3.2.3以降 古いカーネルで読み書き可能な xfs が必要な場合は、 mkfs.xfs(8) を呼ぶときに -m crc=0
スイッチを使えば、簡単に無効にできます。
# mkfs.xfs -m crc=0 /dev/target_partition
XFS v5 オンディスクフォーマットは Linux Kernel 3.15 以降の実稼働ワークロードでは安定と見なされています。
Free inode btree
Linux 3.16 から、XFS には空き inode を追跡する btree が追加されました。これは既存の inode 割り当て btree と同等ですが、free inode btree は少なくとも1つの空き inode を持つ inode チャンクを追跡することは例外です。目的は、inode 割り当てのための空き inode クラスタのルックアップを改善することです。古くなったファイルシステム、つまり、何百万ものファイルをファイルシステムに追加したり、ファイルシステムから削除したりして、何年も経過したファイルシステムでのパフォーマンスを向上させることができます。この機能を使用しても、ファイルシステム全体の信頼性レベルやリカバリ機能には影響がありません。
この機能は、Linux Kernel 3.15 以降の実運用ワークロードで安定したと考えられる新しい v5 オンディスク・フォーマットに依存しています。既存のディスク上の構造は変更されませんが、inode 割り当て btree との一貫性を維持する必要がある新しい構造が追加されます。このため、古いカーネルでは free inode btree 機能を持つ読み取り専用ファイルシステムのみをマウントすることができます。
この機能は xfsprogs 3.2.3 以降を使用している場合、デフォルトで有効になっています。古いカーネルで書き込み可能なファイルシステムが必要な場合、XFS パーティションをフォーマットする際に finobt=0
スイッチで無効にすることができます。このとき、crc=0
が一緒に必要になります。
# mkfs.xfs -m crc=0,finobt=0 /dev/target_partition
または(finobt
は crc
に依存するため)
# mkfs.xfs -m crc=0 /dev/target_partition
Reverse mapping btree
リバースマッピング btree は、そのコアで、ストレージスペース使用量のセカンダリインデックスであり、プライマリスペース使用量メタデータの冗長コピーを効果的に提供します。これにより、ファイルシステム操作にいくらかのオーバーヘッドが追加されますが、ファイルシステムに含まれるため、相互参照が非常に高速になります。破損したプライマリメタデータをセカンダリコピーから再構築できるため、オンラインでファイルシステムを修復するために不可欠な機能です [5]
この機能は、Linux 4.16 の実験的ステータスを卒業し、本番環境に対応しています。ただし、オンラインファイルシステムのチェックと修復は(これまでのところ)この機能の唯一のユースケースであるため、少なくともオンラインチェックが本番環境に移行するまではオプトインのままです。
Reverse mapping btree は、ファイルシステムブロックをファイルシステムブロックの所有者にマップします。ほとんどのマッピングは i ノード番号とオフセットになりますが、ファイルシステムメタデータへのマッピングもあります。このセカンダリメタデータを使用して、プライマリメタデータを検証したり、ディスクエラーが発生したときに失われたデータを正確に特定したりできます。
この機能または将来を見据えた新しいファイルシステムを試すには、ファイルシステムの作成中に -m rmapbt=1
パラメータを渡します。
# mkfs.xfs -m rmapbt=1 device
タイムスタンプ
Linux 5.10 以降、XFS は、リファクタリングされたタイムスタンプおよび i ノードエンコーディング関数を使用して、タイムスタンプを 64ビットナノ秒カウンターとして処理し、ビットシフトして有効サイズを増やすことをサポートしています。これにより、XFS は 2038年問題 を回避して 2486 年まで実行できるようになります。bigtime を有効にして新しい XFS ファイルシステムを作成すると、1901年12月から2038年1月までではなく、2486年7月まで。下位互換性を維持するために、ビッグタイムスタンプ機能は現在デフォルトで有効になっていません。-5.10
この機能では、1970年1月から2106年2月ではなく、1970年1月から2486年7月までのクォータタイマーの有効期限も許可されます。
この機能または将来を見据えた新しいファイルシステムを試すには、ファイルシステムの作成中に-m bigtime=1
パラメータを渡します。
# mkfs.xfs -m bigtime=1 device
xfsprogs 5.11 以降、これは xfs_admin(8) を使用して既存の(マウントされていない)ファイルシステムでも有効にできます。
# xfs_admin -O bigtime=1 device
または xfs_repair(8) を使用:
# xfs_repair -c bigtime=1 device
パフォーマンス
速度を最適化するには、XFS ファイルシステムを次のコマンドで作成します:
# mkfs.xfs /dev/target_partition
はい、とてもシンプルです。なぜなら "ブースト機能" は全てデフォルトで "オン" になっている からです。
XFS wiki によれば、XFS を最大限活用したい場合は、デフォルトの CFQ I/O スケジューラーを (Deadline, Noop, BFQ などに) 変更したほうが良いようです (特に SSD を使っている場合)。
ストライプサイズと幅
ファイルシステムをストライプする RAID 上に作成する場合は mkfs.xfs
コマンドでストライプサイズを指定することで著しい速度の向上が望めます。
How to calculate the correct sunit,swidth values for optimal performance を見て下さい。
バリアの無効化
/etc/fstab
ファイルに nobarrier マウントオプションを追加してファイルシステムのバリアの使用を無効化することでパフォーマンスを上げることができます。
アクセス日時
/etc/fstab
ファイルに noatime
マウントオプションを追加することでファイルシステムのパフォーマンスが向上することがあります。XFS ファイルシステムではデフォルトの atime の扱い方は relatime
になっており、noatime
と比べてオーバーヘッドをかなり減らしつつも atime の値を正常に保ちます。現在 Linux の全てのファイルシステムが (2.6.30 あたりから) デフォルトで relatime
を使うようになっていますが、XFS が relatime
を使うようになったのは2006年からです。そのため、パフォーマンスを理由に XFS で noatime
を使う必要はほとんどありません。
また、noatime
には nodiratime
が含まれているため、noatime
を指定したら nodiratime
を指定する必要はなくなります。
デフラグ
XFS はエクステントベースであり遅延アロケーションを利用しているため断片化の問題はなかなか発生しないようになっていますが、マウントされたアクティブな XFS ファイルシステム上のファイルをデフラグできる、ファイルシステムデフラグユーティリティ (xfs_fsr, XFS filesystem reorganizer の略) が用意されています。定期的に XFS の断片化を監視するのにも使えます。
xfs_fsr(8) はマウントされたファイルシステムの編成を改善します。再編成アルゴリズムによって一度に一つのファイルが操作され、コンパクトになる、つまりファイルのエクステント (ファイルデータの連続ブロック) のレイアウトが改善されます。
フラグメンテーションレベルの確認
ファイルシステムにどれくらい断片化が発生しているのか確認するには:
# xfs_db -c frag -r /dev/sda3
デフラグの実行
デフラグを開始するには、xfsprogs パッケージに含まれている xfs_fsr
コマンドを使います:
# xfs_fsr /dev/sda3
Deduplication
The reflink feature, available since kernel version 4.9 and enabled by default since mkfs.xfs
version 5.1.0, allows creating fast reflink'ed copies of files as well as deduplication after the fact, in the same way as btrfs:
Reflink copies
Reflink copies initially use no additional space:
$ cp --reflink bigfile1 bigfile2
Until either file is edited, and a copy-on-write takes place. This can be very useful to create snapshots of (large) files.
Deduplication
Existing filesystems can be deduped using tools like duperemove.
External XFS Journal
Using an external log (metadata journal) on for instance a SSD may be useful to improve performance [8]. See mkfs.xfs(8) for details about the logdev
parameter.
To reserve an external journal with a specified size when you create an XFS file system, specify the -l logdev=device,size=size
option to the mkfs.xfs
command. If you omit the size
parameter, a journal size based on the size of the file system is used. To mount the XFS file system so that it uses the external journal, specify the -o logdev=device
option to the mount command.
Sync interval
XFS has a dedicated sysctl variable for setting the writeback interval with a default value of 3000.
/etc/sysctl.d/20-xfs-sync-interval.conf
fs.xfs.xfssyncd_centisecs = 10000
管理
リサイズ
XFS はパーティションが変更された後、オンラインでサイズを変更することができます。マウントポイントを最初のパラメータとして xfs_growfs
を実行すれば、XFS ファイルシステムを最大サイズに拡大できます。
# xfs_growfs /path/to/mnt/point
オンラインメタデータチェック (スクラブ)
xfs_scrub
はカーネルに XFS ファイルシステム内の全てのメタデータオブジェクトをスクラブするように要求します。メタデータレコードは明らかに悪い値をスキャンされ、他のメタデータと相互参照されます。その目的は、ファイルシステム内の他のメタデータに対する個々のメタデータレコードの一貫性を調べることで、ファイルシステム全体の一貫性に対する妥当な信頼性を確立することです。破損したメタデータは、無傷の冗長なデータ構造が存在すれば、他のメタデータから再構築することができる。
xfs_scrub_all.timer
を 有効化/起動 します、すべての XFS ファイルシステムのオンライン メタデータを定期的にチェックします。
Repair
From Checking and Repairing an XFS File System:
If you cannot mount an XFS file system, you can use the xfs_repair -n command to check its consistency. Usually, you would only run this command on the device file of an unmounted file system that you believe has a problem. The xfs_repair -n command displays output to indicate changes that would be made to the file system in the case where it would need to complete a repair operation, but will not modify the file system directly.
If you can mount the file system and you do not have a suitable backup, you can use xfsdump to attempt to back up the existing file system data, However, the command might fail if the file system's metadata has become too corrupted.
You can use the xfs_repair command to attempt to repair an XFS file system specified by its device file. The command replays the journal log to fix any inconsistencies that might have resulted from the file system not being cleanly unmounted. Unless the file system has an inconsistency, it is usually not necessary to use the command, as the journal is replayed every time that you mount an XFS file system.
First unmount the filesystem, then run the xfs_repair(8) tool:
# xfs_repair device
If the journal log has become corrupted, you can reset the log by specifying the -L option to xfs_repair.
If you cannot mount the file system or you do not have a suitable backup, running xfs_repair is the only viable option unless you are experienced in using xfs_db.
xfs_db provides an internal command set that allows you to debug and repair an XFS file system manually. The commands allow you to perform scans on the file system, and to navigate and display its data structures. If you specify the -x option to enable expert mode, you can modify the data structures.
# xfs_db [-x] device
For more information, see the xfs_db(8) and xfs_repair(8), and the help command within xfs_db.
See also Which factors influence the memory usage of xfs_repair? and XFS Repair.
Data rescue
Even when being mounted read-only with mount -o ro
an XFS file system's log will be replayed if it has not been unmounted cleanly.
There may be situations where a compromised XFS file system on a damaged storage device should be mounted read-only, so that files may be copied off it hopefully without causing further damage, yet it cannot be mounted because it has not been unmounted cleanly and is damaged to such an extent that the log cannot be replayed. Also, consider that replaying the log means writing to the compromised file system, which might be a bad idea in itself.
To mount an XFS file system without writing to it in any way and without replaying the log, use mount -o ro,norecovery
.
Undelete
xfs_undeleteAUR can recover (under certain conditions) deleted files on an unmounted or read-only mounted XFS filesystem. See https://github.com/ianka/xfs_undelete for more information.
トラブルシューティング
ルートファイルシステムクォータ
XFS quota マウントオプション (uquota
, gquota
, prjquota
, etc) はファイルシステムの再マウントの際に失敗します。ルートファイルシステムでクォータを有効にするには、マウントオプションは initramfs に カーネルパラメータ として渡されなければなりません。rootflags=
です。その後、ルート (/etc/fstab
) ファイルシステムのマウントオプションの中にリストされてはいけません。
xfs_scrub_all は、ユーザ "nobody" がマウントポイントにアクセスできない場合、失敗します
xfs_scrub_all
を実行すると、マウントされた各 XFS ファイルシステムに対して xfs_scrub@.service
が起動します。このサービスはユーザ nobody
として実行されるので、nobody
がディレクトリに移動できない場合、エラーで失敗します。
xfs_scrub@mountpoint.service: Changing to the requested working directory failed: Permission denied xfs_scrub@mountpoint.service: Failed at step CHDIR spawning /usr/bin/xfs_scrub: Permission denied xfs_scrub@mountpoint.service: Main process exited, code=exited, status=200/CHDIR
サービスの実行を許可するには、ユーザー nobody
に実行権限があるようにマウントポイントの パーミッション を変更します。