Unmountable: Unsupported or no file system

[LimeB]

A few days ago I noticed that my server was acting up which the GUI was kind of working but then when I was trying to navigate to a few areas it just all together stopped working. I ended up having to do a hard reset on the box and now it is back up the main data disk I care about comes up as "Unmountable: Unsupported or no file system". Attached is the diagnostics after booting up now.

 

Edited January 3 by LimeB

[JorgeB]

Check filesystem on disk2, run it without -n.

[LimeB]

I did that through the GUI method and this came up immediately:

 

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.

[LimeB]

I also did -n and this came up:

 

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

ignored because the -n option was used.  Expect spurious inconsistencies

which may be resolved by first mounting the filesystem to replay the log.

        - scan filesystem freespace and inode maps...

sb_fdblocks 1348690186, counted 1369121098

        - 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

inode 6892288466 - bad extent starting block number 4503567551069610, offset 0

correcting nextents for inode 6892288466

bad data fork in inode 6892288466

would have cleared inode 6892288466

        - agno = 4

        - agno = 5

        - agno = 6

        - agno = 7

        - agno = 8

        - agno = 9

        - agno = 10

        - process newly discovered inodes...

Phase 4 - check for duplicate blocks...

        - setting up duplicate extent list...

        - check for inodes claiming duplicate blocks...

        - agno = 0

        - agno = 2

        - agno = 6

        - agno = 3

        - agno = 5

        - agno = 7

        - agno = 1

        - agno = 8

        - agno = 9

        - agno = 10

        - agno = 4

entry "2013-11-28 002.JPG" at block 0 offset 128 in directory inode 6892288464 references free inode 6892288466

                would clear inode number in entry at offset 128...

inode 6892288466 - bad extent starting block number 4503567551069610, offset 0

correcting nextents for inode 6892288466

bad data fork in inode 6892288466

would have cleared inode 6892288466

No modify flag set, skipping phase 5

Phase 6 - check inode connectivity...

        - traversing filesystem ...

entry "2013-11-28 002.JPG" in directory inode 6892288464 points to free inode 6892288466, would junk entry

bad hash table for directory inode 6892288464 (no data entry): would rebuild

would rebuild directory inode 6892288464

        - traversal finished ...

        - moving disconnected inodes to lost+found ...

Phase 7 - verify link counts...

No modify flag set, skipping filesystem flush and exiting.

[LimeB]

I ended up stumbling on this video and went with using the -L flag. After doing so, all is well again it seems. I also just realized I ran into corruption a few years ago and read through that thread as well. That one I also went through the repair with -L.