Don't know where to start

[lfernandoec]

is the behavior normal?The free space of the l2 disk is 0.

This means that L2 storage is full. You may let it be because PrimoCache will automatically replace old data by new data. Alternatively, if you find current hit rate is not good, you may clear its content and PrimoCache will re-cache.

maybe we have a problem here.

The first time i executed the comand the L2 had 150MB. That's why i thought something was wrong.

I cleaned the cache (by GUI) and executed the comand again. Still 0 free.

Droped the partition, created again. Still 0.


Maybe, instead of the corrupted monitor, can there be some issue detecting the free space of the disc?

console vs GUI

command.png (33.06 KiB) Viewed 7079 times

[InquiringMind]

It might be the size of the L2 cache encountering an internal limitation in PrimoCache, since you are seeing *some* data being cached. Setting up a smaller L2 (5-10GB) could be one way to check this, if you've not already tested that.

[lfernandoec]

i tried reducing from 64GB to 32GB.
First thing i will do is formating to 5GB and see what happens

[lfernandoec]

Reduced the cache to 5GB. Same results. Slow write on GUI and on command line it appears as 0 free /5 total
Maybe there's some king of bug during the format?

[InquiringMind]

You mention having a notebook (so presumably no option to move the HDD to another interface). How about connecting up an external HDD and seeing how L2 cache performs on that? If that works, then it suggests a conflict with the Intel RST controller.

[lfernandoec]

My current configuration is a 1TB HDD (OS, Files, Everything) and a 120GB SSD ( 110 actually) bought only for caching.

I replaced the DVD with the SSD caddy caddy image

My notebook is a DELL 5537 with no RAID option, only AHCI, that's why i can't use the RAPID.

Maybe the problems lies on the port used?

[InquiringMind]

Having the SSD hooked up to the (former) DVD connector shouldn't normally be a problem (they'll both be using Serial ATA) but it might be worth benchmarking the SSD (if you haven't already done so) using Crystal Diskmark to check that its speed is up to scratch (modern SSDs should achieve 400-500MB/s sequential on SATA 3.0 and 200MB/s on SATA 2.0).

DVD drives don't run anything like as fast so it might just be possible that a slow connector is hampering your SSD to the point where PrimoCache avoids using it (don't know if it has that capacity, but it would be a clever feature to have).

Otherwise try an external drive hooked up to one of the USB 3.0 ports (if you don't already have a drive, you should purchase one ASAP for data backups) and use an image transfer utility like Clonezilla to copy the 1TB drive across, configure your BIOS to boot up from USB (the Dell *should* be able to do this, but best check before doing all the other stuff - if it lists multiple USB options, then you'll want the USB Hard Disk) and try reconfiguring PrimoCache L2. If that works, it would finger the Intel controller (or its driver software) as the culprit.

[lfernandoec]

I have a crystal mark for the SSD, but not with me right now.

Tell me if this is a valid test.
Instead of using a external drive for the SSD, i can REMOVE de HDD and replace it for the SSD. Install a clean windows in the SSD, then create a cache For the ssd IN the sdd.
For me it's a bit redunant having a ssd cached by a ssd. But i can try, for the sake of experimenting.

[InquiringMind]

Not too sure if PrimoCache will allow a drive to cache itself - even if it did, the results might not provide much insight. To rule out any Intel controller/driver conflict as a possible cause, you need to use a different interface and a USB connection seems the best alternative (or Firewire/IEE1394 if your laptop has one).

[lfernandoec]

Ram disk + Ram cache perhaps?

I'm tring to find ways to test now, instead of having to find a adapter, that could take me a day or two.
But the connection port really is something worth testing.