Trimmed Blocks Writing to Hard Drive from L1...???

FAQ, getting help, user experience about PrimoCache
Post Reply
mell111
Level 5
Level 5
Posts: 48
Joined: Fri Oct 05, 2018 11:16 am

Trimmed Blocks Writing to Hard Drive from L1...???

Post by mell111 »

I set up a write-only cache task with deferred-write using Average mode for an empty 8tb hard drive with a 16GB L1 cache and a 446GB L2 cache with 256kb block size. In the current use case, my software is generating writes at a rate of 20-50 MB/sec. The hard drive without cache is easily capable of sustained writes of well over 100 MB/sec.

In a few hours, about 750GB were written, _all_ of it through the L1 cache (0 writes to the L2 cache - fantastic!)

The very odd thing is that PrimoCache is reporting 15 Trimmed Blocks. Where would that come from? My system disk is an SSD (not the L2 cache SSD), but there is no cache task for it, nor has there ever been. The only TRIM activity I can imagine is to the system disk from Windows (I didn't do any manual TRIM to anything.)

What could be causing this? Even though it's a tiny percentage, could this cause data corruption? After all, it appears that PrimoCache is reporting that it discarded 15 blocks without writing them to disk, if I understood the online help description properly.

Unrelated to this, I'm also wondering what would generate urgent writes in this scenario - monitoring task manager for the hard drive shows it peaks at around 70% utilization and is mostly below 50%. PrimoCache reports %.05 deferred writes and a bit over 1% urgent writes. The urgent writes weren't just at the start - they've been increasing in number (not %) throughout. It's not a problem at all - like I said 0 writes to L2 and no sign of write throttling.

Thanks.
mell111
Level 5
Level 5
Posts: 48
Joined: Fri Oct 05, 2018 11:16 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by mell111 »

Following up: I just noticed that PrimoCache reports total writes 95%. Total write (L1/L2) 888GB; Total write (Disk) 844GB. Deferred blocks still 0.5%. The L1 cache is 16GB, L2Storage write still 0. Windows File Explorer reports around 840GB written. No sign of throttling or errors. Trimmed blocks still at 15 (which is 4MB :-). I won't be able to check overall data integrity for quite a while, but completed files seem fine.

What would account for this?
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by Support »

When files in a NTFS volume are deleted, NTFS file system will send TRIM commands to the underlying disk. Then PrimoCache will respond to these TRIM commands and discard related blocks. So if you see that PrimoCache reports TRIMMED BLOCKS, there should be files or filesystem metadata deleted before.

In current versions, when L1 write cache is almost full, "urgent writes" begins to count, though L2 write cache might still have lots of free space. We will improve this.
As you use AVERAGE mode and it seems that L1 write cache is enough to handle all writing requests, L2 write cache is not involved in your case.
mell111
Level 5
Level 5
Posts: 48
Joined: Fri Oct 05, 2018 11:16 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by mell111 »

Ah - I didn't realize TRIM was also issued to spinning disks.

What about the discrepancy between requested writes and total writes (consistently at around 95%) ? Thanks.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by Support »

mell111 wrote: Tue Nov 27, 2018 5:03 pm What about the discrepancy between requested writes and total writes (consistently at around 95%) ?
This is one of the benefits from Defer-Write, reducing total write amount. Please see
http://www.romexsoftware.com/en-us/prim ... -wear.html
mell111
Level 5
Level 5
Posts: 48
Joined: Fri Oct 05, 2018 11:16 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by mell111 »

That's great - thanks for the reference.

Following up on your point above:

"In current versions, when L1 write cache is almost full, "urgent writes" begins to count, though L2 write cache might still have lots of free space. We will improve this."

Since in my case the cache is 100% write and is large enough for the current use case to never require the L2 (16GB for max. 50MB/s writes with hard drive capable of accepting over 100MB/s writes) it seems PrimoCache should just be able to use already flushed blocks from L1 (of which there should be plenty.) It's probably doing that, but is that correct? I was wondering what you mean by "improve this". This part seems to be behaving as it should.

It occurs to me that the 10 second latency I set for defer-write may be too aggressive and may account for the urgent writes. What do you recommend for this scenario? Can you also mention what the trade-offs are for the latency setting? Thanks.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by Support »

mell111 wrote: Wed Nov 28, 2018 3:59 am it seems PrimoCache should just be able to use already flushed blocks from L1 (of which there should be plenty.) It's probably doing that, but is that correct?
Correct.
mell111 wrote: Wed Nov 28, 2018 3:59 am I was wondering what you mean by "improve this".
I mean that when L2 still have free write space, "urgent write" occurred in L1 shall not be counted as "urgent" in statistics.
mell111 wrote: Wed Nov 28, 2018 3:59 am Can you also mention what the trade-offs are for the latency setting?
Longer latency, more dirty data in the cache. So when the latency has expired, more data will be flushed to the disk at a time. During the flush phase, disk will be quite busy and may cost much CPU time. The benefit is longer latency may reduce more writes to disk, reduce disk activities, may have quicker response to applications who generate write requests.
A simple rule is that if system overall writing load is heavy, reduce latency. Another tuning rule is to avoid urgent writes (< 5%).

I think in your scenario (16GB L1 cache, write-in: 20~50MB/s, disk: 100MB/s), the writing load is not heavy, you may not need the average write mode. Native/Intelligent/Buffer is enough to handle writing requests. You may even use a longer latency since your cache is big and disk capability is much beyond writing requests.
mell111
Level 5
Level 5
Posts: 48
Joined: Fri Oct 05, 2018 11:16 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by mell111 »

Thanks. What is the drawback of average write mode compared to the others?
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Trimmed Blocks Writing to Hard Drive from L1...???

Post by Support »

with average write mode, target disks have more write activities as it checks and may write certain percent of current dirty data amount every 0.5s.
Post Reply