Questions[dm-cache](server)

I've added a 2 TB RAID1 SSD as a writeback cache to a 10 TB RAID1 HDD using LVM 2.03.11(2) (2021-01-08) like this:

lvcreate --type raid1 --mirrors 1 --nosync -l 100%FREE -n sshd sshd /dev/sdc /dev/sdd
lvcreate --type raid1 --mirrors 1 --nosync -l 100%FREE -n cache sshd /dev/nvme1n1 /dev/ssd_blend/ssd_blend
lvconvert --type cache --cachemode writeback --chunksize 2M --cachevol cache sshd/sshd

and the default behavior is slowly promoting new blocks. I want it to behave more like a writecache, where blocks are from the start written to the cache and later on moved to the slow disk. I want cached what was written last, regardless of the hit count.
I don't want to use writecache though, because I also want read cache.

Is there a way to do that?
I tried

lvchange --cachepolicy smq --cachesettings 'write_promote_adjustment=0' sshd

but doesn't do anything.

I have a SSD writeback cache in front of a HDD, set up through lvmcache (so a dm-cache). When the cache LV is not full (Data% column in lvs < 100.00%), writes go to the cache device (monitored via dstat). However, when the cache LV is full (Data% = 100.00%), writes go directly to the HDD, essentially becoming a writethrough cache. Blocks do not get evicted from the SSD cache, even after some time, and performance drops. When I try reading recently read data from the cached LV, reads are from the SSD, so I assume the entire SSD has now become a read cache. Is this expected behavior for dm-cache's write cache, even in writeback mode? Is there no reserved space for writes? This seems like quite a poor design as essentially users can only write one cache LV's worth of data before the cache becomes a writethrough cache.

My understanding is that dm-cache uses the mq eviction algorithm, but that only applies to read caching and thus is irrelevant to the write caching issue I am observing.

Is there a way to reserve space for a write cache, or use both a dm-writecache (which I understand will not do any read caching) and a dm-cache at the same time?

I have a host with a single cache LV (~800GB SSD in front of a multi-TB RAID array; write-through mode). I ran a routine scrub on the RAID last night (lvchange --syncaction check). Ever since that completed, the system has been running at 100% I/O capacity; iostat tells me it's reading data from the SSD and writing to the RAID.

The Cpy%Sync column of lvs output for the cache LV (not the RAID) started out at 98% or so before the scrub, which was worrisome in itself, but now it is steadily going down, having currently reached about 70%.

I thought Cpy%Sync for a cache LV indicated the amount of data on the cache that also existed on the backing store, so in write-through mode it should always be 100%. What does it actually mean and what is the system doing that's making it go down steadily?

There is nothing helpful in dmesg.