All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Use fast device only for metadata?
Date: Tue, 9 Feb 2016 22:29:59 +0100	[thread overview]
Message-ID: <20160209222959.26ccded4@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 87k2mdeufs.fsf@vostro.rath.org

Am Tue, 09 Feb 2016 08:10:15 -0800
schrieb Nikolaus Rath <Nikolaus@rath.org>:

> On Feb 09 2016, Kai Krakow <hurikhan77@gmail.com> wrote:
> > You could even format a bcache superblock "just in case",
> > and add an SSD later. Without SSD, bcache will just work in passthru
> > mode.
> 
> Do the LVM concerns still apply in passthrough mode, or only when
> there's an actual cache?

I don't think anyone ever tried... But I think there's actually not
much logic involved in passthru mode, still it would pass through the
bcache layer - where the bugs may be. It may be worth stress testing
such a setup first, then do your backups (which you should do anyways
when using btrfs, so this is more or less a no-op).

There may even be differences if backing is on lvm, or if caching is on
lvm, and the order of layering (bcache+lvm+btrfs, or lvm+bcache+btrfs).
I think you may find some more details with the search machine of your
preference. I remember there were actually some posts detailing exactly
about this - including some mid-term experience with such a setup.

What ever you find, passthru-mode is probably the easiest path
regarding to code complexity, so it may not reproduce bugs others
found. You may want to try to reproduce exactly their situations but
just using passthru mode and see if it works.

I suspect the hardware storage stack may also play its role (SSD
firmware, SATA/RAID chipset, trim support on/off, NCQ support, ...)


-- 
Regards,
Kai

Replies to list-only preferred.


  reply	other threads:[~2016-02-09 21:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-07 19:06 Use fast device only for metadata? Nikolaus Rath
2016-02-07 20:07 ` Kai Krakow
2016-02-07 20:59   ` Martin Steigerwald
2016-02-08  1:04     ` Duncan
2016-02-08 12:24     ` Austin S. Hemmelgarn
2016-02-08 13:20       ` Qu Wenruo
2016-02-08 13:29         ` Austin S. Hemmelgarn
2016-02-08 14:23           ` Qu Wenruo
2016-02-08 21:44     ` Nikolaus Rath
2016-02-08 22:12       ` Duncan
2016-02-09  7:29       ` Kai Krakow
2016-02-09 16:09         ` Nikolaus Rath
2016-02-09 21:43           ` Kai Krakow
2016-02-09 22:02             ` Chris Murphy
2016-02-09 22:38             ` Nikolaus Rath
2016-02-10  1:12               ` Henk Slager
2016-02-09 16:10         ` Nikolaus Rath
2016-02-09 21:29           ` Kai Krakow [this message]
2016-02-09 18:23         ` Henk Slager
2016-02-09 13:22       ` Austin S. Hemmelgarn
2016-02-10  4:08       ` Nikolaus Rath

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=20160209222959.26ccded4@jupiter.sol.kaishome.de \
    --to=hurikhan77@gmail.com \
    --cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.