I have heard of people using a plugin called Cache_dirs to try and remedy this.  Wondering what others are doing?  Ive been thinking about just having plex update once per day.  Thoughts?

I use cache_dirs to prevent this.. I believe it has the added side effect of making library updates much faster as well (at least it seems that way from my experience.)

If your Plex install is on the array drive(s), that is what keeps them spun up. Moving it to a Cache drive will fix it.

If your Plex install is on the array drive(s), that is what keeps them spun up. Moving it to a Cache drive will fix it.

 

Just jumping in here because this is relevant to me. I haven't completed my unRAID build yet, but I don't plan on having a cache drive. What you're saying is that if I install Plex directly to the array, the disks will stay spinning?

First question: Why?

Second question: is there not a setting that will allow the array to spin down? (i.e., tell Plex to only update manually, rather than automatically on an interval)

Third question: What about installing on the unRAID flash drive? Is there a way to install Plex to that location instead? Obviously, the flash drive will always be on anyhow so that would not be a burden. I'll just buy a bigger one ;p

Noob,

 

If you plan on running Docker with Containers like Plex, I would NOT install it on the array.  Use a cache drive

Noob,

 

If you plan on running Docker with Containers like Plex, I would NOT install it on the array.  Use a cache drive

 

Thanks for the reply. That doesn't help me understand the issue, though. I'd like to be informed and then I'll figure out what trade-off to make with the array/spin-time, etc.

 

My second question seems like the simplest solution. If I install a Plex docker image on the array AND I set it to only update when I manually click "update", will my array suffer from the spin-up problem mentioned above?

 

If that doesn't work, what about installing the docker on the flash drive? Will unRAID allow this?

First of all, its not polite to hijack my thread.  I understand you are new to unraid, we were all new once.  But going off topic in a thread would make it harder for people with your same issue to find help without having to re-ask

 

A simple search returns this...

http://lime-technology.com/forum/index.php?topic=5754.0

 

Basically, calculating parity takes a long time, and is very slow.  Like you, I started without a cache and quickly regretted it as soon as I spun up a VM.  Do yourself a favor and use an SSD.

 

To answer the rest of your question, my array spins up during an update.  So if you set it to manual, this will not happen.  My rig runs at 100w idle which is alot compared to some people.  So having my drives spun down is important to me.  If you do not use a cache, it would be virtually impossible for your array to spin down because itll always be used.  The important part to note is that the cache is not technically part of the array.

Thanks, again, for your reply.

 

I read that thread before I started my build. My question is not about the advantages or disadvantages of cache drives (I grant you, if I had asked that question, that would be a thread hijack). I don't think my questions are a thread hijack because you asked in your first post "Ive been thinking about just having plex update once per day. Thoughts?" This is exactly what I'm asking about in my second question (albeit using a different update frequency), so this was a fair place to ask that. The third question about installing Plex to the OS drive is related, too, since installing to a cache drive was suggested by interwebtech, and installing Plex to the OS drive may allow me to remedy the problem without having to add cache.

 

"To answer the rest of your question, my array spins up during an update.  So if you set it to manual, this will not happen." This is exactly what I needed. So installing to the OS drive is unnecessary because it isn't the Plex app running in the background that causes the array to spin-up, it sounds like its just the library update. Thanks!

That is not 100% true.  Keep in mind that plex generates many log files.  These files will keep your disks up as well.  As for installing apps on your flash....im sure there is a technical reason for not doing this, even if I cant back that up with real data.  I will say that if it were an acceptable solution, you'd read about more people doing it.

 

I am not sure why you are so against a cache drive.  If it is simply HDD slots, then use some duct tape. Or look into a PCIe SSD.  But if you plan to run apps and VMs, you will need an SSD.  Remember, Unraid does not STRIPE like traditional raid, so if VMs are on your radar without a cache drive, I would recommend you look at something like FreeNas, which does stripe and will provide you more IOPs, otherwise, performance will be rather terrible, from my experience.

 

