Do I have a REAL reason to run an SSD outside the array - Unsure now

[danioj]

I currently run my Apps / VM's / Store Config on a 250GB SSD outside the array via the Unassigned Devices Plugin. I also run a 250GB Cache Pool (2 x 250 GB SSD's).

 

I am not sure why I originally did this. I think it was because I didn't want ALL my cache devices "spun up" 24 x 7 (as the Apps I run would demand they be). For instance now the SSD mounted outside the array is spun up 24 x 7 BUT the Cache Pool is probably spun up 10 times a day roughly.

 

The downside of course is that there is no redundancy with the data on the SSD mounted outside the Array. I do backup the VM's / Config Folders / Docker File etc weekly to the Array BUT I am wondering if it wouldn't just be better to add the disk to the Cache Pool and just deal with all the SSD's being "spun up" 24 x 7 and take it as payment for the redundancy.

 

I don't think I can setup a btrfs pool via the Unassigned Devices Plugin and even if I knew if I could it feels like it would be a waste of a disk.

 

Any thoughts from others? Just go with a larger Cache Pool or is my setup now better?

 

 

[garycase]

I don't know why you would have set that up to start with.    Since all drives involved are SSDs, there's nothing "spun up" to be concerned with.    SSD power consumption when not actually being read/written is VERY low ... not enough to really be concerned about whether or not they're "spun down" to sleep mode.    [There IS a savings for that, but they generally idle well under 100mw, so I'd think it's not all that big a deal if you can cut them down to half of that.]

 

You may have simply wanted the logical distinction of having different functions on different drives ... understandable, but not necessary.

 

Personally, I'd just increase the size of the cache pool and store the Apps/VMs/etc. there to take advantage of the fault tolerance.    The "payment" for this is probably ~ 200mw for 3 SSDs in idle state vs. sleep mode ... if you assume it's even worse at 100mw/drive, that's still only 300mw ... less than 3kwh / year      And it's likely no more than half that 

 

[theone]

I would add the 3rd SSD to the Cache Pool and put everything on the cache.

 

The added power is only 3-4 Watts - 2 SSDs constantly writing (35kWh/year @$0.12 is only $4.2 a year)

[danioj]

I don't know why you would have set that up to start with.

 

.....

 

You may have simply wanted the logical distinction of having different functions on different drives ... understandable, but not necessary.

 

I think that must have been it. Of course I use the words "Spun Up" to put active / sleep mode into words we all understand. But I think even doing that puts me in the wrong mind set.

 

Personally, I'd just increase the size of the cache pool and store the Apps/VMs/etc. there to take advantage of the fault tolerance.    The "payment" for this is probably ~ 200mw for 3 SSDs in idle state vs. sleep mode ... if you assume it's even worse at 100mw/drive, that's still only 300mw ... less than 3kwh / year      And it's likely no more than half that 

 

That's what I was generally thinking but its always nice to have what you're thinking confirmed. Plus you're always good to "chew the fat" with, as you do have a tendency to throw in some supportive quantitive data to support a position 

 

I would add the 3rd SSD to the Cache Pool and put everything on the cache.

 

The added power is only 3-4 Watts - 2 SSDs constantly writing (35kWh/year @$0.12 is only $4.2 a year)

 

LOL - Even my coffee this morning cost me AUD > $4 

 

Thats it. This weekend. Extend Cache Pool. Thanks for the input Boys!

[garycase]

The added power is only 3-4 Watts - 2 SSDs constantly writing (35kWh/year @$0.12 is only $4.2 a year)

 

Not even close => the "cost" is about 1/10th of that amount at most.    An SSD "idles" at far lower power -- and that will be the state probably 99% of the time.    The difference is between the idle power and the sleep mode power ("spun down").

 

But in any case, it's clearly a VERY low "cost" to simply use the cache pool 

[theone]

If you are running a VM on the cache and maybe also torrenting (like i am) then the cache is constantly being written to.

[garycase]

If you are running a VM on the cache and maybe also torrenting (like i am) then the cache is constantly being written to.

 

Actually it's likely that it's still a very small amount of the time => a torrent spends more time filling the memory buffer than it does writing that information to disk.    e.g. if your torrent is coming in at 20Mb/s it's filling your buffer(s) at 2.5MB/s, but those buffers are emptied to the SSD at about 300MB/s => so the SSD is active less than 1% of the time ... possibly a bit more if your incoming connection is faster (and is always that active).

 

[trurl]

I've never understood why people wanted the extra trouble of running apps from a drive that is not managed by unRAID. The cache drive is already part of the core functionality.

[RobJ]

I like the idea of a separate drive or pool, call it 'Apps' for want of something better, with the primary distinction that it starts and stops with the system, unlike the Cache drive or pool which goes up and down with the array.  It makes it easier to manage always-on apps.  It also should be easy to implement, because it just uses a stripped down version of the Cache drive/pool code base, minus the Share stuff and 'Cache: Only' stuff.  An officially supported Apps drive/pool makes things like pfsense easier.  It also makes management more intuitive, both the Cache and Apps drives/pools are optional and work almost the same, but one starts and stops with the array, the other doesn't.

[trurl]

