boomam

Hi, That's not what i'm asking at all, reading the second paragraph would have showed this. I'm asking if we have to turn on each supported service as part of the docker container setup, using the variables that are pre-set in the template. It is of course obvious that for DNS requests to be intercepted that it would need to be in the chain of DNS's in use by a given subnet. Thanks.

Hey, Do we have to do anything specific to this container, other than set the BIND IPs, for it to cache things? For example, do we need to set each service type to 'false' so that it does cache them? I ask as i've had Lancache in operation for a while now, lots of downloads from at least 4-5x of the services it lists as supporting, with 100s of GB of data downloaded in total...and the current cache size is less than 5Gb. Is that normal? Thanks!

Ok, those would equate to the books and NC shares. I'm running the mover right now to test - i'm also considering just moving them both to cache-only and having some backups scripts run each evening. The SSD cache is big enough that it can take the hit of additional storage.

Yes, i understand the theoretical intent of the setting, but from what i have observed thus far where the mover is moving almost nothing and the drives spinning up even though Cache-yes is in play, kinda contradicts what i'm seeing I'm half temped to just give up and just not have the HDDs spin down at all, rely on their own low-power mode for power savings.

RE: Calibre Both its library and import docker links go to a 'books' share, that is set to cache-yes Re: NextCloud The container path for /data goes to a share called 'NextCloud', that is set to cache-yes Thank you for your input thus far btw. Appreciate the effort.

I use SSH to move things around, im more comfortable with CLI. I'll nuke the share in the GUI, then CLI, then re-create. -- EDIT -- Share deleted and re-created - /boot/config/shares now matches up correctly, inc. in names. Do you have any theories as to why Calibre/the books share is causing drive spin ups? Also, i'm concerned about NextCloud a little, after the mover has run...i'm wondering if it's worth resetting it up and trying to split the /data folder out.

ok, How am i cleaning up missing shares? Is there a guide somewhere? The directories do not exist on the file system, so where exactly are they located otherwise in the context of Unraid? -- EDIT -- Looking in /boot/config/shares, i can see 2x issues 1. it lists a bitwarden share that doesnt exist. 2. It lists a log share with a 'L', whereas the actual share uses 'l'. Is this what i'm tidying up in some way? Am i just deleting one and editing the other? -- EDIT 2 -- The bitwarden one removes without issue. The Logs one will not rename as it thinks its the same name - odd for Linux.

Attached. I rebuilt NextCloud (as i had nothing in it anyway) from the NCP image, to one with 2x containers (MariaDB + LinuxServer/NextCloud) and thus far its NOT spinning the drive up for just being started. Just Calibre to work out now, followed by Plex. unraid1.zip

The thing that's throwing me off right now is the drive spin ups with nextcloud and Calibre. When I had my docker.img file on an unassigned drive, I didn't have spin up issues. Also, nextcloud/calobre isn't in constant usage either. So I'm a little stumped what's causing the spin ups.

Good to know. I can duplicate with Plex too, same scenario i guess....only during clean up earlier i accidentally ran 'rm -r' on my media share. 😞

Thanks, read it a few times, but the FAQ is typical linux style though - not great, but the accepted norm Once i get some time in a few weeks i want to work out how to contribute to get it clearer/dumbed down. I'm going through containers one by one, and i'm able to duplicate drive spin up's, in addition to the logs one, with both Calibre & NextCloud, even though both their shares are cache-yes. A few away from testing my 30-odd containers, then i can loop back and diagnose.

Thats unusual behaviour - perhaps a reason why im seeing spin ups of the disks. Is there a reliable way to diagnose/tidy up? For example, i just by chance saw that domains still existed on disk1 for some reason, used CLI to move it to cache.

Disabling the syslog server seems to have kept the drives spun down, even though the associated share was set to cache=yes...hmm... - Edit - Odd, spoke too soon, restarted the docker service and all of a sudden i can no longer spin down the disks again.

Good shout on that button, easy way to check. I now have system, appdata & domains set to be cache-only. I'm reasonably happy with the layout mentioned above, my only issue now is that i cant get my HDDs to stay spun down. The aforementioned tools i got from CA are next to useless for diagnosing why the drives immediately spin up after spinning down. Shutting down all containers & VMs, still shows the drives coming straight back online...hmm... Any ideas?

Reading around some more, if i want the VMs/Containers to be high speed, they should be cache-only, and have some backup routines running on them to move to the array - correct? Equally, im going down this route for each setting - Cache Only For items i want read/write caching and have other backup routines running Appdata Domains Cache Prefer For items that i want to read from the cache, but the writes be flushed to the array by the mover. System Cache Yes For items that i want to write to the cache, with writes be flushed to the array by the mover, but read caches until its been moved Downloads General Storage Logs Cache Np For items that i want to read & write from the array only. Backups HDD spin up concerns aside, does the 'plan' above seem like somewhat good practice?

Ok. So what is the actual real world advantage of cache-prefer then? Doc's say it copies data to the cache from the array (unless there's no room), and i assume R/W's from the cache - after a point, what is the mover even doing if its not writing back to the array at some point? Comparatively, cache-yes seems to be cache writes, then move to array, with reads coming from the HDDs. So theres truly no way to not have the HDD's spin up at every little thing happening? That surely cannot be right?

ok - so for cache-prefer shares - does the data that exists in cache ever get written back to the array?

Hi, Today i merged my unassigned SSD/data back into the main pool, and now have 2x 1Tb drives in a SSD cache pool for a 3x 4Tb HDD array. What i'm trying to work out is the best cache settings to use, whilst also minimizing HDD drive-spin up, and SSD write usage too (obviously depends on the apps at play). In an ideal world, other than when i'm pulling data (read), everything will go to the SSD, and the HDD's will only spin up when the mover kicks in. At the moment, i have ALL my shares, other than system & appdata, set to 'yes' for caching, with system & appdata set to 'prefer'. With 25-30 containers active, including ones collecting logs (influx/telegraf for example), and the syslog looping back to write to a log share, i'm seeing a few hundred KB/s of writes at any given moment, with the occasional spike up to a few MB/s. However, i'm also seeing the HDDs spin up often too. If i manually spin-down the HDDs, they stay off for a little while, but do end up spinning up again. I am guessing that perhaps some data is being pulled by one of the containers that's not in the cache yet - perhaps it'll get better the longer its in this configuration? As some questions - 1. What is the best practice for cache usage? 2. Is there a way to have the cache somewhat mirror the data array (to a point) and the mover literally just be a copy to ensure parity/protection from the HDDs? 3. Is there a better way to see what files are writing at any given moment to either the array or the cache? As some of the plugins, such as 'Open Files' are next to useless for diagnosing due to the paths being listed being the abstracted paths, instead of the actual paths - as in it will list /user/XYZ instead of whether its cache or disk being written or read too. Thanks!

Thanks - that was it. I dont recall ever setting that setting in the past, but hey-ho, its working now, so nice one! 🙂

Previous location was an unassigned disk. Current access mode - i do not know what you mean by this. Please elaborate.

I seem to be getting an error when i change the variable in the container for the container path /transcode to be /tmp - Error response from daemon: path /tmp is mounted on / but it is not a shared or slave mount. Anyone any ideas on this one?