kazanjig Posted July 24, 2023 Share Posted July 24, 2023 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! Quote Link to comment
itimpi Posted July 24, 2023 Share Posted July 24, 2023 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 Quote Link to comment
kazanjig Posted July 24, 2023 Author Share Posted July 24, 2023 (edited) 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 Quote Link to comment
kazanjig Posted July 24, 2023 Author Share Posted July 24, 2023 -L seems to have fixed it -- drive is now mounted. Checking for any latent effects. Thank you @itimpi. Quote Link to comment
itimpi Posted July 24, 2023 Share Posted July 24, 2023 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.