January 16, 20242 yr Good morning. Overnight, it appears something happened with one of the disks in my array. I was alerted to it due to error notifications that specific shares were not found. Checking the dashboard revealed one of my disks had a message: Unmountable: Unsupported or no file system. Stopping and restarting the array did not fix anything nor did a clean reboot. The server is now running a parity operation since I disabled the disk but was wondering if anyone has seen this before (saw similar threads) and if anything in the logs reveal a cause or best course of action from here? From what I can gather (which is very basic knowledge on my part) the disk seems to have passed the checks? The disk in question is HGST_HUH721010ALE604_2TJ1VM3D - 10 TB (sdc) Thank you very much in advance. apollo-diagnostics-20240116-0903.zip Edited January 16, 20242 yr by Giants56 Attaching log
January 16, 20242 yr 17 minutes ago, Giants56 said: running a parity operation since I disabled the disk Examining your diagnostics, it appears that what you mean by that is that you are rebuilding the unmountable filesystem on disk3. Since emulated disk3 is unmountable, the only possible result of rebuilding is an unmountable filesystem. Why did you do anything before asking here since it seems you didn't know how to proceed? As far as it had gotten when you took the diagnostics, rebuild was going OK, but it hadn't been going long. So probably you haven't made things worse. But, rebuild will not fix this problem. Normally, if a disk becomes disabled, and the emulated disk is also unmountable, we wiil try to repair the emulated filesystem before rebuilding. In your case, it seems you intentionally disabled the disk. Stop rebuild, post new diagnostics.
January 16, 20242 yr You can read this while I look at the new diagnostics you will post and you wait for further advice: https://docs.unraid.net/unraid-os/manual/storage-management/#checking-a-file-system
January 16, 20242 yr Author 21 minutes ago, trurl said: Why did you do anything before asking here since it seems you didn't know how to proceed? I think it started on its own once i removed the disk from the array to try to readd it, but fair point. I’ve stopped the rebuild and re-ran diagnostics. I appreciate the quick reply. apollo-diagnostics-20240116-1004.zip
January 16, 20242 yr Solution 3 minutes ago, Giants56 said: it started on its own once i removed the disk from the array to try to readd it The way you make it rebuild is to reassign the disk to the same slot and start the array. Check filesystem on emulated disk3. Be sure to use the webUI and not the command line. Capture the results and post them.
January 16, 20242 yr Author Here’s the output of the check system process. Should I run it without the “-n”, or is this sufficient? I did not see anything in the linked help article about this particular option. 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_icount 68352, counted 82176 sb_ifree 54, counted 220 sb_fdblocks 2073420622, counted 771470199 - 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 - agno = 8 - agno = 9 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 9 - agno = 5 - agno = 8 - agno = 6 - agno = 7 - agno = 2 - agno = 4 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting.
January 16, 20242 yr Author Thank you Jorge. When running it without -n, I get this brief explanation. I’m not sure if it’s appropriate to run with -L 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 16, 20242 yr 1 minute ago, Giants56 said: run with -L Unraid has already determined the filesystem is unmountable, so you have to -L
January 16, 20242 yr Author Got it. here’s the output with -L 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 destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 68352, counted 82176 sb_ifree 54, counted 220 sb_fdblocks 2073420622, counted 771470199 - 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 - agno = 8 - agno = 9 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 5 - agno = 9 - agno = 4 - agno = 3 - agno = 7 - agno = 8 - agno = 6 - agno = 1 - agno = 2 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 (1:212864) is ahead of log (1:8). Format log to cycle 4. done
January 16, 20242 yr Author Got it. It does look more promising having restarted the array. It went into a data-rebuild process which I paused. But here’s the diagnostic. apollo-diagnostics-20240116-1143.zip
January 16, 20242 yr The repaired filesystem on emulated disk3 is mountable now and has lots of data. Rebuild (assuming it goes well) will have those same contents. Worth noting though, that the only reason a rebuild is necessary is because you disabled the disk. You could have done the repair on the unmountable but not disabled disk. Doesn't look like this has resulted in a lost+found share on that disk for things repair couldn't figure out.
January 16, 20242 yr Author Ok thanks very much. So translated, I made things harder by giving it a go myself and next time should search and then just come here with logs. But at this point, I’ll resume data rebuild and hope for a favorable outcome overall. Sound about right? assuming so thank you so much for your quick and thorough help.
January 17, 20242 yr 19 hours ago, Giants56 said: resume data rebuild Post new diagnostics when done, or if it seems to be having problems, or if you just want us to take another look.
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.