May 28, 20206 yr I have had problems with one of my disks in my array since i installed it... A couple of days ago i found it with "Unmountable: No file system" error. I assume it failed without doing much of any testing. I have now preformed a parity sync / data rebuild on the replacement disk but that one also has the same error. In the array operation tab i get the option to format the disk. In the guide i found on how to replace a failed disk it says nothing about having to format it after data rebuild The guide i found: https://wiki.unraid.net/Replacing_a_Data_Drive Edited May 28, 20206 yr by PetterH
May 28, 20206 yr Community Expert Do NOT format it unless you want to lose its contents. You might want to read this section of the official documentation. If a disk shows as unmountable before doing a rebuild then it will always show the same after a rebuild. The way to clear an ‘unmountable’ status is to run the appropriate file system repair tool.
May 28, 20206 yr Author @itimpi I ran the xfs repair tool and got the following: 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... agi unlinked bucket 28 is 156 in ag 5 (inode=10737418396) sb_ifree 365, counted 458 sb_fdblocks 1299601301, counted 1315296881 - 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 Metadata CRC error detected at 0x44d70d, xfs_bmbt block 0x280768818/0x1000 - agno = 5 Metadata CRC error detected at 0x44d70d, xfs_bmbt block 0x280768818/0x1000 btree block 5/971016 is suspect, error -74 bad magic # 0x241a9c92 in inode 10737418396 (data fork) bmbt block 1343148296 bad data fork in inode 10737418396 would have cleared inode 10737418396 - 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 = 3 - agno = 5 - agno = 6 - agno = 4 - agno = 1 - agno = 7 - agno = 2 bad magic # 0x241a9c92 in inode 10737418396 (data fork) bmbt block 1343148296 bad data fork in inode 10737418396 would have cleared inode 10737418396 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... Maximum metadata LSN (1984442613:-916355275) is ahead of log (3:1668473). Would format log to cycle 1984442616. No modify flag set, skipping filesystem flush and exiting. Do i remove the -n option and run again or?
May 28, 20206 yr Author So i ran it again without the -n option and it told me to run it with an -L option. Now what? This is after running it with the -L 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 destroyed because the -L option was used. - scan filesystem freespace and inode maps... agi unlinked bucket 28 is 156 in ag 5 (inode=10737418396) sb_ifree 365, counted 458 sb_fdblocks 1299601301, counted 1315296881 - 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 Metadata CRC error detected at 0x44d70d, xfs_bmbt block 0x280768818/0x1000 - agno = 5 Metadata CRC error detected at 0x44d70d, xfs_bmbt block 0x280768818/0x1000 btree block 5/971016 is suspect, error -74 bad magic # 0x241a9c92 in inode 10737418396 (data fork) bmbt block 1343148296 bad data fork in inode 10737418396 cleared inode 10737418396 - 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 = 1 - agno = 5 - agno = 0 - agno = 2 - agno = 3 - agno = 6 - agno = 7 - agno = 4 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... Metadata corruption detected at 0x44d608, xfs_bmbt block 0x280768818/0x1000 libxfs_writebufr: write verifier failed on xfs_bmbt bno 0x280768818/0x1000 Maximum metadata LSN (1984442613:-916355275) is ahead of log (1:2). Format log to cycle 1984442616. releasing dirty buffer (bulk) to free list! done
May 28, 20206 yr Author okey so apperantly i only had to stop the array to exit maintinance mode and start it again to normal and now its good thanks @itimpi
Archived
This topic is now archived and is closed to further replies.