November 28, 20178 yr (Unraid 6.3.5) Hi all! I have an umountable disk on my array and I'm trying to fix it. I'm trying to follow the instructions here: https://wiki.lime-technology.com/Check_Disk_Filesystems#Drives_formatted_with_XFS I've started the array in maintenance mode and I've gotten the results from xfs_repair with the -nv options. On the help page it says: Quote If however issues were found, the display of results will indicate the recommended action to take. Typically, that will involve repeating the command with a specific option, clearly stated, which you will type into the options box (including any hyphens, usually 2 leading hyphens). Here is the report output: Phase 1 - find and verify superblock... - block cache size set to 6061368 entries Phase 2 - using internal log - zero log... zero_log: head block 1090613 tail block 1090605 - scan filesystem freespace and inode maps... agi unlinked bucket 26 is 1208760090 in ag 0 (inode=1208760090) sb_ifree 2646, counted 2777 sb_fdblocks 132148717, counted 134296216 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - 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 = 3 - agno = 2 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 1208760090, would move to lost+found Phase 7 - verify link counts... would have reset inode 1208760090 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Nov 28 18:02:24 2017 Phase Start End Duration Phase 1: 11/28 18:01:48 11/28 18:01:48 Phase 2: 11/28 18:01:48 11/28 18:01:48 Phase 3: 11/28 18:01:48 11/28 18:02:06 18 seconds Phase 4: 11/28 18:02:06 11/28 18:02:06 Phase 5: Skipped Phase 6: 11/28 18:02:06 11/28 18:02:24 18 seconds Phase 7: 11/28 18:02:24 11/28 18:02:24 Total run time: 36 seconds Should I do a repair? What should my next step be to get my data back? Any help would be deeply appreciated. Edited November 28, 20178 yr by wackydog
November 28, 20178 yr Author Hi Jonnie! Thanks for the quick reply|! Here is the result 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. So I'll follow the instructions and see how it goes Edited November 28, 20178 yr by wackydog didn't get it all in
November 28, 20178 yr Author So I presume I have to do the -L option if starting the array gives me 'disk unmountable' ?
November 28, 20178 yr Community Expert 2 minutes ago, wackydog said: So I presume I have to do the -L option Correct
November 28, 20178 yr Author So, this was the output: Phase 1 - find and verify superblock... - block cache size set to 6061368 entries Phase 2 - using internal log - zero log... zero_log: head block 1090613 tail block 1090605 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... agi unlinked bucket 26 is 1208760090 in ag 0 (inode=1208760090) sb_ifree 2646, counted 2777 sb_fdblocks 132148717, counted 134296216 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 1208760090, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (5:1090609) is ahead of log (1:2). Format log to cycle 8. XFS_REPAIR Summary Tue Nov 28 18:42:47 2017 Phase Start End Duration Phase 1: 11/28 18:40:16 11/28 18:40:16 Phase 2: 11/28 18:40:16 11/28 18:40:54 38 seconds Phase 3: 11/28 18:40:54 11/28 18:41:13 19 seconds Phase 4: 11/28 18:41:13 11/28 18:41:13 Phase 5: 11/28 18:41:13 11/28 18:41:13 Phase 6: 11/28 18:41:13 11/28 18:41:30 17 seconds Phase 7: 11/28 18:41:30 11/28 18:41:30 Total run time: 1 minute, 14 seconds done Can I just restart the array? If disconnected inodes were moved to lost and found, do I lose data? Can I rebuild missing files from parity?
November 28, 20178 yr Community Expert 7 minutes ago, wackydog said: Can I just restart the array? Yes, check the lost+found folder, it's usually empty. 8 minutes ago, wackydog said: Can I rebuild missing files from parity? No, parity can't help with filesystem corruption.
November 28, 20178 yr Author OK, it's back online. Thanks for the help! I guess my next step is to do a non-writing parity check and also an extended Smart test on the drive. Does the parity check show problems when the file system is repaired? Should I be concerned about the disk health if the extended smart test is all green?
November 28, 20178 yr Community Expert Filesystem corruption usually has nothing to do with drive health, though it's possible, but most times it's the result of unclean shutdowns.
November 28, 20178 yr Author Good to hear! I hope the parity and extended SMART test show green. Thank you so much for your quick response. I REALLY appreciate it. You're the man
Archived
This topic is now archived and is closed to further replies.