Multiple Cache Pools ?

[Porterhouse]

v6.1.3 pro (x3):

Any chance of having multiple cache pools in future? I get that the cache pool is designed as an always on, fast write destination, but I would like to be able to separate this function from cache-only vdisks, which is different. Having a different pool for this would also permit a user to use faster, smaller SSD's for vdisk and then expand the normal cache-pool with more affordable, larger, last-gen SSDs, OR could we have SSD's supported in some other fashion in a future version, but obviously not within the parity array if that breaks the integrity of unRAID parity. Thanks

[itimpi]

Not quite sure why you need this?

 

I have some SSD's set up that are not under unRAID control for use by VM's.  Any reason that you cannot do something similar for your requirements.  Is there any specific reason it needs to be a cache disk?

[Porterhouse]

itimpi - can you explain how you're mounting your SSD's and how they're formatted (btrfs/XFS/other ?)

 

OK by cache in this context I meant 'make available in real time'. One of my issues for which a I'm suggesting a cache pool might be a solution, is that we have a large collection of ripped music, circa 300Gb of FLACs and MP3s, which my family access via Sonos from a unRAID share, but due to the need to spin-up disks, there's a lag before the media loads the artwork and plays. Not ideal in the middle of a party. I'd like to eliminate this lag by sync'ing my music library to an SSD. But also, 500Gb SSD's are not cheap, so I'd like the option to use an SSD (or maybe a pair of for resilience) last-gen, high capacity SSDs for this, in order to save a few hundred quid, whereas for a VDisk application I'd want to use the fastest, smallest SSD I could get away with. Why not make it possible to use a different cache pool for both these applications, with one SSD or two, depending on the application, hence, the option of having multiple pools, someday, but still within the licensing model for total number of disks.

 

     

[uldise]

itimpi - can you explain how you're mounting your SSD's and how they're formatted (btrfs/XFS/other ?)

Unassigned devices plugin? http://lime-technology.com/forum/index.php?topic=38635.0

[garycase]

...  due to the need to spin-up disks, there's a lag before the media loads the artwork and plays. Not ideal in the middle of a party. I'd like to eliminate this lag ...     

 

So just don't spin down the disks that contain that share.    You could even add a couple SSDs to your array and dedicate them to your music share.  These could be whatever size you find convenient, although for 300GB of data a single 500GB SSD is all  you need ... and these are pretty inexpensive these days (under $200).

 

 

[Porterhouse]

Thanks uldise. I'll have a look at the UDEV plugin. 

 

Garycase: You say 'add a couple SSDs to your array and dedicate them to your music share' .. but I thought SSD's were not supported in the array, ref this comment in the official wiki:

 

'Do not assign an SSD as a data/parity device. While unRAID won’t stop you from doing this, SSDs are only supported for use as cache devices due TRIM/discard and how it impacts parity protection. Using SSDs as data/parity devices is unsupported and may result in data loss at this time'

 

Is it OK to use SSD's in the array now ?

Thanks

[garycase]

I know it's been caveated, but I can't think of any technical reason not to use them.  TRIM/discard will only be done if there is TRIM support in the array ... otherwise they should work exactly as a "normal" drive.

 

Indeed, forum member Johnnie.Black has an all-SSD array (8 drives I think) that he's been kind enough to do a lot of extensive testing with to help isolate some issues in v6  [You might be interested in this:  http://lime-technology.com/forum/index.php?topic=43026.msg410578#msg410578  or  his posts that helped isolate the issue with Marvell-based SATA controllers here:  http://lime-technology.com/forum/index.php?topic=42629.msg417531#msg417531 ]

 

I wouldn't hesitate to use an SSD in my array if I wanted to eliminate the spin-up issue for a relatively small share that fit on an SSD (like your 300GB share).

 

 

[Porterhouse]

Cool .. I'll give it try and report back.

Thanks