I like the idea of a separate drive or pool, call it 'Apps' for want of something better, with the primary distinction that it starts and stops with the system, unlike the Cache drive or pool which goes up and down with the array.  It makes it easier to manage always-on apps.  It also should be easy to implement, because it just uses a stripped down version of the Cache drive/pool code base, minus the Share stuff and 'Cache: Only' stuff.  An officially supported Apps drive/pool makes things like pfsense easier.  It also makes management more intuitive, both the Cache and Apps drives/pools are optional and work almost the same, but one starts and stops with the array, the other doesn't.

If unRAID implemented an apps drive then I would have an apps drive and no cache drive since I never cache user shares. As it is, I just use the supported cache pool functionality as my apps drive.

[danioj]

I like the idea of a separate drive or pool, call it 'Apps' for want of something better, with the primary distinction that it starts and stops with the system, unlike the Cache drive or pool which goes up and down with the array.  It makes it easier to manage always-on apps.  It also should be easy to implement, because it just uses a stripped down version of the Cache drive/pool code base, minus the Share stuff and 'Cache: Only' stuff.  An officially supported Apps drive/pool makes things like pfsense easier.  It also makes management more intuitive, both the Cache and Apps drives/pools are optional and work almost the same, but one starts and stops with the array, the other doesn't.

 

You have reminded me why I originally did this. Having these disks mount and be available when the system starts just seemed to "feel" nicer to me. Not even close to an argument to do it really BUT I do like everything in it's own little box:

 

Cache is Cache.

App is App.

Array is Array.

 

Maybe speaks to my OCD rather than anything else.

[InlineRanger]

If unRAID implemented an apps drive then I would have an apps drive and no cache drive since I never cache user shares. As it is, I just use the supported cache pool functionality as my apps drive.

 

With a UPS and a lot of RAM, my need for a cache drive has disappeared. I too would prefer an officially supported apps drive for the reasons RobJ mentioned.

[hernandito]

I get the idea of having access to your apps folders when the array is down... but I value my precious sata ports and the potential additional storage too much to want to dedicate it for that.

 

Unless you can get Dockers (and plugins) working with the array down, there is no way I will give up a drive bay, or sata port for just the apps. That would be a cool mystery feature of 6.2. Dockers that work with array down.... although what would they do with the volume mappings...?!

 

 

[danioj]

Well I've done it. I'v moved all my apps / vm's and config to the cache and have added the drive (previously mounted via unassigned devices) outside of the array into the cache pool - which is now sitting at 500GB (3 x 250GB SSD's) - RAID-1 375GB (3 x 250GB SSD's) - RAID-1.

 

I did realise one thing when I was doing it - obviously now this disk takes up an unRAID license disk slot - which it didn't before. However, the data on it is now protected so it's not a bad trade off.

[itimpi]

Well I've done it. I'v moved all my apps / vm's and config to the cache and have added the drive (previously mounted via unassigned devices) outside of the array into the cache pool - which is now sitting at 500GB (3 x 250GB SSD's) - RAID-1.

 

I did realise one thing when I was doing it - obviously now this disk takes up an unRAID license disk slot - which it didn't before. However, the data on it is now protected so it's not a bad trade off.

Unless you have a Pro license then a drive counts against the unRAID license regardless of whether it is being used by unRAID as the license counts storage devices attached to the PC running unRAID, not just those that are configured for unRAID use.  With the Pro license this might be an issue as that license has no limit on attached devices but does have a limit on the maximum number of devices that can be configured for use by unRAID (currently 25).  However to use all the allowed slots on the Pro license you have to have a very big unRAID system and I think the number of people who reach that limit is comparatively small.

[danioj]

Well I've done it. I'v moved all my apps / vm's and config to the cache and have added the drive (previously mounted via unassigned devices) outside of the array into the cache pool - which is now sitting at 500GB (3 x 250GB SSD's) - RAID-1.

 

I did realise one thing when I was doing it - obviously now this disk takes up an unRAID license disk slot - which it didn't before. However, the data on it is now protected so it's not a bad trade off.

Unless you have a Pro license then a drive counts against the unRAID license regardless of whether it is being used by unRAID as the license counts storage devices attached to the PC running unRAID, not just those that are configured for unRAID use.  With the Pro license this might be an issue as that license has no limit on attached devices but does have a limit on the maximum number of devices that can be configured for use by unRAID (currently 25).  However to use all the allowed slots on the Pro license you have to have a very big unRAID system and I think the number of people who reach that limit is comparatively small.

 

Very good info. Thanks for posting 

[trurl]

Well I've done it. I'v moved all my apps / vm's and config to the cache and have added the drive (previously mounted via unassigned devices) outside of the array into the cache pool - which is now sitting at 500GB (3 x 250GB SSD's) - RAID-1.

 

I did realise one thing when I was doing it - obviously now this disk takes up an unRAID license disk slot - which it didn't before. However, the data on it is now protected so it's not a bad trade off.

Should be 375GB. Not sure unRAID reports this correclty.

[danioj]

Well I've done it. I'v moved all my apps / vm's and config to the cache and have added the drive (previously mounted via unassigned devices) outside of the array into the cache pool - which is now sitting at 500GB (3 x 250GB SSD's) - RAID-1 375GB (3 x 250GB SSD's) - RAID-1.

 

I did realise one thing when I was doing it - obviously now this disk takes up an unRAID license disk slot - which it didn't before. However, the data on it is now protected so it's not a bad trade off.

Should be 375GB. Not sure unRAID reports this correclty.

 

You are of course correct. 375GB Pool NOT 500GB. My reporting was wrong!!