existing disk now Unmountable

[Devil2U]

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.

[itimpi]

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

[Devil2U]

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

Edited August 16, 2017 by Devil2U

[itimpi]

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?