I am not sure when this happened, but I do not like the view under shares:

 

When I hover it says "This share is invalid. It references storage that does not exist."

The only thing I've seen about the issue is that it was a bug.  But I'm on 6.12.14, so that would surprise me.  When I pick the top folder (appdata), I see this:

 

When I look at my share drives, they are all there, so they seem to be fine.  Is this still a bug or is something else going on?

 

 

That suggests you no longer have a pool called cache, if that is correct, just click on each share, reconfigure or make a dummy change, and hit apply.

 

 

On 4/17/2025 at 7:00 AM, JorgeB said:

That suggests you no longer have a pool called cache, if that is correct, just click on each share, reconfigure or make a dummy change, and hit apply.

 

 

That does work.  Is that indicative of a poor setup?  I have the following Array setup:



I have 8 drive bays - so all are taken up.  I have an internal boot device.  This is an older HP Gen7 server. I do have a couple of 1TB SSD's (SATA) that I could add, but would need to add a sata expansion card or something to add anything.  Unless it would be wise to take one of the existing disks and create a cache somehow?  I have 5.42TB used out of 11.6TB, so I think I have enough free space even if I remove a drive.

 

Not necessarily a bad setup, but typically, you have HDDs for the array and use SSDs with one or more pools, SSD write speed on the array will be limited by parity disks, and also they cannot be trimmed, but it most depends on how you are using the array.

16 hours ago, JorgeB said:

Not necessarily a bad setup, but typically, you have HDDs for the array and use SSDs with one or more pools, SSD write speed on the array will be limited by parity disks, and also they cannot be trimmed, but it most depends on how you are using the array.

ok.  Well, I would say I'm using it mostly for Dockers and storage space.  Main docker's are Plex/sonarr/radarr/sabnzbd/ombi, InfluxDB, CodeProject_AI_Server for Blue Iris use.  The overall load tends to ride between 1-4% unless streaming.

I would definitely like to 'do better', though.  I've definitely replaced some of the older spinning drives with SSD, but that is mainly because I retired my ESXi server and SSD seemed to work much better with the VMs.  In that setup I have:

Parity - 4TB Barracuda 540 RPM
Disk 1 - 1.8TB SAS 10K RPM
Disk 2 - 2TB SSD
Disk 3 - 1TB SSD
Disk 4 - 2 TB SSD

Disk 5 - 1 TB SSD
Disk 6 - 2TB SSD
Disk 7 - 1.8TB SAS 10K RPM

You could preobably tell that from the part numbers, but just being clear on what I have.  What would be the suggestion to make this a better setup?  I'm not really sure how pool devices work, so that confuses me a bit on what you mentioned above.

Another reason to have pools is so Docker/VM performance won't be affected by parity, and so array disks can spin down since these files are always open.

17 hours ago, JorgeB said:

SSD write speed on the array will be limited by parity disks, and also they cannot be trimmed

Your 10K RPM HDDs also cannot be written faster than parity.

35 minutes ago, Convington said:

storage space

I can imagine ways to use the SSDs (and maybe even the 10K HDDs) in pools for your dockers and VMs, but how are you using these disks for storage space?

16 minutes ago, trurl said:

Another reason to have pools is so Docker/VM performance won't be affected by parity, and so array disks can spin down since these files are always open.

Your 10K RPM HDDs also cannot be written faster than parity.

I can imagine ways to use the SSDs (and maybe even the 10K HDDs) in pools for your dockers and VMs, but how are you using these disks for storage space?

I have a number of shares on them.  My Plex has a few shares such as TV, Movies.  Then Sabnzbd has Downloads.  I have a BI folder for Blue Iris videos.  Then I have a couple of other folders for work-related stuff.

Attach Diagnostics to your NEXT post in this thread. 

Here are the diagnostics.

tower-diagnostics-20250420-0825.zip

Your domains share is configured to write to a pool named cache, which you don't have.

 

Other than that, looks like most shares are just writing to all drives, regardless of the performance differences of the drives, or the performance needs of the shares.

 

I guess you might as well leave the 10K HDDs in the array. Their write speed is limited by parity, but their read speed isn't.

 

Maybe have the SSDs in 2 pools based on matching drive size, zfs or btrfs.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares

 

Ideally, these shares would have all files on a fast pool, with none of their files on the array, so Docker/VM performance will not be affected by parity writes, and so array disks can spin down since these files are always open.