80 day parity check

[TheJoshGriffith]

Hey,

 

First time here. Diagnostics attached. Effectively, I've had some issues with unraid being superbly slow, especially on IO operations, for a few weeks now. I can't really pinpoint when it first started, but it's gotten to the point that I can no longer use my server.

 

 

The average estimated finish for the current parity check (just had to power cycle as the whole system was unresponsive) is about 80 days, fluctuating up to about 130 and down to about 50.

 

The drives I've used are generally new, but there is a mix of older ones.

 

Let me know if there is other information which may be helpful, or if there's anything obviously wrong with my setup.

 

Hardware specs, I'm sure are in the diagnostics, but approximate to:

• AMD Ryzen 9 3900x
• 32GB DDR4 memory (can't remember speed, but probably 2400MHz)
• X570 chipset
• The hard drives are running mostly straight from SATA ports, but some are wired into a PCI-e expansion. Most drives are ST8000DM004, with a few 4TB of similar models.

 

Any assistance appreciated, thanks in advance.

harris-diagnostics-20230622-1215.zip

[JorgeB]

There's something writing to disk6, this will slow down parity check, especially with SMR disks.

[trurl]

11 minutes ago, JorgeB said:

something writing to disk6

Possibly Docker or VM related, since your appdata and domains shares have files on disk6.

 

Best if appdata, domains, system shares are on cache or other pool and not on the array, since these files are always open. Having these on the array will impact performance of Dockers/VMs, keep array disks spunup, and can impact performance of array when multiple processes are trying to access them.

[TheJoshGriffith]

Thanks both, so I had a disk installed for cache but it didn't previously work - I've just set that up and it seems fine now.

 

With the cache disk simply enabled, do I need to do something to tell the system to use the cache disk for appdata, domains, and system shares? Or will it automatically cache any data written to the array and copy it later? Having already set this up, I see that there is now an appdata directory on the cache, but when copying files whilst the copy speed is superbly fast, the files don't appear on the cache disk browser, so I'm hesitant.

 

This does seem to have largely resolved the slowness issue, at least. I paused the parity check, will resume it shortly, but need to setup some more applications first.

[JorgeB]

16 minutes ago, TheJoshGriffith said:

With the cache disk simply enabled, do I need to do something to tell the system to use the cache disk for appdata, domains, and system shares?

You need to move the current data from disk6 to cache, trey won't be moved automatically, also VM/docker services must be disabled first.

 

 

[TheJoshGriffith]

7 hours ago, JorgeB said:

You need to move the current data from disk6 to cache, trey won't be moved automatically, also VM/docker services must be disabled first.

 

 

I'm gonna be really awkward here and ask... What would be the recommended way to do this? My best guess is simply to `mv` them in a terminal but I've a feeling that'd break something. Could I instead copy them from the array then delete off of the array? Do I need to stop the array to do so?

 

Sorry for the awkwardness, I just don't want to risk bricking anything. I've been extremely hesitant to do much tinkering so far for exactly that reason, and it's left me in this state where I didn't know how to fix the problems I couldn't quite identify!

[trurl]

If those shares are set cache:prefer, mover will move them to cache. Nothing can move open files, that is why you have to disable Docker and VM Manager first.