poofysnoops

Hi guys! I'm having some trouble getting my new Quadro P2000 to show up properly. It shows up in Tools > System Devices as [10de:1c30] 0a:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2000] (rev a1) but nowhere else. When I attempt to open Settings > Nvidia Driver, the page never loads. If I try to run the command nvidia-smi as instructed at the top of this post, nothing happens at all. The terminal just freezes. I've uninstalled and reinstalled the Nvidia Driver plugin. Here is my plugins page: And attached is my diagnostics file. Please advise, thanks! Edit: One other thing that is probably important - I noticed once I installed the card into the HP Proliant DL380 G8 server, it stopped using the onboard VGA output for the local CLI. Maybe the machine itself is taking control of the GPU, but I'm not sure how to prevent that. counterpart-diagnostics-20211207-1951.zip

I added the -L flag, and it seems to have completed successfully and I see no lost data.

Sure - I got the following: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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. Is there a specific way I should try to mount the disk while in maintenance mode? Or should I run with -L like it says?

Running Unraid 6.8.3 This morning upon logging in to check my array, I noticed that some of my dockers weren't working properly and tried to restart them. I got an "array error" message and they wouldn't start again. So, I stopped the array and attempted to start it again. Then I noticed that a (nearly full) 12tb disk was listed as "Unmountable: no file system". I then tried xfs_repair for this disk and got the following back: 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_ifree 1396, counted 1395 sb_fdblocks 381815839, counted 384216640 - 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 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 2676247418, would move to lost+found Phase 7 - verify link counts... would have reset inode 132 nlinks from 531 to 530 No modify flag set, skipping filesystem flush and exiting. I'll attach my diagnostics.zip. Not sure where to go from here to avoid further issues, I'm still relatively new to this. counterpart-diagnostics-20200527-1010.zip