Tiered Caching --> Writing wakes up disks

[Br33ce]

I know how you (trapexit) "feel" about tiered caching and why it's not the "holy grail" that some think it is, but I am trying to understand my system and it a little bit better.
So please forgive my asking :)

Reading a file, that is located on my cache drive does not wake the other disks. Thats how mergerfs is, afaik, supposed to work. Only the disk containing the necessary data for a read should wake up.
How about writing something TO the pool? Does it matter if I use ff or lfs for example as the latter might wake all disks to "ask" which one has the least free space?

What I've noticed is that writing wakes my disks, and I am not sure where to look first so I thought I'd start here.. If its not intendend behaviour of mergerfs than I will go on :) Thank you for any help or suggestions.

System:
6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (OMV 7)
SSD is first, policy ff

[Br33ce]

And I'd like to answer this myself instead of deleting it, so that others might learn (again) from my own stupidity:

The disks dont wake up on write (atleast not with ff which is what I am using (now)). The do wake up when you REPLACE a file that lives on the HDD part of the pool... :)

[trapexit]

When in doubt you can use strace (examples in the docs) to watch exactly what mergerfs is doing. And yes. ff will scan the branches in order and stop when it finds something so it can happen that it doesn't trigger a spinup for that specific call because it never makes it to that branch. But if you were using some other policy where it needs to query the other branches then naturally it would lead to a spinup.

[Br33ce]

Thanks! Just for my understanding, lfs might wake the HDDs to check the free space?

[trapexit]

Yes