A few rookie questions

[spike6479]

So far I'm extremely happy with your product. It noticeably improves the performance of my system.
My storage configuration is as follows:
5 HDDs in an external jbod attached with eSATA, backup drives
7 HDDs internal to system
120 GB SATA SSD
500 GB M.w SSD (system drive)

I currently have configured 2 cache tasks:
1. eSATA drives, L2 on SATA SSD
2. Often used internal drives, L2 200GB on M.2

QUESTIONS:
1. What queue depth do you use for disk I/O?
2. Is there a penalty to pay to include rarely used internal drives in cache task?
3. I have each cache task set to use 4GB RAM. Are the 2 cache tasks sharing the same RAM, or I am using 8GB?
I found the answer, yes it does use 8GB; makes sense to me
4. Should I cache my system drive?
5. The reason I created a second cache task was to make use of the SATA SSD and because the eSATA drives are turned off for all but one day of the week. Is there a better way do this?

SUGGESTIONS:
It might be nice to allow naming the cache tasks.
It would also be nice to status of the cache task, like is it running.

Keep up the good work. The trial is going well and I will be purchasing primocache soon

[Jaga]

1. What queue depth do you use for disk I/O?

Don't know - Support will have to answer that one.

2. Is there a penalty to pay to include rarely used internal drives in cache task?

Not really. Primocache keeps the most frequently accessed blocks in the cache task. The only exception is if the task shares read/write space, and you write large files to one of it's cached volumes. It has the possibility of flushing other infrequently-used blocks and holding onto the newly-written file's blocks. With smaller caches, that has the capability of flushing a large amount of content.

4. Should I cache my system drive?

I definitely would. It seriously speeds up the system as a whole. You might want to give the cache task that hosts blocks for the boot drive a bit more L1 memory however, since 4GB is rather small to begin with. 6 or 8 GB would be preferable. Or create it a dedicated L1 task with at least 4GB of RAM.

5. The reason I created a second cache task was to make use of the SATA SSD and because the eSATA drives are turned off for all but one day of the week. Is there a better way do this?

In my opinion it would be better to enable sleep mode for the drives rather than turning them completely off (and having them off across reboots throughout the week). That way Primocache knows their status (and can rely on the cache blocks not being dirty) at all times when the computer is running. If the drives aren't accessed, they simply stay asleep. Even a long sleep timer like 4 hours would work well, if you don't constantly reboot.

SUGGESTIONS:
It might be nice to allow naming the cache tasks.

That would be nice.

It would also be nice to status of the cache task, like is it running.

Click on any drive inside a cache task, look for the "Status" label in the UI. Active means it's running, paused means it's not.

[spike6479]

Thanks for the detailed reply.

The drives attached by eSATA are powered off for several reason:
1. They are located in an external port multiplied box, that has a relatively noisy power supply fan
2. With backups off line most of the time, they are not susceptible to any virus attack
3. The driver for the eSATA adapter is not the most stable. I don't reboot my system very often, usually just when powering on/off the external box.

My plan is to get more RAM when the prices come down. I built this system in Dec 17 and RAM was very pricey at the time.

I'll give caching the system drive a shot. My thinking was that, given the L2 cache is on the M.2 SSD and SATA SSD, caching the system drive, also on the M.2 SSD, wouldn't make much difference. I understand that the L1 cache would help, but I thought the L2 cache might actually slow it down.

[Jaga]

You definitely wouldn't want to cache the M.2 (boot) with the SSD (L2). You can turn off that behavior by clicking the "Volume Specifications" button in the cache task configuration screen. Just toggle the L2 off for the boot volume in there, and it'll only use the L1 to cache the OS. The best solution for faster boot drives (in my experience) is to create their own L1 task - even 2GB can give a decent boost when dedicated like this.

Theoretically the L2 will persist even with the eSATA drives turned off. Because no writes are happening (that Primocache knows of), it won't try to update any of it's tracking flags in the registry, and shouldn't think the cache is dirty. So.. it'll probably work fine the way you have it planned by turning them off. I just have to wonder sometimes at the specific list of things that Primocache uses to trigger a flush on a cache when it thinks it is out-of-sync. Keep an eye on that L2 eSATA cache task and see how it goes.

[spike6479]

It looks like primocache was smart enough to recognize that my system drive wouldn't benefit from l2 cache as it comes up disabled.

I've decided not to cache my backup drives at all. I've scheduled my backups to run at night and the incremental backups have no problems completing. If I want/need to do a full backup of a drive. I'm planning on trying caching the backup drives just for the duration of the full backup. I'm going to setup a separate cache task for backup using the SATA SSD so it won't interfere with the main cache. Fortunately if you pause a cache task, it releases the L1 cache RAM.

I'm not concerned with boot times, as I don't boot that often; and most of the boot time is spent dealing with the HDDs.

It looks like you can't have L2 cache on 2 drives. Although I've specified my M.2 and SATA SSD as L2 cache in the task configuration, you can only select one to be used.

Thanks for your responses they have been helpful.

[Jaga]

I've decided not to cache my backup drives at all. I've scheduled my backups to run at night and the incremental backups have no problems completing. If I want/need to do a full backup of a drive. I'm planning on trying caching the backup drives just for the duration of the full backup. I'm going to setup a separate cache task for backup using the SATA SSD so it won't interfere with the main cache. Fortunately if you pause a cache task, it releases the L1 cache RAM.

I pause Primocache during backups using rxpcc.exe (the command-line version). Here's a snippet of what I have in a batch file that runs via the Windows Scheduler:

Code: Select all

rxpcc pause -a -s
timeout 10
cd "C:\Program Files\Macrium\Reflect"
Reflect.exe -e -w "C:\Users\username\Documents\Reflect\My Backup.xml" -full
timeout 10
rxpcc resume -a -s

That way none of what the backup program reads is cached, and I consistently get higher hitrates. The initial pause is so that whatever's in the deferred write cache has time to fully flush.

And while you can't have a L2 spread across two SSDs, you can make a RAID 0 stripe with two of them and use that volume as a L2.

[spike6479]

Pausing the main cache is a great idea. It looks like I can move volumes from my main cache task to the backup cache with the cli. I think this will work well.
Thanks again.