Barb

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

This IP address discrepancy has been there for a few months. It doesn't cause any problems (that I'm aware of) but I would like to know what's going on.

After I setup Unraid on an old computer I assigned a static IP address based on the MAC address (192.168.X.X). When I look at the client list in my router (ASUS AX88U), the Unraid server shows as having and IP address of 169.254.X.X instead of 192.168.X.X. Also, when I hover over the Unraid server in the client list I see a message that "2 clients are connected through this device". I don't know if this is related. I can access the server by typing in 192.168.X.X on another machine, so what gives?

I was in the middle of watching a movie via Plex on android when all of the sudden the movie stopped playing. I couldn't get it to play again on my phone. I tried accessing the file directly on my Win10 machine and I couldn't open or copy the .mkv file. Eventually I found that permission for the file had changed from "-rw-rw-rw-" to "-rw------- I used chmod a+rw to restore the original file permission, but why would the permission have changed in the first place?

This is a problem I notice when using Plex. I'll be watching something and then Plex cuts out for a few minutes and the dashboard says the server is unreachable. I initially thought this was a Plex problem, but I noticed when this happens I can't reach the Unraid server either or any other services hosted on the server. After a minute or so I can access the unraid server again and Plex also starts working again. I'm posting the diagnostics file. This issue came up on September 21 at 9:27PM and September 23 at 10:17PM. sidekick-diagnostics-20200923-2221.zip