linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nix <nix@esperi.org.uk>
To: kent.overstreet@gmail.com
Cc: Stefan K <shadow_7@gmx.net>,
	linux-bcache@vger.kernel.org, linux-bcachefs@vger.kernel.org
Subject: Re: how does the caching works in bcachefs
Date: Thu, 16 Jul 2020 22:07:19 +0100	[thread overview]
Message-ID: <87sgdr9njs.fsf@esperi.org.uk> (raw)
In-Reply-To: <20200709160805.GA158619@zaphod.evilpiepirate.org> (kent overstreet's message of "Thu, 9 Jul 2020 12:08:05 -0400")

On 9 Jul 2020, kent overstreet told this:

> In real world mixed workloads LRU is fine, it's not that much of a difference
> vs. the more sophisticated algorithms. More important is the stuff like
> sequential_bypass or some other kind of knob to ensure your backup process
> doesn't blow away the entire cache.

The ioprio thing that never got integrated into bcache (but is still
available as out-of-tree patches that work fine) is even better for
this: yes, it might not quite be what ioprio was meant for, but it means
the user has the equivalent of 'nocache' that they can apply to entire
process hierarchies that they don't want to pollute the cache, just by
using ionice. Run your backup with ionice -c 3 and now everything, even
the metadata reads, comes from the cache if it's already in the cache
but otherwise stays out of cache.

(This matters if you have a huge amount of metadata that is rarely read
except when the backup sweeps over it, and a not-too-huge cache device.
You don't want to waste cache space on stuff that only the backup is
accessing...)

      reply	other threads:[~2020-07-16 21:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08 21:46 how does the caching works in bcachefs Stefan K
2020-07-08 22:37 ` kent.overstreet
2020-07-09 13:20   ` Stefan K
2020-07-09 16:08     ` kent.overstreet
2020-07-16 21:07       ` Nix [this message]

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgdr9njs.fsf@esperi.org.uk \
    --to=nix@esperi.org.uk \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=shadow_7@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).