Barb

There is a message that "All existing data on this device will be OVERWRITTEN when array is Started". I just want to be sure that as long as all the drives are in the correct place, the data should be fine. Edit: I see that the message only applied to the parity disk. Starting the array is rebuilding parity but the rest of the data on the other disks is untouched. Thanks for the help.

I was trying to remove a drive from the cache pool and accidentally removed both. I reassigned the correct drive as the cache drive, but there was a message saying data would be deleted. Instead I went to Tools->New Config. I accidentally didn't preserve the disk assignments and can't remember which drive went were. I happen to have a diagnostic from a week ago. Were in the logs could I find this information? I looked in syslog, and I see a massage saying import 0 sdd ... disk 0, import 1 sdc ... disk 1... I'm pretty sure that's parity, disk 1, disk 2, etc... but I want to be sure.

Bummer. I lost a few things, but fortunately my back up isn't too old. Thanks for the help and the tips.

Thanks for your help. The cache drive is mounted now, but there are still some issues with the contents of the drive. sidekick-diagnostics-20241003-1047.zip

All the sudden my cache drive became unmountable. I was going to try running btrfs --repair, but I got a warning about not doing so without help from a Dev. Please help me understand what is happening. sidekick-diagnostics-20241002-1926.zip

AMD 3700g ASUS x570-i ASUS 1070ti I have the nvidia drivers and gpu statisctics plugins installed on Unraid. With no drives running the system draws 72-75W. GPU statistics reports 9-10W and state P8. When I start a windows 10 VM and passthough the GPU, my system will draw 84-88W when idle. I expected the power draw to be equal or better with the VM running based on what I've heard online. I am measuring power at the wall. Is this normal? Anything I can check to see why the power draw is higher with the VM running?

I made such a silly mistake. I went back to perform a check and the autocomplete shows I typed -Ln instead of -Lv. I ran the check correctly this time, started the array, and all my data is back. Thank you for looking into this. I swear I spent a while researching what I needed to do beforehand and a silly typo derailed everything.

