From: Gionatan Danti <firstname.lastname@example.org>
To: Zdenek Kabelac <email@example.com>
Cc: Mcdermott <firstname.lastname@example.org>,
LVM general discussion and development <email@example.com>
Subject: Re: [linux-lvm] when bringing dm-cache online, consumes all memory and reboots
Date: Tue, 24 Mar 2020 23:35:12 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
> 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
> We will likely fix this by setting max chunk size somewhere around
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
> 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
> devices and its implications - there is no universal setting that fits
> best all users.
Assyoma S.r.l. - www.assyoma.it 
email: email@example.com - firstname.lastname@example.org
GPG public key ID: FF5F32A8
next prev parent reply other threads:[~2020-03-24 22:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 17:57 [linux-lvm] when bringing dm-cache online, consumes all memory and reboots Scott Mcdermott
2020-03-23 8:26 ` Joe Thornber
2020-03-23 9:57 ` Zdenek Kabelac
2020-03-23 16:26 ` John Stoffel
2020-03-23 22:02 ` Scott Mcdermott
2020-03-24 9:43 ` Zdenek Kabelac
2020-03-24 11:37 ` Gionatan Danti
2020-03-24 15:09 ` Zdenek Kabelac
2020-03-24 22:35 ` Gionatan Danti [this message]
2020-03-25 8:55 ` Zdenek Kabelac
2020-03-23 21:35 ` Scott Mcdermott
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).