I've seen a few threads on slow cache, but the performance here isn't "Oh that could be better", it's typically worse than just writing to straight to disk.

 

As a test, I ran `dd if=/dev/zero of=file.test bs=1024k count=8k` and, well, a picture is worth a thousand words:

 

853789+0 records in
853789+0 records out
6994239488 bytes (7.0 GB, 6.5 GiB) copied, 298.39 s, 23.4 MB/s

btrfs filesystem df:

Data, RAID1: total=84.00GiB, used=81.58GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=156.73MiB
GlobalReserve, single: total=84.41MiB, used=0.00B

No balance found on '/mnt/cache'

I have the dynamix trim plugin installed. I also tried manually trimming /mnt/cache right before running the test just to make sure it didn't error and was really running.

 

Pool setup:

 

Unraid 6.7.2, no useful log output.

Edited September 7, 20196 yr by Spitko

I've had to turn caching off on all shares as anything writing to cache for more than a few moments brings the whole server to a crawl. Writing lots of smaller new files does seem to be more stable than large file writes though; not quite sure if that's a useful datapoint yet.

 

Also if it helps, the SSDs are both ADATA SU635 (ASU635SS-240GQ-R). I knew going in that QLC drives were fairly flawed, but I don't think anything I'm doing here should be hitting the limitations of the tech. The drives are rated for 520/450MB/s R/W. While some people do report lower speeds, they're still an order of magnitude above what I'm getting here.

I'm getting crazy slow speeds to unraid server.  SMB transfers are 1 mb or less even with a cache drive!

Did you ever come up with a solution to your problem, OP?

Your issue sounds unrelated to mine... you should probably open a new thread.