I have 3 8TB drives. Parity. Disk 1. Disk 2. I was trying to watch a show on Plex and I got an error about files missing. I logged onto Unraid and I saw that there was a red X on Disk 1. The device was disabled and unmountable. The drive was also now showing up under Historical Devices. What was really weird is that even though it said Contents Emulated, when I looked for the files, there were a significant number of files missing. I've had a drive fail before and I was able to see all my files during that time. First thing I tried was swapping cables and that didn't change anything. I did some research and tried a repair. File system is XFS. I ran a check with -nv and then -Lv. The drive still showed up as unmountable and files were still missing. I shut everything down, disconnected the drive, restarted Unraid, and everything looked the same (red X) except now the device showed up as disconnected. I shut everything down again, plugged the drive back in and this time when I restarted there was a yellow triangle next to the drive saying contents emulated. I stopped the array and there was no drive assigned to Disk 1. I selected the drive to assign to Disk 1 and there was a blue square saying New Drive. Weird. I start the array and I get a message saying: Disk 1, drive not ready, content being reconstructed. Also: Parity sync / Data rebuild started. I still can't see most of my files and I was afraid the parity rebuild was going to wipe the drive so I paused the rebuild right away. I'm not sure how to proceed 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_fdblocks 231474589, counted 245099536 - 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 imap claims a free inode 8589934733 is in use, would correct imap and clear inode imap claims a free inode 8589934734 is in use, would correct imap and clear inode - agno = 5 - agno = 6 bad nblocks 43807 for inode 12884902050, would reset to 21279 - 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 = 5 - agno = 3 - agno = 7 - agno = 4 - agno = 6 entry "Succession.S03E05.1080p.WEBRip.x265-RARBG.mp4" at block 0 offset 352 in directory inode 8589934728 references free inode 8589934733 would clear inode number in entry at offset 352... entry "Succession.S03E06.1080p.WEBRip.x265-RARBG.mp4" at block 0 offset 416 in directory inode 8589934728 references free inode 8589934734 would clear inode number in entry at offset 416... bad nblocks 43807 for inode 12884902050, would reset to 21279 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry "Succession.S03E05.1080p.WEBRip.x265-RARBG.mp4" in directory inode 8589934728 points to free inode 8589934733, would junk entry entry "Succession.S03E06.1080p.WEBRip.x265-RARBG.mp4" in directory inode 8589934728 points to free inode 8589934734, would junk entry bad hash table for directory inode 8589934728 (no data entry): would rebuild would rebuild directory inode 8589934728 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (7:2202465) is ahead of log (7:2201629). Would format log to cycle 10. No modify flag set, skipping filesystem flush and exiting. Here is the Check with -nv Phase 1 - find and verify superblock... - block cache size set to 691296 entries Phase 2 - using internal log - zero log... zero_log: head block 2201629 tail block 2201625 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_fdblocks 231474589, counted 245099536 - 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 imap claims a free inode 8589934733 is in use, would correct imap and clear inode imap claims a free inode 8589934734 is in use, would correct imap and clear inode - agno = 5 - agno = 6 bad nblocks 43807 for inode 12884902050, would reset to 21279 - 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 = 5 - agno = 7 - agno = 2 - agno = 6 - agno = 3 - agno = 4 entry "Succession.S03E05.mp4" at block 0 offset 352 in directory inode 8589934728 references free inode 8589934733 would clear inode number in entry at offset 352... entry "Succession.S03E06.mp4" at block 0 offset 416 in directory inode 8589934728 references free inode 8589934734 would clear inode number in entry at offset 416... bad nblocks 43807 for inode 12884902050, would reset to 21279 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 entry "Succession.S03E05.mp4" in directory inode 8589934728 points to free inode 8589934733, would junk entry entry "Succession.S03E06.mp4" in directory inode 8589934728 points to free inode 8589934734, would junk entry bad hash table for directory inode 8589934728 (no data entry): would rebuild would rebuild directory inode 8589934728 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (7:2202465) is ahead of log (7:2201629). Would format log to cycle 10. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Sat Jan 14 21:18:00 2023 Phase Start End Duration Phase 1: 01/14 21:17:48 01/14 21:17:48 Phase 2: 01/14 21:17:48 01/14 21:17:49 1 second Phase 3: 01/14 21:17:49 01/14 21:17:55 6 seconds Phase 4: 01/14 21:17:55 01/14 21:17:55 Phase 5: Skipped Phase 6: 01/14 21:17:55 01/14 21:18:00 5 seconds Phase 7: 01/14 21:18:00 01/14 21:18:00 Total run time: 12 seconds Here is the check with -Lv 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_fdblocks 231474589, counted 245099536 - 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 imap claims a free inode 8589934733 is in use, would correct imap and clear inode imap claims a free inode 8589934734 is in use, would correct imap and clear inode - agno = 5 - agno = 6 bad nblocks 43807 for inode 12884902050, would reset to 21279 - 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 = 5 - agno = 3 - agno = 7 - agno = 4 - agno = 6 entry "Succession.S03E05.mp4" at block 0 offset 352 in directory inode 8589934728 references free inode 8589934733 would clear inode number in entry at offset 352... entry "Succession.S03E06.mp4" at block 0 offset 416 in directory inode 8589934728 references free inode 8589934734 would clear inode number in entry at offset 416... bad nblocks 43807 for inode 12884902050, would reset to 21279 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry "Succession.S03E05.mp4" in directory inode 8589934728 points to free inode 8589934733, would junk entry entry "Succession.S03E06.mp4" in directory inode 8589934728 points to free inode 8589934734, would junk entry bad hash table for directory inode 8589934728 (no data entry): would rebuild would rebuild directory inode 8589934728 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (7:2202465) is ahead of log (7:2201629). Would format log to cycle 10. No modify flag set, skipping filesystem flush and exiting. sidekick-diagnostics-20230114-2224.zip