Xfs_repair output

Rocky Linux Help & Support
1

Hello,

We suspect that our filesystem was corrupted so we run an xfs_repair command. Checking the output I can not say if there was a corruption. Does anyone knows how to interpret the following output ?

Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
        - 10:05:43: zeroing log - 215039 of 215039 blocks done
        - scan filesystem freespace and inode maps...
        - 10:05:48: scanning filesystem freespace - 51 of 51 allocation groups done
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - 10:05:48: scanning agi unlinked lists - 51 of 51 allocation groups done
        - process known inodes and perform inode discovery...
        - agno = 30
        - agno = 0
        - agno = 15
        - agno = 45
        - agno = 46
        - agno = 47
        - agno = 31
        - agno = 1
        - agno = 16
        - agno = 48
        - agno = 49
        - agno = 32
        - agno = 2
        - agno = 50
        - agno = 17
        - agno = 33
        - agno = 34
        - agno = 18
        - agno = 3
        - agno = 35
        - agno = 36
        - agno = 19
        - agno = 37
        - agno = 4
        - agno = 38
        - agno = 39
        - agno = 20
        - agno = 40
        - agno = 5
        - agno = 41
        - agno = 42
        - agno = 21
        - agno = 43
        - agno = 6
        - agno = 44
        - agno = 22
        - agno = 7
        - agno = 23
        - agno = 8
        - agno = 24
        - agno = 9
        - agno = 25
        - agno = 10
        - agno = 26
        - agno = 11
        - agno = 27
        - agno = 12
        - agno = 28
        - agno = 13
        - agno = 29
        - agno = 14
        - 10:16:46: process known inodes and inode discovery - 21194432 of 21068448 inodes done
        - process newly discovered inodes...
        - 10:16:46: process newly discovered inodes - 51 of 51 allocation groups done
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - 10:16:47: setting up duplicate extent list - 51 of 51 allocation groups done
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 11
        - agno = 10
        - agno = 2
        - agno = 15
        - agno = 5
        - agno = 8
        - agno = 7
        - agno = 3
        - agno = 9
        - agno = 4
        - agno = 1
        - agno = 14
        - agno = 6
        - agno = 12
        - agno = 13
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - agno = 32
        - agno = 33
        - agno = 34
        - agno = 35
        - agno = 36
        - agno = 37
        - agno = 38
        - agno = 39
        - agno = 40
        - agno = 41
        - agno = 42
        - agno = 43
        - agno = 44
        - agno = 45
        - agno = 46
        - agno = 47
        - agno = 48
        - agno = 49
        - agno = 50
clearing reflink flag on inodes when possible
        - 10:16:51: check for inodes claiming duplicate blocks - 21194432 of 21068448 inodes done
Phase 5 - rebuild AG headers and trees...
        - 10:16:56: rebuild AG headers and trees - 51 of 51 allocation groups done
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - 10:20:43: rebuild AG headers and trees - 51 of 51 allocation groups done
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
        - 10:28:19: verify and correct link counts - 51 of 51 allocation groups done
done
2

Can you edit the post.

You are supposed to show the unmount command, then the xfs repair command, and then the return value.

In addition, it would be best to say why you think the filesystem is corrupt in case it’s some other problem.

3

Hello,

yes first we umount the filesystem i.e umount /home/students/ and then run the command
xfs_repair /dev/SHomeVG/StudentsLV ===> this is the name of the block device , since we use lvm
Unfortunately I didn’t run the echo command when it finished.
We suspect that the fs causes us problems because we had various problems with students logging on linux workstations( Students home directories resits on the fs, and exported through nfs to Rocky 9.4 clients). Some students could login to their accounts, some others no. When we tried to delete on the nfs server the directory with name .cache on those students home directory, files in this directory could not be deleted, although we poweroff all the clients. When we rebooted the server, we were able to delete the .cache.
Of course the problem with the .cache could happen also because we use nvidia card, and is the primary card on some of the machine. We haven’t figure out yet what causes this weird problem.
We also have this problem when we have heavy load on the server i.e too many students login from more than 60 clients at the same time.
So we first start to check the filesystem and then think what else can cause this problem