失敗したXFSファイルシステムを検出する方法は？

まあ。何をすべきか私失敗したXFSファイルシステムが検出されましたか？

私は長年XFSを使用してきました。しかし、私は思う私まったく検出しないでください。インストールが成功すれば正しく機能すると思います。これがほとんどの人がやっていることです。ファイルシステムのチェックが自動化されて実行されている場合、それはすべてです。

誤解しないでください。私は実際に多くの監視を行いますが、その中にファイルシステムに固有の監視はありません。 SMARTセルフテストを実行します（時間がかかりすぎるselect,contため、毎日ディスクセグメントを実行します）。longRAIDチェック（ステージング段階でも）を実行し、パリティの不一致（mismatch_cnt= 0）をチェックします。これらのいずれかが失敗した場合は、すぐに電子メール通知を受け取り、セクターの再割り当てが開始されたら実際にHDDを交換します（または少なくとも重要なデータを信頼していません）。

そのため、ストレージが正常に動作しているかどうかを監視します。これには、ドライブ自体（SMART）内のエラーとある程度高いレベルのエラーが含まれます（RAIDチェックは、コントローラ、ケーブル、RAIDロジックなどをある程度テストします）。

正常に機能する限り、ファイルシステムも理想的に機能する必要があります。 ZFS / btrfs（将来はXFS対応）などのチェックサムファイルシステムを除いて、ファイルシステム自体で内部的に実行される完全性チェックに加えて、マウント時にファイルシステムレベルでスキャンを実行することは実際には不可能です。コンセプト。

出力には、RAIDを実行しており、そのRAIDに障害が発生したディスクがあることが表示されます。md0冗長性のないRAID（RAID0またはパフォーマンスが低下したRAID1/5/6/10）でない限り、エラーは発生しないでください。 。

まず、ファイルシステム階層の下の問題を解決する必要があります。ディスクエラーに対してXFSを非難することはできませんが、ディスクエラーを確認する方法ではありません。

---

ファイルシステム上で完全な読み取りテストを実行したい場合は、xfsdumpバックアップディスクに対して実行できるようです。とにかくファイルシステムで完全な読み取りテストを実行したい場合は、次のようにします。まあ、ある意味では意味があるんです。

その本質は、xfsdumpXFSファイルシステムを完全にナビゲートし、すべてのファイルを保存することです。したがって、これは空き領域を除いて可能な限り完全な読み取りテストに近づける必要があります。

もちろん、すでに別のバックアップシステムを実行している場合は、実際にはファイルシステムに依存しない方法で同じ状況です。 （該当するバックアップシステムで単純な権限不足以上の読み取りエラーが発生した場合は、メールレポートを送信するのが最善です。、また）もちろん、増分バックアップであれば、定期的な完全バックアップなしで実際にファイルを何度も読み取ることはありません。

---

しかし、通常、ストレージが動作していることを知っている限り、ファイルシステムは「正しく動作する」と信じています。すべてのプログラムが例外なしで発生するすべてのI / Oエラーを引き上げることをお勧めしますが、実際にこれを行う普遍的な解決策はありません。各プログラムには独自のエラー処理機能があります。

多くの重要なストレージサーバーでは、エラーが大きくなったり、データが破損したり、破損したデータがユーザーに提供されないように、「エラーパニック」を有効にしています。エラーパニックを使用すると、パニックイベントまたはシャットダウンのみを監視してファイルシステムエラーを検出できます。

もちろん、冗長システムがない場合、サーバーパニックが発生すると実際のダウンタイムが発生します。ただし、業務上重要なシステムには冗長性が必要です。実際、これらのI / Oエラーを示すファイルシステム上のすべてのデータは使用されてはならず、バックアップシステムを起動できるようにできるだけ早くシステムを切断する必要があります。ほとんどの場合、データを提供しない方が実際に破損したデータを提供するよりも優れています。

~によるとhttps://access.redhat.com/solutions/3645252fs.xfs.panic_mask=127、XFSファイルシステムで検出されたすべてのエラーがシステムパニックを引き起こすようにsysctlを設定できます。

この構成でシステムの再起動を維持するには、次の手順を実行します。

echo 'fs.xfs.panic_mask=127' > /etc/sysctl.d/01-xfs.conf

xfs_repair -n

Usage: xfs_repair [options] device

Options:
  -f           The device is a file
  -L           Force log zeroing. Do this as a last resort.
  -l logdev    Specifies the device where the external log resides.
  -m maxmem    Maximum amount of memory to be used in megabytes.
  -n           No modify mode, just checks the filesystem for damage.
  -P           Disables prefetching.
  -r rtdev     Specifies the device where the realtime section resides.
  -v           Verbose output.
  -c subopts   Change filesystem parameters - use xfs_admin.
  -o subopts   Override default behaviour, refer to man page.
  -t interval  Reporting interval in minutes.
  -d           Repair dangerously.
  -V           Reports version and exits.

man page:
-n     No modify mode.
       Specifies that xfs_repair should not modify the filesystem but
       should only scan the filesystem and indicate what repairs would have been made.

そして持ってxfs_checkただし、マンページを作成すると、次の内容が表示されます。check XFS filesystem consistency... Note that using xfs_check is NOT recommended. Please use xfs_repair -n instead, for better scalability and speed.

/etc/fstab6番目または最後の列から、1またはに2つながる場合fsckファイルシステムの確認起動するたびにインストールが発生します。正確にxfs_repair -n？わかりません。

あなたが尋ねた検出済み失敗ファイルシステム：これに対する私の解釈は、失敗するとインストールされず、まったくアクセスできないということです。実際に知る必要はありません。確認するインストールされていないことが判明した場合、これは明確ではなく、手動でインストールしようとすると失礼にインストールが失敗します。

これを行うには削除する必要がありますが、以下を監視するには、定期的に手動で次の手順を実行する必要があります。

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc2       550G  152G  371G  30% /            {ext3}
udev            253G  216K  253G   1% /dev
tmpfs           253G  5.5M  253G   1% /dev/shm
/dev/sdc1       195M   13M  183M   7% /boot/efi
/dev/sda1       5.0T  4.9T   99G  99% /data         {xfs}
/dev/sdb1       559G   67G  492G  12% /scratch
tmpfs           450G     0  450G   0% /ramdisk
/dev/sdd1       5.0T  4.9T  9.8G 100% /bkup         {xfs}

how do i find file system types?

# mount
/dev/sdc2 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sdc1 on /boot/efi type vfat (rw,umask=0002,utf8=true)
/dev/sda1 on /data type xfs (rw)
/dev/sdb1 on /scratch type xfs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
tmpfs on /ramdisk type tmpfs (rw,size=450G)
nfsd on /proc/fs/nfsd type nfsd (rw)
/dev/sdd1 on /bkup type xfs (rw)

# xfs_repair -n /dev/sdd1
xfs_repair: /dev/sdd1 contains a mounted and writable filesystem

fatal error -- couldn't initialize XFS library

# umount /bkup/
# xfs_repair -n /dev/sdd1

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 4
        - agno = 3
        - agno = 1
        - agno = 2
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

this "xfs_repair -n" output is on a good XFS file system that has been problem free for years.