☰

如何检测失败的 XFS 文件系统？

tag-icon • tag-icon filesystems monitoring xfs
如何检测失败的 XFS 文件系统？

目前，我通过检查系统日志中是否有如下消息来监视失败的文件系统（由于磁盘、控制器等出现故障）：

2017-06-15T17:18:10.081665+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381844.448488] blk_update_request: critical target error, dev sdj, sector 97672656
2017-06-15T17:18:10.724329+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.047871] XFS (md0): metadata I/O error: block 0x2baa81400 ("xlog_iodone") error 121 numblks 512
2017-06-15T17:18:10.724329+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.124418] XFS (md0): xfs_do_force_shutdown(0x2) called from line 1177 of file /build/linux-lts-wily-8ENwT0/linux-lts-wily-4.2.0/fs/xfs/xfs_log.c.  Return address = 0xffffffffc050e100
2017-06-15T17:18:10.724349+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.124425] XFS (md0): Log I/O Error Detected.  Shutting down filesystem
2017-06-15T17:18:10.724349+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.124452] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:18:10.724354+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.163480] XFS (md0): Please umount the filesystem and rectify the problem(s)
2017-06-15T17:18:40.612572+00:00    2017-06-15T17:18:40+00:00   localhost  kernel:  [1381875.074647] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:19:10.612554+00:00    2017-06-15T17:19:10+00:00   localhost  kernel:  [1381905.101606] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:19:40.612558+00:00    2017-06-15T17:19:40+00:00   localhost  kernel:  [1381935.128546] XFS (md0): xfs_log_force: error -5 returned.

这是好的但我真的想要一个更规范的检查。我唯一能想到的就是编写一个脚本，尝试将文件写入磁盘，并在因任何原因无法写入时发出警报。然而，这似乎很容易出现误报——文件无法写入的原因有多种，而不仅仅是文件系统出现故障。

除了 grep 日志或将金丝雀文件写入磁盘之外，如何对其进行监控？

答案1

嗯。怎么办我检测到失败的 XFS 文件系统？

我使用 XFS 已经很多年了。但是...我想我根本不检测它。如果安装成功，我相信它可以工作。大多数人就是这样做的......文件系统检查是自动化的，如果它启动并且启动并运行，就是这样。

现在，别误会我的意思。我实际上做了大量的监控，但没有一个是特定于文件系统的。我运行 SMART 自测试（select,cont每天执行一个磁盘段，因为long花费的时间太长）。我运行 RAID 检查（也在分段中），并检查奇偶校验是否不匹配 ( mismatch_cnt= 0)。如果其中任何一个失败，我都会收到即时邮件通知，并且一旦 HDD 开始重新分配扇区（或者至少不再信任它们提供重要数据），我实际上会更换 HDD。

因此，我进行监控以确保存储正常工作。这涵盖了驱动器本身内部的错误 (SMART)，在某种程度上也涵盖了更高级别的错误（RAID 检查在某种程度上也测试控制器、电缆、RAID 逻辑等）。

只要工作正常，文件系统也最好也能正常工作。除了像 ZFS/btrfs（将来也可能是 XFS）这样的校验和文件系统之外，除了文件系统本身在内部执行的任何健全性检查之外，在安装时在文件系统级别上运行检查并不是真正概念的一部分。

您的输出表明您也在运行 RAID，并且该 RAID 中有一个发生故障的磁盘；即使这样，也不应该导致 上发生错误md0，除非它是没有冗余的 RAID（RAID0 或已经降级的 RAID1/5/6/10）。

您应该首先解决文件系统层以下的问题。您很难将磁盘错误归咎于 XFS，但这也不是检查磁盘错误的方式。

我想如果您真的想在文件系统之上运行完整读取测试，您可以xfsdump对备份磁盘执行...如果您无论如何都要对文件系统进行完整读取测试，不妨在这在某种程度上是有意义的。

其本质是xfsdump完整地遍历 XFS 文件系统并存储所有文件。因此，这应该尽可能接近完整的读取测试，不包括可用空间。

当然，如果您已经在运行另一个备份系统，那么与文件系统无关的方式实际上是同样的情况（如果该备份系统遇到不仅仅是缺乏权限的读取错误，最好向您发送邮件报告，也是），当然，如果它是增量备份，如果没有定期完整备份，它实际上不会多次读取文件......

但总的来说，只要知道存储可以工作，我们就相信文件系统能够“正常工作”。虽然让每个程序无一例外地提升它遇到的任何和所有 I/O 错误会很好，但我不知道有一个通用的解决方案可以真正做到这一点。每个程序都有自己的错误处理。

答案2

许多关键存储服务器启用“错误恐慌”，这样错误就不会变得更大，导致进一步的数据损坏，或者向用户提供损坏的数据。通过错误恐慌，您可以仅监视恐慌事件或系统停机来检测文件系统错误。

当然，如果您没有冗余系统，一台服务器发生恐慌就意味着实际的停机时间。然而，关键任务系统必须具有冗余。事实上，文件系统上显示此类 I/O 错误的任何数据都不应再使用，并且应尽快断开系统连接，以便备份系统可以启动。不提供数据实际上比提供损坏的数据要好在多数情况下。

根据https://access.redhat.com/solutions/3645252，您可以设置 sysctlfs.xfs.panic_mask=127以使在任何 XFS 文件系统上检测到的任何错误都成为系统恐慌。

为了坚持此配置系统的重新启动，请执行以下操作：

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

答案3

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 XFS filesystem consistency... Note that using xfs_check is NOT recommended. Please use xfs_repair -n instead, for better scalability and speed.

在/etc/fstab第六列或最后一列中，如果它是 a 1or2导致fsckor文件系统检查在每次启动时都会发生的安装...具体是吗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.

相关内容