XFS repair or drive rebuild?

[djuniah]

It appears as though i have some filesystem corruption.  I've checked my SMART values and everything seems normal there so i'm thinking it's not a hardware related issue.  This all started with an "Unmountable: No file system" message after a bad shutdown (power loss i believe).  After starting the array in maintenance mode and running "xfs_repair -v /dev/md3" I get a "filesystem has valuable metadata changes in a log which needs to be replayed." message.  Which it then suggests either mounting the filesystem to replay the log, or re-running with -L to clear the log and repair.  I have a few questions:

 

- Does starting the array in maintenance mode count as trying to mount it?  I assume with unraid that i shouldn't be manually trying to mount any /dev/md# devices right?

- Would it be safer to just shut down, pull the drive, wipe it, and then have unraid use parity to rebuild it? Or should I attempt the repair? If i do attempt the repair, would that affect parity at all?

[JorgeB]

1 minute ago, djuniah said:

Does starting the array in maintenance mode count as trying to mount it? 

No, you could try a manual mount but it usually fails.

 

Rebuilding won't fix filesystem corruption, just use -L, usually there's no data loss.

[djuniah]

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...
sb_ifree 760, counted 672
sb_fdblocks 832117916, counted 833084897
       - found root inode chunk
Phase 3 - for each AG...
       - scan and clear agi unlinked lists...
       - process known inodes and perform inode discovery...
       - agno = 0
Metadata CRC error detected at 0x417105, xfs_dir3_block block 0x4fd8/0x1000
bad directory block magic # 0x74760a33 in block 0 for directory inode 20449
corrupt block 0 in directory inode 20449
       will junk block
no . entry for directory 20449
no .. entry for directory 20449
problem with directory contents in inode 20449
cleared inode 20449
       - 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 = 0
       - agno = 1
       - agno = 2
       - agno = 3
entry "__ADMIN__" at block 0 offset 96 in directory inode 6442552432 references free inode 20449
       clearing inode number in entry at offset 96...
Phase 5 - rebuild AG headers and trees...
       - reset superblock...
Phase 6 - check inode connectivity...
       - resetting contents of realtime bitmap and summary inodes
       - traversing filesystem ...
bad hash table for directory inode 6442552432 (no data entry): rebuilding
rebuilding directory inode 6442552432
       - traversal finished ...
       - moving disconnected inodes to lost+found ...
disconnected inode 20454, moving to lost+found
disconnected inode 20455, moving to lost+found
disconnected inode 20457, moving to lost+found
disconnected inode 20459, moving to lost+found
disconnected inode 20460, moving to lost+found
disconnected inode 20461, moving to lost+found
disconnected inode 20465, moving to lost+found
disconnected inode 20466, moving to lost+found
disconnected inode 20467, moving to lost+found

After that I stopped the array, then restarted it in maintenance mode and i'm still seeing a "No Filesystem" error.  Any thoughts on why that may still be?

[JorgeB]

38 minutes ago, djuniah said:

then restarted it in maintenance mode and i'm still seeing a "No Filesystem" error.

That's normal in maintenance mode, since no disks are mounted, just start in normal mode.

[djuniah]

Ah thanks! Didn't realize that.  In the Lost+Found dir i'm seeing about 32 files who's names are just "20454, 20455, 20457,....etc" (basically the disconnected inode names from my previous post) and they are of varying sizes from 1kb to 750kb outside of looking at the file contents directly and hoping to find header info, do you have any suggestions on how to figure out what they might be?

[JorgeB]

Just now, djuniah said:

outside of looking at the file contents directly and hoping to find header info, do you have any suggestions on how to figure out what they might be?

No, sorry.

[djuniah]

Ok thanks for the help/quick replies!  Truly appreciated.