cdcoulson

Understood on the first sentence. The problem is: the docker directory on cache is empty. Docker directory on disk1 (array) is 31G. If Docker/VM Manager are disabled, and the system share is set to cache primary/array secondary and Array -> Cache, why won't the Mover move the contents of the docker directory from disk 1 (array) to cache? They're still in-use (how, if Docker is disabled?) Unless Mover won't move the docker directory because the docker directory on cache already exists (despite being empty)?

Okay, more targeted question after my previous edits/discoveries. I sorted out my appdata situation -- not sure how duplicate directories were created off-cache, but it's sorted, now. For system, though, the issue still remains: I have data on cache (1GB) and disk 1 (33GB). Again, settings are Cache primary & Array secondary with Array -> Cache. I did not change any of these settings recently. How can I move the 33GB system folder on disk 1 to cache? Should I? (EDIT: Docker disabled, VM Manager disabled, settings above for system: [Cache primary, Array secondary, Array -> Cache], and when invoking Mover, nothing happens )

Thanks. For appdata, I have data on cache (19GB), disk 1 (1GB) and disk 2 (1GB) despite it being set to Cache for Primary and nothing to Secondary. I enabled Array as Secondary, then "Array -> Cache" to allow me to use the Mover with the goal of shifting all appdata files from Disks 1/2 to Cache. That's running right now. (EDIT: I followed instructions and disabled Docker/VM Manager prior to making any changes.) For system, I have data on cache (1GB) and disk 1 (33GB). Again, settings are Cache primary & Array secondary with Array -> Cache. I did not change any of these settings. Will Mover also handle these files? If not, how can I tell from CLI which files reside on cache/array? I'm pretty familiar with the command line -- don't really need a file manager, unless that can somehow show me which files/directories are on cache versus array. (EDIT: Apologies, realized I could simply navigate to /mnt/cache & /mnt/diskX to compare and remove files as-needed. Thanks!) Thanks!

Ah, understood. Yep, during impact, I'm able to log in via SSH and run commands without issue. When doing so, I typically do see load average spike (> 40.0) fairly high. I forgot about this part: using a CLI client on my phone, I logged in via SSH and started looking at IO stats for the disks and noticed that sdj (cache) had a relatively high counter for "kB_dscd" -- is this possibly a separate/another indicator of an issue with the cache disk? https://imgur.com/a/4Cg4B1Y (Apologies for the formatting -- tough to correlate values to headers, but it's definitely discarded KB to sdj -- cache) I see. I just checked, and appdata is set to "Cache" for primary storage with no secondary storage selected; system is set to "Cache" for primary storage, "Array" for secondary storage (High Water/Automatically split only the top level directory as required/All/None) with Mover action set to "Array -> Cache". Is it preferred to set system share to only use Cache (i.e. unset secondary storage option), then run Mover?

Not familiar enough to understand the significance of the first part. Regarding the second part, I checked the zip archive contents again, and that timestamp/error definitely exists. There are also multiple occurrences, not just at that timestamp, found inside docker.txt.

Hey all. Long-time listener, first-time caller. I have a home server (E5-2667 v2 / X9DRL-iF) running Unraid 6.12.4. I have a single SSD cache (Samsung 850 Evo 500GB) and a variety of disks (8 total, including parity). Sporadically, though seemingly correlated to high-IO situations (copying large files, running Mover, etc) the system will be unavailable via GUI. Docker applications will function for some time but eventually begin throwing errors (query timeouts, etc). I followed instructions to log in via SSH and run the "diagnostics" command, the output of which I'm attaching here. One of the error messages in the logs that sticks out to me is: time="2024-01-17T23:44:01.928430881-07:00" level=warning msg="error copying stderr" runtime=io.containerd.runc.v2 I saw an older thread mentioning that this could be a cache issue. Any thoughts? Thanks in advance for your time. tower-diagnostics-20240117-2345.zip

Hi all, Long-time user, first time poster. I've had a home-use server up (Unraid 6.9.2) and running for quite a while now, and started running out of disk capacity. I purchased a handful of 6TB drives, and I replaced my 2TB parity drive with a 6TB drive without much of an issue. Took about 12 hours to rebuild it with about 10TB of total data. I followed the instructions I found in the user guide to expand/replace disks with larger capacity drives-- stopped the array, unassigned the target 1TB data drive, shut the server down, physically removed the 1TB data drive from the system and replaced it with a 6TB drive, booted the system back up, assigned the new 6TB drive in the old drive's position and then started the array. The disk rebuild started, as expected, but is cruising along at 15-35MB/s and is currently estimated to take almost 3 days to rebuild. The system is also extremely slow to respond, and in some cases, triggers HTTP timeouts. I'm hoping someone can shed some light on what might be happening, here. I've attached a diag output. Thanks in advance! tower-diagnostics-20230406-2026.zip