January 22, 20242 yr Hello Helpful People, About two weeks ago I looked the the Main tab of the Unraid dashboard and found that Data Disk 1 had no supported file type and we could not write to that disk. The disk has been part of my array for years and had a majority of our data on it. I stopped the array and ran fsx_repair from Disk 1 Settings > File System Check and it repaired the partition. We were up and running. Now two weeks later I am getting some of the same warnings (although the file system is not preventing from writing to the disk at this point.) I don't see any Smart errors but does anyone know any tests or diagnostics I can run to determine if this is a hardware problem with this drive before I "jump down the rabbit hole" too far? Unraid 6.12.6 ciserver-smart-20240122-0853.zip ciserver-diagnostics-20240122-1149.zip
January 22, 20242 yr Community Expert That's usually only a filesystem problem, check filesystem on that disk, run it without -n.
January 22, 20242 yr Author Two weeks ago I ran the following: xfs_repair -L /dev/md1 This "repaired" the file system but I am back here again. Is this the command that you are suggesting that I run again?
January 22, 20242 yr Community Expert The device name can vary according to the Unraid release (and whether encryption is used). It is better if you run it via the GUI as that will automatically select the correct device name.
January 22, 20242 yr Author I did actually run is in the GUI. I just removed the "-n" and replaced it with "-L" while in Maintenance Mode and hit the "Check" button. Is there something incorrect in the command that I ran or should this have resolved the issue so that I wouldn't have to run it again just two weeks later? Edited January 22, 20242 yr by rdagitz
January 22, 20242 yr Author I went ahead and ran the fix again. Stopped the array Started in Maintenance Mode Went to Disk 1 Settings > Check File System Removed the -n and put in -L and hit the Check button Below is the output of the Check Quote Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - 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 bad CRC for inode 2478582022 bad CRC for inode 2478582022, will rewrite cleared inode 2478582022 bad CRC for inode 2542151719 inode identifier 17941646034858475519 mismatch on inode 2542151719 bad CRC for inode 2542151719, will rewrite inode identifier 17941646034858475519 mismatch on inode 2542151719 cleared inode 2542151719 - 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 = 3 - agno = 0 - agno = 2 entry "X5iMxkA46w170196728289120821" in shortform directory 2490719384 references free inode 2542151719 junking entry "X5iMxkA46w170196728289120821" in directory inode 2490719384 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 ... disconnected dir inode 2542151720, moving to lost+found disconnected dir inode 4923619919, moving to lost+found disconnected dir inode 4923619940, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 284073 nlinks from 2 to 5 resetting inode 2490719384 nlinks from 3 to 2 Maximum metadata LSN (46:1368543) is ahead of log (1:2). Format log to cycle 49. done
January 23, 20242 yr Community Expert 1 hour ago, rdagitz said: I went ahead and ran the fix again. Stopped the array Started in Maintenance Mode Went to Disk 1 Settings > Check File System Removed the -n and put in -L and hit the Check button Below is the output of the Check Have you restarted in Normal mode to check that the drive now mounts and seems to have its data intact? Any files/folders for which the repair process cannot find the correct name will have been put into a lost+found folder on the drive.
January 23, 20242 yr Community Expert 9 hours ago, rdagitz said: Removed the -n and put in -L and hit the Check button You should only use -L if asked to by xfs_repair.
January 23, 20242 yr Author Ran the check again without the -L Quote 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 = 2 - agno = 1 - 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... done Looks good to me. Thoughts?
January 23, 20242 yr Community Expert 2 minutes ago, rdagitz said: Ran the check again without the -L Looks good to me. Thoughts? Have you restarted the array in normal mode and then checked the disk contents as it should now mount.
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.