I am with you on this, and totally understand your concern and it's valid, if the user's experiencing slowness, then it could be number of things:
I believe we could see this as :
Will:
1) Tweaking number of cooling days (31 days) : To see if that makes any difference, in that case, atleast the "file" stays on local tier (SSD) for long enough to service any demand. Beyond that point, may be all or some block ranges are cold, and it's tiered off. Still not bad.
2) According to Fabric Pool concepts (Neither I have implemented nor I am expert, but I am also getting aware through TR) : It says if the access request pattern for the 'requested' blocks are random, then it's moved back (to SSD), if not, then it stays where its. This is interesting b'cos, technically you have no control over 'files/folders' (at logical file-system level), as the BLOCKS are being moved here. Now, whatever algorithm is utilized here, we cannot really get the hang of it, and that's not in our control as Admins. The only thing we can do is : Raise a ticket with NetApp and treat it as 'FabricPool' performance incident. Support will have their tools to get to the bottom of this (based on : cooling days, file-access pattern, network load, system load, size etc) and we go from there.
The tiering minimum cooling period is 2 days. You can modify the default setting for the tiering minimum cooling period with the -tiering-minimum-cooling-days parameter in the advanced privilege level of the volume create and volume modify commands. Valid values are 2 to 63 days.
https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-psmg%2FGUID-149A3242-B120-49CB-B712-BDDED53ED25D.html
Keep yours inputs coming in.
Thanks!