February 21, 20233 yr Author Thanks, JorgeB. I proceeded as you indicated. Below are the results (the first block was run with just -v, and the second block was run with -Lv . I then tried to start the array in normal mode (not maintenance), which triggered a rebuild. But then it occurred to me that Disk 1 was set as "Not Installed" (recall that I have two drives with an issue). I had removed Disk 1 using the GUI, to avoid the chance that at some point it might try to rebuild that drive onto itself, as opposed to a replacement drive. I wasn't sure if not having anything assigned to Disk 1 might create a problem for the rebuild of Disk 12, so I immediately cancelled the rebuild of Disk 12 using the GUI, and stopped the array. The GUI currently reads "Start will bring the array on-line and start Data-Rebuild." Which of the following should I do now, or should I do something else? Option A) restart the array in normal mode, with Disk 1 left as "Not Installed" and Disk 12 assigned to the 10TB drive that was just repaired with -L Option B) reassign Disk 1 to the original 14TB that UNRAID disabled (and which I believe UNRAID regards as unmountable), then restart the array in normal mode with Disk 12 assigned to the 10TB drive that was just repaired with -L Option C) replace Disk 1 with one of my new precleared 14 TB drives, then restart the array in normal mode with Disk 12 assigned to the 10TB drive that was just repaired with -L I guess I'm just not quite sure if any of this might trigger a parity check as part of the data rebuild, and I want to make sure the system is properly configured should that occur. I'm also not quite clear how emulation is fitting into this picture as well. For example, is emulation occurring if no drive is assigned to Disk 1? And would UNRAID at some point *forget* the need to emulate Disk 1? I still don't quite understand why certain files appear lost despite messages indicating that both Disk 1 and Disk 12 were being emulated. Is there a link or forum post that you could point me to, so I could understand that part better? Thanks again so much! Dave BLOCK 1 Phase 1 - find and verify superblock... - block cache size set to 3005320 entries sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... zero_log: head block 1075093 tail block 1075089 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. BLOCK 2 Phase 1 - find and verify superblock... - block cache size set to 3005320 entries sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... zero_log: head block 1075093 tail block 1075089 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 0, counted 262400 sb_ifree 0, counted 1948 sb_fdblocks 2441087425, counted 140977217 - 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 = 1 - agno = 3 - agno = 6 - agno = 2 - agno = 5 - agno = 8 - agno = 7 - agno = 4 - agno = 9 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - 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 - agno = 8 - agno = 9 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:1075085) is ahead of log (1:2). Format log to cycle 4. XFS_REPAIR Summary Tue Feb 21 10:56:10 2023 Phase Start End Duration Phase 1: 02/21 10:53:21 02/21 10:53:21 Phase 2: 02/21 10:53:21 02/21 10:53:49 28 seconds Phase 3: 02/21 10:53:49 02/21 10:54:23 34 seconds Phase 4: 02/21 10:54:23 02/21 10:54:23 Phase 5: 02/21 10:54:23 02/21 10:54:23 Phase 6: 02/21 10:54:23 02/21 10:54:54 31 seconds Phase 7: 02/21 10:54:54 02/21 10:54:54 Total run time: 1 minute, 33 seconds done
February 21, 20233 yr Community Expert Since you have dual parity, you can avoid rebuild by not having anything assigned as either disk. Then starting the array in normal mode will let us see the emulated disks and decide what needs to be done before rebuilding.
February 21, 20233 yr Author Thanks, trurl! I made sure both disks were removed (via GUI), and I started the array in normal mode. Both disks now have a red 'x' next to them. The mouseover says "Device is missing (disabled). Contents emulated" for both disks. Attached is an updated diagnostic file. Thanks! Dave nas24-diagnostics-20230221-1452.zip
February 21, 20233 yr Community Expert Emulated disk12 is mounted and 95% full. Emulated disk1 is unmountable. Check filesystem on disk1
February 21, 20233 yr Author Thanks, trulrl. I stopped the array to run xfs_repair via the GUI, and I have checked the "maintenance mode" box. There is a message next to that box that says "Maintenance mode - if checked, Start array but do not mount disks." However, above that message is another message indicating "Start will start Parity-Sync and/or Data-Rebuild." If I click "Start" to start the array, will UNRAID actually start a parity-sync and/or data-rebuild as the message is indicating, or will it just let me access Disk 1 so I can run xfs_repair in maintenance mode? I just want to make sure it doesn't try to rebuild Disk 1 onto itself, which I think would be bad. Thanks! Dave
February 21, 20233 yr Author Also, I should note that in the GUI Disk 1 now appears in blue, with the mouseover text showing "New device."
February 22, 20233 yr Community Expert 3 hours ago, DaveW42 said: Start will start Parity-Sync and/or Data-Rebuild Aren't disks 1, 12 still not assigned?
February 22, 20233 yr Author I believe I assigned disk 1 in order to see the option to run xfs_repair on it. If I don't assign it, it goes to Unassigned Disks and I don't see the option to run xfs_repair on that drive ...
February 22, 20233 yr Community Expert You do the repair on the emulated disk, not on the physical disk. Leave both disks 1, 12 unassigned and it won't rebuild anything. Could be it didn't know the filesystem of emulated disk since it is unmountable, so it didn't offer to let you check filesystem. We can fix that. Unassign disks 1, 12, start the array, and post new diagnostics
February 22, 20233 yr Author Thanks, trurl! Disk 1 and Disk 12 now appear with red x's as "Not installed." I started the array in maintenance mode. Attached is the diagnostic file. Thanks! Dave nas24-diagnostics-20230221-2204.zip
February 22, 20233 yr Community Expert 3 minutes ago, DaveW42 said: started the array in maintenance mode Can't tell anything about filesystems that way since no disks are mounted. Probably nothing has changed, but let's make sure. Start the array in normal mode with nothing assigned as disks 1, 12 and post new diagnostics.
February 22, 20233 yr Author Thanks, trurl. Disk 1 and Disk 12 still appear with red x's as "Not installed." I started the array in normal mode. Attached is the new diagnostic file. Thanks! Dave nas24-diagnostics-20230221-2244.zip
February 22, 20233 yr Community Expert OK, still like this and still what you need to do. Don't reassign any disks. 7 hours ago, trurl said: Emulated disk12 is mounted and 95% full. Emulated disk1 is unmountable. Check filesystem on disk1 And it knows disk1 is xfs so you shouldn't have this problem. 2 hours ago, trurl said: Could be it didn't know the filesystem of emulated disk since it is unmountable, so it didn't offer to let you check filesystem.
February 22, 20233 yr Author Hi, trurl. I'm not quite sure what you are asking me to do as a next step. Could you clarify? The array is currently running in normal mode, with no disks assigned as Disk 1 and Disk 12. The 14TB disk that was disabled (i.e., as Disk 1) currently appears as Dev 2 in Unassigned Devices. It is also labelled as sdd and is not mounted. The 10TB disk that we ran -L on (i.e., as Disk 12) is in Unassigned Devices as Dev 1 (sdh), and is not mounted. When I click on Dev 2 in Unassigned Devices, there is no area for me to run xfs_repair via the GUI. If I am understanding the manual correctly, this is the part where I need to be very careful and make sure to fix the drive by going through unRAID parity management. Since the Disk 1 14TB drive is currently placed in Unassigned Devices, I believe this means that that drive is not on the array and is not currently regarded as a participant in unRAID parity management. Do we need to do our next steps via the terminal, since the GUI does not show xfs_repair for Dev 2? Also, as a quick reminder from my first post, this particular 14TB drive was disabled by UNRAID, and I have taken no steps with it since that time (i.e., I have NOT yet tried to replace this drive with a new drive, to let it sync/rebuild based on the emulated version of the disabled drive). Would it be safer to just sync/rebuild this drive onto a new precleared drive, and then run xfs on the replacement drive? Please let me know. Thanks again for the help and insight! Dave
February 22, 20233 yr Community Expert Why did you unassign disk12? It will need to be rebuilt now. Last diags posted are full of spam, please reboot and pot new diags after array start.
February 22, 20233 yr Community Expert 4 hours ago, JorgeB said: Why did you unassign disk12? It will need to be rebuilt now It already needed rebuilding. He reassigned it before we were ready. I had him unassign it so nothing would be rebuilt until we had repaired disk1. 4 hours ago, JorgeB said: Last diags posted are full of spam, please reboot and pot new diags after array start. Reboot is OK to clear the logs. Leave disk1 and disk12 unassigned. 7 hours ago, DaveW42 said: what you are asking me to do Start the array in normal mode with nothing assigned as disks 1, 12. That way it won't begin rebuilding anything, and we can check the contents of emulated disks 1, 12, and work on repairing emulated disk1. Then post new diagnostics
February 22, 20233 yr Community Expert 46 minutes ago, trurl said: It already needed rebuilding. He reassigned it before we were ready. I had him unassign it so nothing would be rebuilt until we had repaired disk1. OK, must have missed that, because initially disk12 was not disabled, just ummountable.
February 22, 20233 yr Community Expert 5 minutes ago, JorgeB said: initially disk12 was not disabled, just ummountable Reviewing the thread, that is the case in the beginning, and he needlessly unassigned it. After we got emulated disk12 repaired, and before we had repaired disk1, he apparently reassigned both disks because it wouldn't let him check filesystem on auto fs disk1. Then rebuild started, so I had him unassign both so we could continue working on disk1 repair.
February 22, 20233 yr Author Sorry for any missteps on my part! I am trying the best I can to proceed step-by-step through the guidance provided. Since I am a newbie to the inner workings of unRAID, I hadn't realized the significance of unassigning a drive and what the implications were. Thanks for clarifying the next step, trurl: 1 hour ago, trurl said: Start the array in normal mode with nothing assigned as disks 1, 12. That way it won't begin rebuilding anything, and we can check the contents of emulated disks 1, 12, and work on repairing emulated disk1. Then post new diagnostics Current state of machine: Disk 1 and Disk 12 still appear with red x's as "Not installed." Array is running in normal mode. Attached is the new diagnostic file. Thanks, Dave nas24-diagnostics-20230222-0939.zip
February 22, 20233 yr Community Expert Stop the array, then start the array in maintenance mode and post the output of: xfs_repair -v /dev/md1
February 22, 20233 yr Author Thanks, JorgeB! I have stopped the array and started it again in maintenance mode. Should I run that command via the terminal? Note that unRAID does not currently give me the option to run xfs_repair via the GUI on an unassigned device. Dave
February 22, 20233 yr Community Expert 7 minutes ago, DaveW42 said: Should I run that command via the terminal? Yep.
February 22, 20233 yr Community Expert 8 minutes ago, DaveW42 said: does not currently give me the option to run xfs_repair via the GUI on an unassigned device. And for the moment we don't care about the unassigned devices, only the emulated disks.
February 22, 20233 yr Author Thanks! And thanks also for the additional comment regarding our focus on emulated disks (it helps me better understand this process). Below is the requested output. Dave xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock - block cache size set to 2975488 entries Phase 2 - using internal log - zero log... zero_log: head block 2227444 tail block 2227440 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.
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.