linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Krakow <kai@kaishome.de>
To: Giuseppe Della Bianca <giusdbg@gmail.com>
Cc: linux-bcache@vger.kernel.org
Subject: Re: [CACHE DEVICE] Space usage
Date: Sun, 4 Apr 2021 21:41:48 +0200	[thread overview]
Message-ID: <CAC2ZOYsWXUQ+AtQkoXXx50_XSQGMx9xBrgFNP7k0Mt8c79XMcQ@mail.gmail.com> (raw)
In-Reply-To: <4639704.31r3eYUQgx@exnet.gdb.it>

Hi!

Am So., 4. Apr. 2021 um 18:23 Uhr schrieb Giuseppe Della Bianca
<giusdbg@gmail.com>:
> In SSDs, full use of available space causes speed and durability problems.
>
> bcahe uses all the available space in the cache device?
>
> I could not find information on the maximum space used or how to set it.

There's no option for that in bcache. Instead, create a smaller
partition for bcache, then create a second partition filling the rest
of the device. You may want to use a size ratio of 80:20 for these
partitions tho modern drives usually already have an internal reserve
area, so 90:10 may be fine, too.

Now, use the blkdiscard command to trim the second partition. That way
the SSD knows that this is unused space it can use for wear leveling.
You may remove this second partition if you want to. In either case,
don't write anything to this space in the future.

Now continue to install bcache to the first partition created.

I've never seen any performance or endurance gains here using modern
Samsung drives so I've gone with using 100% for bcache. But my older
smaller drives had seen a benefit (usually better performance than
better lifetime) from using 80:20 or 90:10. So I'd say the bigger the
drive, the less likely you need to reserve any trimmed space.

So currently I'm using a hybrid approach and made the second partition
into a big swap partition: Most of it will stay trimmed but if the
system has to swap, it will at least find fast swap space here, and it
can be used for cold hibernation. You should not do that, tho, if your
system is low on memory: Swap isn't meant as emergency memory, and it
isn't meant as an extension to installed RAM. It's a space where the
system can put anonymous memory that's never used to make space for
disk caching. Only in that case, it's hardly ever written to or read
from.

Regards,
Kai

  reply	other threads:[~2021-04-04 19:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-04 16:15 [CACHE DEVICE] Space usage Giuseppe Della Bianca
2021-04-04 19:41 ` Kai Krakow [this message]
2021-04-05 10:43   ` gius db

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=CAC2ZOYsWXUQ+AtQkoXXx50_XSQGMx9xBrgFNP7k0Mt8c79XMcQ@mail.gmail.com \
    --to=kai@kaishome.de \
    --cc=giusdbg@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    /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).