XFS SSD Cache "Unmountable: Unsupported or no file system"

[kazanjig]

Not sure of the circumstances, but my server now reports its XFS SSD cache as "Unmountable: Unsupported or no file system".

 

Here are the results of xfs_repair:

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 210951268, counted 212661156
        - 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
inode 538653759 - bad extent starting block number 4503567550402429, offset 0
correcting nextents for inode 538653759
bad data fork in inode 538653759
would have cleared inode 538653759
        - 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 = 3
        - agno = 2
inode 538653759 - bad extent starting block number 4503567550402429, offset 0
correcting nextents for inode 538653759
bad data fork in inode 538653759
would have cleared inode 538653759
entry "597feb7aedcf95e3cb07122f8d1e44b66d32bd73_1280x1024_fit.jpg" at block 0 offset 2504 in directory inode 540714325 references free inode 538653759
        would clear inode number in entry at offset 2504...
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
entry "597feb7aedcf95e3cb07122f8d1e44b66d32bd73_1280x1024_fit.jpg" in directory inode 540714325 points to free inode 538653759, would junk entry
bad hash table for directory inode 540714325 (no data entry): would rebuild
would rebuild directory inode 540714325
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

 

After a reboot, the SSD remains unmountable. Not sure where to go from here. Help!

[itimpi]

See the last line!    You need to remove the -n to get anything fixed as otherwise it just a read-only check.   If it asks for it add -L

[kazanjig]

Re-ran with -v. Results below. Hesitant to follow the instructions to destroy the log if there are alternatives but proceeding based on your suggestion.

 

Phase 1 - find and verify superblock...
        - block cache size set to 6177104 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 500453 tail block 500449
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.

 

Edited July 24, 2023 by kazanjig

[kazanjig]

-L seems to have fixed it -- drive is now mounted. Checking for any latent effects. Thank you @itimpi.

[itimpi]

28 minutes ago, kazanjig said:

-L seems to have fixed it -- drive is now mounted. Checking for any latent effects. Thank you @itimpi.

The -L option is frequently required.   Since the mount command has already failed you normally cannot do what the message suggests.    In practice the -L option never seems to cause a problem as the most it would affect is the last file being written.