spall

Members
  • Posts

    135
  • Joined

  • Last visited

About spall

  • Birthday 09/15/1970

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

spall's Achievements

Apprentice

Apprentice (3/14)

9

Reputation

  1. All right. Thanks everyone. I'm gonna consider the mystery solved. So much for that idea. Unless I want to replace all sticks for a higher density. Much appreciated.
  2. That was the assumption I was under. Hmm. Ok. Maybe someone will chime in with the definitive on that. Otherwise, I have no idea what went south. Thanks again for commenting!
  3. @JorgeB Unfortunately I am on the latest BIOS. Thanks again for the suggestions. I'll just blissfully ignore this in the log for now.
  4. @itimpi I mapped to a folder inside: /tmp/intermediate. Your second point is what was confusing me, because the dashboard was reporting in the 60% range, and that was jiving with the amount of RAM use at the start of the download + the size of the file in /tmp. The server should have, at that point, had >40GB of RAM left to muck with. Am I correct in my understanding that /tmp will use whatever RAM is available? /tmp isn't the one that's only 1/2 RAM? If the latter, it would have filled it up and maybe that caused the muck up.
  5. @itimpi Sorry! I meant /tmp on the Unraid side. I was trying to use RAM as the intermediate directory.
  6. So I had this idea (maybe bad) to try and use /tmp for an intermediate directory in nzbget. I thought it could be faster than just hitting a cache pool with all the unpacking and moving etc. So I set it up and everything was cruising fine until it hit roughly 60% RAM usage, and my Unraid GUI started freaking out. It was constantly reloading itself, all the drives in the array would be missing, and then suddenly around a third would be present. The flash drive and everything in unassigned devices disappeared and had the loading icon constantly. Then the log went crazy with this on a loop: Feb 25 20:20:16 spock rc.diskinfo[27686]: PHP Warning: syntax error, unexpected end of file, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /var/local/emhttp/disks.ini on line 258 Feb 25 20:20:16 spock rc.diskinfo[27686]: in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 294 Feb 25 20:20:16 spock rc.diskinfo[27686]: PHP Exception: array_map(): Argument #2 ($array) must be of type array, bool given in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 295 I was able to shut the array down and reboot. I removed the /tmp from the container and everything is normal. But.. what happened here? And while I'm asking the question: Why was this a bad idea? Thanks!
  7. @JorgeB Thanks for the response. That's good to know, but what are the ramifications of it? Is it telling me if there's an error in RAM it won't be able to tell me which stick had the issue? If so, is there a way to change that, or it is what it is?
  8. Hi all, I just did a server reboot and got this in the log: mcelog: Kernel in lockdown. Cannot enable DIMM error location reporting Can someone explain this and if it is a concern? I can't say that it hasn't always been there as I just noticed it now after installing new DIMMs. Thanks for your time!
  9. Ya know I never realized you could do that. Added to the exclusion list. Thanks!
  10. Hallo, First, thanks for the continued work on this plugin! I had an error throw today: [12.02.2024 07:01:28][ℹ️][FoundryVTT] No stopping needed for FoundryVTT: Not started! [12.02.2024 07:01:28][❌][FoundryVTT] '/tmp/fvtt' does NOT exist! Please check your mappings! Skipping it for now. [12.02.2024 07:01:30][ℹ️][FoundryVTT] Should NOT backup external volumes, sanitizing them... [12.02.2024 07:01:30][ℹ️][FoundryVTT] Calculated volumes to back up: /mnt/user/appdata/FoundryVTT [12.02.2024 07:01:30][ℹ️][FoundryVTT] Backing up FoundryVTT... [12.02.2024 07:01:54][ℹ️][FoundryVTT] Backup created without issues [12.02.2024 07:01:54][ℹ️][FoundryVTT] Verifying backup... [12.02.2024 07:02:18][ℹ️][FoundryVTT] Starting FoundryVTT is being ignored, because it was not started before (or should not be started). The rest of the data backed up fine. Just wanted to double check that this isn't cause for greater concern. I'm ok with the bit about '/tmp/fvtt' Thanks for reading!
  11. Finished without error. You think just treat it as an anomaly?
  12. @JorgeB Thanks, as usual, for the feedback. Doing that thing now. Will report back when it finishes sometime in 2027.
  13. Sure thing. Attached. spock-diagnostics-20231220-0532.zip
  14. I created a new cache pool and am migrating data from the old pool->array and then plan on migrating to the new pool. Moments after I started the Mover I got this: Dec 19 20:40:42 spock kernel: critical medium error, dev sdab, sector 3907733680 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 2 Dec 19 20:40:42 spock kernel: md: disk8 read error, sector=3907733616 Dec 19 20:40:42 spock kernel: md: disk8 read error, sector=3907733624 /dev/sdab is a drive inside the array. SMART shows nothing out of the ordinary, and those are the only log entries (so far) for that drive. I do have a few larger capacity drives on hand that I've been meaning to swap in, so I don't mind replacing that one. Should I go ahead and do that? I've just never seen (to my recollection) a critical "medium" error before. No idea what that could mean. Thanks for reading!