Devil2U Posted August 15, 2017 Share Posted August 15, 2017 An existing 2TB disk I have been using since the build of my Uraid system is now showing up as Unmountable. I noticed this after 2-3 times of starting the mover which stopped shortly thereafter. Based on other research, I decided to Check Filesystem Status on the drive. (-n) This was the result: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0xaea86661/0x200 flfirst 118 in agf 3 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan agi unlinked bucket 56 is 4184696 in ag 3 (inode=3225410168) sb_icount 122048, counted 121856 sb_ifree 968, counted 1139 sb_fdblocks 19159410, counted 19734110 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 3225410168, would move to lost+found Phase 7 - verify link counts... would have reset inode 3225410168 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. When I try and run the repair without the -n, I get this message: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. The system log also shows the following warning over and over... Tower rc.diskinfo[5818]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Thoughts and suggestions are appreciated. Let me know if you have any questions. Thanks. Link to comment
itimpi Posted August 15, 2017 Share Posted August 15, 2017 Running with the -L option ty[ically works fine and repairs without any data loss. i have also found that a mount from the command line normally works even though it fails from the unRAID Level. I put together a little script for myself that does a mount/umount on each drive and then runs xfs_repair without needing the -L option Link to comment
Devil2U Posted August 16, 2017 Author Share Posted August 16, 2017 Ok, ran that with -L Not exactly sure how to interpret this result, or what the next step should be (start mover again, verify parity?) The disk DID mount and the array is online. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0xaea86661/0x200 flfirst 118 in agf 3 too large (max = 118) agi unlinked bucket 56 is 4184696 in ag 3 (inode=3225410168) sb_icount 122048, counted 121856 sb_ifree 968, counted 1139 sb_fdblocks 19159410, counted 19734116 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 3225410168, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (1:355410) is ahead of log (1:2). Format log to cycle 4. done Link to comment
itimpi Posted August 16, 2017 Share Posted August 16, 2017 You should be good to go and do whatever you would normally do. Parity is maintained during the repair (as long as the array was started in Maintenance mode at the time) so it is not necessary to run a check. However periodic parity checks are good housekeeping so It might be time to do one as part of your normal process? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.