Share - Use cache disk


Recommended Posts

Hi,

 

By default the "Use cache disk" is set to No.

 

I have a Sandisk Ultra 2 480 GB SSD.

 

If I set to yes, does that mean that everything that is read and written to the array is written to the SSD first then moved onto the disks in the array?

 

Is it a good idea to enable Yes to this ? And are there any caveats?

 

Thanks

 

Link to comment

That exactly what it does.  The pro of this is speed. As your new data needs all the drives spinning to write the new bits, then read existing ones to calculate the parity bit.

 

As for if you should use it or bit is entirely up to you.  I know I would, and do.

 

Sent from my Oneplus One

 

 

Link to comment

Hi,

 

By default the "Use cache disk" is set to No.

 

I have a Sandisk Ultra 2 480 GB SSD.

 

If I set to yes, does that mean that everything that is read and written to the array is written to the SSD first then moved onto the disks in the array?

 

Is it a good idea to enable Yes to this ? And are there any caveats?

 

Thanks

 

Caveat: the performance improvement is more significant without Turbo Write (selectable option in 6.2.0 beta). With Turbo Write, I get 110MB/s on array and about 210MB/s on cache.

 

Still significant improvement but for most daily incremental changes, you might not even bother.

 

Cache is still very relevant with VM vdisks and docker images.

