실패한 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/fstab여섯 번째 또는 마지막 열 에서 , 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.