Il 2020-03-24 16:09 Zdenek Kabelac ha scritto:
In past we had problem that when users have been using huge chunk size,
and small 'migration_threashold' - the cache was unable to demote
chunks
from the cache to the origin device (the size of 'required' data for
demotion were bigger then what has been allowed by threshold).
So lvm2/libdm implemented protection to always set at least 8 chunks
is the bare minimum.
Now we face clearly the problem from 'the other side' - users have way
too big chunks (we've seen users with 128M chunks) - and so threshold
is set to 1G
and users are facing serious bottleneck on the cache side doing to many
promotions/demotions.
We will likely fix this by setting max chunk size somewhere around
2MiB.
Thanks for the explanation. Maybe is a naive proposal, but can't you
simply set migration_threshold equal to a single chunk for >2M sized
chunks, and 8 chunks for smaller ones?
Yeah - if you read only 'directory' metadata structures - it's
perfectly OK with caching, if you do a full data read of the whole
storage it's not going to help (which is what I've meant).
The main message is - cache is there to accelerate often read disk
blocks.
If there is no hotspot and disk is mostly read over the whole address
space equally there will be no big benefit of cache usage.
However main message should be - user should think about sizes of
caching
devices and its implications - there is no universal setting that fits
best all users.
Sure.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
