All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neuer User <auslands-kv@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs und lvm-cache?
Date: Thu, 24 Dec 2015 16:24:33 +0100	[thread overview]
Message-ID: <n5h2ni$53q$1@ger.gmane.org> (raw)
In-Reply-To: <pan$22dc8$3670cf4f$29866f7c$946ede75@cox.net>

Am 24.12.2015 um 03:04 schrieb Duncan:

I had a look at bcache, but focused on lvmcache mainly because of the
flexibility it offers. It can be easily added and removed. For LVM it is
just another LV, so all the LVM magic applies.

But thanks, I should take another look at bcache.


> I'll let others debate the lvm-cache details, which I don't know much
> about, but I do have a couple points to add, one of which is detail,
> one rather higher level.  The higher level one first:
> 
> 1) While I've seen both bcache and lvm-cache discussed as potential
> options here, there is at least one user using bcache on top of btrfs
> that posts to bcache-related threads here with some regularity.
> While there were some serious bugs to work thru early on, his
> recent posts suggest current bcache works very well with current
> btrfs, and given that he has posted to several threads with some
> time separation between them, he does appear to be a regular here,
> and I expect he'd be posting pretty fast if things started going
> buggy for him once again.
> 
> There hasn't been a corresponding regular poster here using lvm-cache,
> so while it may work well, we don't know that.  At minimum, postings
> thus suggest that bcache on btrfs is a better tested solution at
> this point, and thus, would be recommended, while lvm-cache on btrfs,
> while an equally valid technical choice in theory, doesn't have much
> if any real-world data going for it at this point, and is thus
> in practice an unknown.
> 
> 2) Not being the person using bcache and not being familiar with it
> or lvm-cache personally, I don't know how either one handle btrfs
> multi-device.  However, it occurs to me that if it's necessary,
> in addition to the multiple ssds suggested by the others to cover
> such multi-device caching, you should also be able to partition
> up the ssd, and use each partition as an individual device cache.
> That's almost certainly what I'd do here if I needed to (except
> that above a certain size, ssd prices per GiB start to go up
> dramatically, so if I wanted total ssd cache sizes above that I'd
> of course pay less for multiple smaller ssds again) instead of
> fiddling with multiple physical ssds, but again, not knowing
> how the caching works, I'm not sure if multiple cache devices
> would be needed to cache a multi-device btrfs at the back end,
> or not, so I don't know whether I'd need to bother with such
> partitioning or not.
> 
> The key here is that on ssds, seek time is zero anyway, so
> partitioning up the ssd and using both partitions as cache
> doesn't have the latency issues that attempting to do something
> like that (or for example btrfs raid1 on two partitions on the
> same physical device) would have on spinning rust.
> 
> 
> I thought I'd throw those points out, in case you had failed to
> notice bcache as an option and would prefer it as better tested,
> once you knew about it, and in case the partitioned ssd idea
> does help with the multi-device btrfs caching thing.
> 



  reply	other threads:[~2015-12-24 15:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23 10:45 btrfs und lvm-cache? Neuer User
2015-12-23 11:21 ` Martin Steigerwald
2015-12-23 11:38   ` Neuer User
2015-12-23 19:45     ` Noah Massey
2015-12-23 20:07       ` Neuer User
2015-12-23 20:38         ` Holger Hoffstätte
2015-12-23 19:49     ` Chris Murphy
2015-12-23 20:21       ` Neuer User
2015-12-23 20:56         ` Chris Murphy
2015-12-24 15:19           ` Neuer User
2015-12-23 20:24 ` Neuer User
2015-12-23 20:59   ` Chris Murphy
2015-12-24  2:04 ` Duncan
2015-12-24 15:24   ` Neuer User [this message]
2015-12-24 14:56 ` Piotr Pawłow
2015-12-24 15:29   ` Neuer User
2015-12-24 16:42     ` Piotr Pawłow
2015-12-25 17:11       ` Neuer User

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='n5h2ni$53q$1@ger.gmane.org' \
    --to=auslands-kv@gmx.de \
    --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.