A vdisk on the same SSD cache gets me to 400MB/s (because a vdisk doesn't get the same network penalty).

Link to comment

When writing larger images to the array would it be sensible to use SSD caching? for example 4.5GB - 7.8GB single files.

 

Would this significantly hinder the lifespan of the SSD would you expect?

 

I spotted that it was possible to enable SSD caching on some but not all HDDs.

If I had the high water allocation method enabled. Would I need to have a specific share to segregate which drives would use caching

or is this possible on a HD by HD basis (although I don't think with high water if I understand it right? that would be controllable.)

 

 

Link to comment

Just another point of view - I don't use my cache drive for write-caching.  I find that small files (a couple GB) are written quickly to the array because they are cached in available RAM by unRAID 6.  After that, I prefer to know that my files are protected by parity immediately, instead of after mover runs at night.  Writes to the parity protected array aren't fast but they're fast enough for my purposes.  It's personal preference, and depends how you use your array.

Link to comment

 

If I set to yes, does that mean that everything that is read and written to the array is written to the SSD first then moved onto the disks in the array?

 

 

I think it's important to clear up that writes are redirected to the cache, data that is on the array and being read is read from the array, data that is on the cache waiting to be moved to the array will be read from the cache, but the data from the array isn't redirected though the cache for a read operation.

 

Also the most common reason for using a cache at this point is to have a disk outside of your array for the purpose application storage and operations. This keeps your array disks from spinning up all the time, it can also greatly improve performance of some apps.

Link to comment

Just another point of view - I don't use my cache drive for write-caching.  I find that small files (a couple GB) are written quickly to the array because they are cached in available RAM by unRAID 6.  After that, I prefer to know that my files are protected by parity immediately, instead of after mover runs at night.  Writes to the parity protected array aren't fast but they're fast enough for my purposes.  It's personal preference, and depends how you use your array.

I totally agree with you. I don't have any share set up with Cache = Yes. Either "Only" for performance or "No" for parity.

 

A sizeable 25GB file takes only 2 minutes to write to array. A word doc takes not even 1 second.

Link to comment

Thanks for your help and replies.

 

Sorry if I'm been a bit thick here.  :-\

I'm clearly new to all this. I've read the notes below Use cache disk: from the help button to try and understand the main differences between YES and ONLY.

 

Could someone please explain it better?

Link to comment

To clear up a misconception you seem to have:

 

Array disks are not cached, user shares are. Any writes made directly to a disk will go directly to that disk. It is only when you write to a user share that unRAID decides whether or not to cache that write and then move it to the array at the scheduled time.

 

The "Use cache disk" for each user share can be set to Yes, No, or Only. This and other User share settings are explained in the Help on that settings page. You can get the help by toggling the Help button.

 

Yes - writes to the user share are written first to cache then moved to array at the scheduled time.

No - writes to the user share are not written to the cache disk, but to the array disk(s).

Only - writes to the user share are written to the cache disk but not moved to the array.

 

Here is some more information about user shares that may not be obvious but can have very important effects:

 

A user share is actually a top level folder on cache or array disk(s). The folder has the same name as the user share.

Conversely, any top level folder on cache or array disk(s) is a user share. The user share has the same name as the folder.

 

If you don't make settings for a user share it will have default settings, which includes Use cache: No.

 

When unRAID writes a file to a user share, it writes it in accordance with the Use cache settings for that share. But when unRAID reads a user share, it will read from any disks (including cache) that have a top level folder named for that share. So it is possible to have writes that go to the array and not to cache while the reads could include files on cache, or have writes that only go to cache while the reads could include files not on cache.

 

Hope I haven't confused things even further. ;)

  • Like 1
Link to comment

To clear up a misconception you seem to have:

 

Array disks are not cached, user shares are. Any writes made directly to a disk will go directly to that disk. It is only when you write to a user share that unRAID decides whether or not to cache that write and then move it to the array at the scheduled time.

 

The "Use cache disk" for each user share can be set to Yes, No, or Only. This and other User share settings are explained in the Help on that settings page. You can get the help by toggling the Help button.

 

Yes - writes to the user share are written first to cache then moved to array at the scheduled time.

No - writes to the user share are not written to the cache disk, but to the array disk(s).

Only - writes to the user share are written to the cache disk but not moved to the array.

 

Here is some more information about user shares that may not be obvious but can have very important effects:

 

A user share is actually a top level folder on cache or array disk(s). The folder has the same name as the user share.

Conversely, any top level folder on cache or array disk(s) is a user share. The user share has the same name as the folder.

 

If you don't make settings for a user share it will have default settings, which includes Use cache: No.

 

When unRAID writes a file to a user share, it writes it in accordance with the Use cache settings for that share. But when unRAID reads a user share, it will read from any disks (including cache) that have a top level folder named for that share. So it is possible to have writes that go to the array and not to cache while the reads could include files on cache, or have writes that only go to cache while the reads could include files not on cache.

 

Hope I haven't confused things even further. ;)

 

Thanks for explaining this. Some of that did clear a few things up.

So when using "ONLY" for a user share which it is set at. The files will only ever exist on the SSD (cache) and never on the HD array?

That is how I just understood that.

 

 

Link to comment
Thanks for explaining this. Some of that did clear a few things up.

So when using "ONLY" for a user share which it is set at. The files will only ever exist on the SSD (cache) and never on the HD array?

That is how I just understood that

That's correct.  This feature is used, for instance, to keep Dockers and their data located on the Cache drive rather than the array.

Link to comment

A user share is actually a top level folder on cache or array disk(s). The folder has the same name as the user share.

Conversely, any top level folder on cache or array disk(s) is a user share. The user share has the same name as the folder.

Awesome! I have been manually distributing some files across the array by copying directly to the disk inside the top level folder with the share name. Have been worrying if I'm supposed to do that but this sounds like that's 100% fine.

 

Thanks for explaining this. Some of that did clear a few things up.

So when using "ONLY" for a user share which it is set at. The files will only ever exist on the SSD (cache) and never on the HD array?

That is how I just understood that.

That's correct. Generally docker image, docker data (aka "app data") and VM vdisk (aka "domain") should be set to Cache Only.

Link to comment

That exactly what it does.  The pro of this is speed. As your new data needs all the drives spinning to write the new bits, then read existing ones to calculate the parity bit.

 

As for if you should use it or bit is entirely up to you.  I know I would, and do.

 

Sent from my Oneplus One

 

Only for NEW files... If files are beiing overwritten that are allready in the array they will be written to the array directly even when cache is enabled..

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.