July 22, 20205 yr As stated in the title, one of my data drives cant be mounted: "Unmountable: No file system". The drive worked before. SMART tests (both long and short) complete without issue. SMART logs: tower-smart-20200722-1011.zip xfs_repair -vn output: Phase 1 - find and verify superblock... - block cache size set to 1518952 entries Phase 2 - using internal log - zero log... zero_log: head block 867319 tail block 867260 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 266607078, counted 271722814 - 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 - 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 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Wed Jul 22 11:11:12 2020 Phase Start End Duration Phase 1: 07/22 11:09:04 07/22 11:09:04 Phase 2: 07/22 11:09:04 07/22 11:09:06 2 seconds Phase 3: 07/22 11:09:06 07/22 11:10:16 1 minute, 10 seconds Phase 4: 07/22 11:10:16 07/22 11:10:16 Phase 5: Skipped Phase 6: 07/22 11:10:16 07/22 11:11:12 56 seconds Phase 7: 07/22 11:11:12 07/22 11:11:12 Total run time: 2 minutes, 8 seconds I don't see anything weird, except the fact that it takes a bit longer to complete (20 and 40 sec. on my other drives). i've already rebooted twice. diganostics before first reboot: tower-diagnostics-20200722-0953.zip after first reboot: tower-diagnostics-20200722-1014.zip and after second reboot: tower-diagnostics-20200722-1019.zip I had some other problems a few days back with my drive being marked as unavailable. Simply restarting the array helped back then. Maybe this is related? Should i just run xfs_repair (without -n) and hope for the best? As stated here: https://wiki.unraid.net/Check_Disk_Filesystems#Drives_formatted_with_XFS. I just wanted to check before i accidentally destroy the data on that drive. Any help is incredibly appreciated!
July 22, 20205 yr Community Expert You need to run xfs_repair without -n or nothing will be done, if it asks for it use -L also.
July 22, 20205 yr Author Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - 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 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (2:867326) is ahead of log (1:2). Format log to cycle 5. done I don;t think it did anything special. I'll reboot the system once again (Third times a Charm), maybe that will magically solve my problems...
July 22, 20205 yr Author Never mind.. my impatience got the better of me. Restarting the array out of the maintenance mode showed it working again! thank you for your help!
Archived
This topic is now archived and is closed to further replies.