EDIT: I had you confused with someone else who was insistent on deploying VMs.  Sorry about that.  But, the information I posted is still relevant.  However, for your use case, you COULD install docker and plex directly to , say, Disk3.  That would let just one disk spin.  I have never tried it, but it should work.  Several ways to accomplish this, but the easiest would be to create an appdata share and include only 1 disk.

The good news is that I've really been pressing unRAID hard and I haven't been able to break it. The bad news is that the UI doesn't allow you to install docker containers on to flash. If it does, I sure haven't been able to get it to work. It accepts /flash as a directory, but the image never writes (I assume it's protected somehow).

 

I've taken your advice and installed the Docker image as well as the Plex container on one disk. I'll see how often/how long it spins up for with Plex updates disabled. If it's excessive, I'll be buying a PCIe mSATA adapter and moving them over to an SSD.

 

I don't plan to use a cache drive because I won't have any apps running that are memory or disk heavy, nor will I be running any VMs on this device. It will just be a basic file server, so cache isn't providing me with any benefit. Sure, I don't want to waste a drive bay or a SATA port, but more importantly I don't want to waste the money. There will be speed improvement with a cache drive, but it is speed I don't have a use for. Also, using a cache drive introduces a small amount of risk. If the drive fails before its data is written, you lose that data. Most caches move data to the array once per day by default, so that's potentially an entire day's worth of content lost. Not the end of the world, but I don't need to take unnecessary risks with my backups.

 

I'm super excited to have a solution to this question, and I thank you so very much for your helpful replies. Happy NASing!

The good news is that I've really been pressing unRAID hard and I haven't been able to break it. The bad news is that the UI doesn't allow you to install docker containers on to flash. If it does, I sure haven't been able to get it to work. It accepts /flash as a directory, but the image never writes (I assume it's protected somehow).

This will be because there is no directory called /flash.  At the Linux level it is known as /boot.  It is only at the network share level that it is known as /flash.

 

However installing docker containers to flash is not recommended for a number of reasons

• Performance will tend to be bad as USB is much slower than SATA (many motherboards have trouble booting off the flash if is not on a (slow) USB2 port).
  
• The flash drive has a limited number of read/write cycles so you may be significantly reducing its lifetime.
  
• Most people get away with a small flash drive (e.g. 2-8 GB).  The docker image is normally larger than this (10-20 GB).  Also since the flash drive has to be formatted as FAT32 you need special utilities to format any flash drive larger than 32GB to FAT32 as Windows does not know how to do it.
  
• Many dockers require significant work space for temporary files.  In which case putting the docker image file in the same location makes sense.
  

Having said that it should work if you try it.  If you go down that route providing feedback on your success would be useful.

Is there any easy way to move all Docker apps to a cache drive once they have already been added to the array? All of my Docker apps are going to an "apps" share and I have since told that share to use cache only. I'm just wanting to move all previous data to the cache drive as well.

I would stop docker, move the docker image and AppData folders, change the path in the container and everything should work fine

The good news is that I've really been pressing unRAID hard and I haven't been able to break it. The bad news is that the UI doesn't allow you to install docker containers on to flash. If it does, I sure haven't been able to get it to work. It accepts /flash as a directory, but the image never writes (I assume it's protected somehow).

 

I've taken your advice and installed the Docker image as well as the Plex container on one disk. I'll see how often/how long it spins up for with Plex updates disabled. If it's excessive, I'll be buying a PCIe mSATA adapter and moving them over to an SSD.

 

I don't plan to use a cache drive because I won't have any apps running that are memory or disk heavy, nor will I be running any VMs on this device. It will just be a basic file server, so cache isn't providing me with any benefit. Sure, I don't want to waste a drive bay or a SATA port, but more importantly I don't want to waste the money. There will be speed improvement with a cache drive, but it is speed I don't have a use for. Also, using a cache drive introduces a small amount of risk. If the drive fails before its data is written, you lose that data. Most caches move data to the array once per day by default, so that's potentially an entire day's worth of content lost. Not the end of the world, but I don't need to take unnecessary risks with my backups.

 

I'm super excited to have a solution to this question, and I thank you so very much for your helpful replies. Happy NASing!

 

You could always install a cache drive and disable caching on the shares that are vital. In general, your current setup should work though. But I think you'll find that disk spun up a lot. Shouldn't hurt anything though.

The good news is that I've really been pressing unRAID hard and I haven't been able to break it. The bad news is that the UI doesn't allow you to install docker containers on to flash. If it does, I sure haven't been able to get it to work. It accepts /flash as a directory, but the image never writes (I assume it's protected somehow).

 

I've taken your advice and installed the Docker image as well as the Plex container on one disk. I'll see how often/how long it spins up for with Plex updates disabled. If it's excessive, I'll be buying a PCIe mSATA adapter and moving them over to an SSD.

 

I don't plan to use a cache drive because I won't have any apps running that are memory or disk heavy, nor will I be running any VMs on this device. It will just be a basic file server, so cache isn't providing me with any benefit. Sure, I don't want to waste a drive bay or a SATA port, but more importantly I don't want to waste the money. There will be speed improvement with a cache drive, but it is speed I don't have a use for. Also, using a cache drive introduces a small amount of risk. If the drive fails before its data is written, you lose that data. Most caches move data to the array once per day by default, so that's potentially an entire day's worth of content lost. Not the end of the world, but I don't need to take unnecessary risks with my backups.

 

I'm super excited to have a solution to this question, and I thank you so very much for your helpful replies. Happy NASing!

 

You could always install a cache drive and disable caching on the shares that are vital. In general, your current setup should work though. But I think you'll find that disk spun up a lot. Shouldn't hurt anything though.

I have a cache drive but I only use it for apps and none of my other user shares are cached so nothing ever gets moved.

 

There is one other thing to consider about putting apps such as plex on an array drive. While it's true that only that one disk will spin when reading, that disk and parity will spin when writing since parity is updated realtime. This will make writing much slower. Also, many apps write more than you might think. Plex for example will be writing even when you aren't updating the library.

Is there any easy way to move all Docker apps to a cache drive once they have already been added to the array? All of my Docker apps are going to an "apps" share and I have since told that share to use cache only. I'm just wanting to move all previous data to the cache drive as well.

 

I would recomend using Midnight Commander or Rsync at the command line level to move the folders.

 

Note: If you go rsync or even just move don't cross the streams and try to move user shares to disk addresses. Alwasy go Disk to Disk, or User Share to User Share.

Note: If you go rsync or even just move don't cross the streams and try to move user shares to disk addresses. Alwasy go Disk to Disk, or User Share to User Share.

 

Good advice. I tried this with a docker I didn't really care about and it refreshed all of its config data. It's because I went from user share to cache drive using rsync. I will use rsync from disk -> cache next time and see how that works.

 

Thanks!

I have already noticed that my parity and disk where Plex is installed seems to be spun up for no reason. There isn't any access on the network shares yet because I haven't started using unRAID in a production setting yet, so my test rig should idle down after some inactivity. When I found it this morning, after hours of inactivity, parity and one disk were spun up. The only thing I can point to is Plex because it's is the only thing installed right now. I'll watch it again tomorrow morning and, if it is still spun up, I'll try changing things around.

 

Note: This is with Plex updates turned off, such that it will only rescan/update the library when I tell it to. There must be some kind of background process always running to keep the DNLA up.

I use cache_dirs to prevent this.. I believe it has the added side effect of making library updates much faster as well (at least it seems that way from my experience.)

 

Hello, I only see cache_Dirs as a V5.0 plugin, am I overlooking it as a V6? I am looking to use it for the same reason, Plex, and allowing my disks to spin down.

I use cache_dirs to prevent this.. I believe it has the added side effect of making library updates much faster as well (at least it seems that way from my experience.)

 

Hello, I only see cache_Dirs as a V5.0 plugin, am I overlooking it as a V6? I am looking to use it for the same reason, Plex, and allowing my disks to spin down.

It is one of the Dynamix - V6 Plugins in the sticky.

That is not 100% true.  Keep in mind that plex generates many log files.  These files will keep your disks up as well. 

 

For your use case, you COULD install docker and plex directly to , say, Disk3.  That would let just one disk spin.  I have never tried it, but it should work.  Several ways to accomplish this, but the easiest would be to create an appdata share and include only 1 disk.

 

Update for everyone: I've installed Plex to a single Disk and it is working well. The struggle is that Plex still spins up the disk sometimes when there is no network activity, even with cache_dirs turned on. It isn't a lot, but it is frequent enough that it makes me wonder why I bother spinning the disks down at all. Plus, since all of my disks are part of an array, a parity drive comes online at the same time. That means that whenever Plex decides to do something (I haven't the slightest clue what it is doing because I've got everything turned off other than DNLA) both disks spin up (data+parity), make one or two writes each, and then sit for the next 14min 45sec.

 

If this behavior continues I'm going to try to reinstall Plex to the flash drive tomorrow using /boot (as suggested above). I'll report back with results after enough time has passed for me to feel confident about my findings.

If this behavior continues I'm going to try to reinstall Plex to the flash drive tomorrow using /boot (as suggested above). I'll report back with results after enough time has passed for me to feel confident about my findings.

My relatively modest plex library uses 3.5GB. Do you have enough room on your flash?

Aye. This is just a test rig, so I only have one movie it'll be indexing. When I do my permanent install it'll be on a 32gb flash so that I can host docker and plex on it (assuming I can get this to work).

 

Bad news is, I just tried and both /boot and /root don't do anything. It accepts these when I click "apply", but nothing shows up on the flash drive. I'll make a new thread to troubleshoot installing things to the flash.

 

Thanks guys! Good luck keeping those drives idle

Id have a problem installing on the flash too if I was simply guessing the directory path. It's been stated already that plex writes a lot of logs. Since you are installing directly to a disk, parity will be written, which keeps both drives up. Use telnet to get a realistic view of the directory structure so you don't have to guess

haven't read the whole thread (sorry), but maybe i can a little advice. i'm an avid longtime plex-user (for years on Apple/Macs), but shortly switch the server to unRAID.

 

PLEX-Server writes alot of files to disk (since a few years i switched to a SSD for it) – first, while indexing the contents, then downloading metadata, covers, writing it's own database and support files (for plug-in contents). and then there are settings which define, how/when plex does house-keeping and if/which log-files are written.

 

now some numbers. i've a quite big library which cumulates to 6,9 GB and a file structure of 335320 entries (files/directories). remind you, this is plex own place to keep all informations about your actual content. i would guess, that even on a fast usb-stick, this massive amount of files/directories could lead to slow response times, when you visit/use plex (administration) webpage. think of the wear/stress put on the stick and then what about a backup? backing up hundred thousands of files from an usb-stick (to wherever) takes quite awhile; you won't like to loose a built-up and maintained plex library.

 

using an ssd as cache only for the appdata (plex library) and/or the docker itself is the best solution in my opinion. it's fast, it's deals easily with these amount of files/directories, wear/tear shouldn't be a problem for several years and it's as fast responding, as your system hardware allows. bonus: the drives don't spin up for many many hours (as long as it's setup that way and your board/controllers allow it). the cache SSD will get active from time to time, because of plexs own active docker, but even then it gets put idle in between (no other accesses from shares, etc. presupposed).

 

on more thought of having a fast (ssd based) cache drive is: transcoding. probably you will run into the situation, that plex needs to transcode content for a device, which can't use the direct playback option (raw cpu power, codecs, audio, etc.). there are only two viable options for plex to have a temporary space doing it's magic: ram or storage. ram is best, but probably at the most cost. storage should be fast because of being permanently written and read by the transcoding process. it's not a good idea to use a share for it (makes the parity drive involved with additional writes) and is the slowest option. so there is only a disk share or cache drive as option left. make it a SSD cache and you have the best of all worlds. this would not only profit plex but the whole unRAID experience.

 

maybe i could give you some hints/insights in the inner working/usage of plex and storage and helping to make it a nice experience.