January 2, 20242 yr 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, 20242 yr by LimeB
January 3, 20242 yr Author 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.
January 3, 20242 yr Author 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.
January 3, 20242 yr Author Solution 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.
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.