From: Kent Overstreet <kent.overstreet@gmail.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, rdunlap@xenotime.net,
axboe@kernel.dk, akpm@linux-foundation.org, neilb@suse.de
Subject: Re: [GIT] Bcache version 12
Date: Tue, 20 Sep 2011 22:57:09 -0700 [thread overview]
Message-ID: <20110921055708.GB6601@moria> (raw)
In-Reply-To: <CAOJsxLGWoGqdv=tdBwWjM9-MD_Qm3ibMSGpp1j-tQLjMW-b-0A@mail.gmail.com>
On Wed, Sep 21, 2011 at 08:42:01AM +0300, Pekka Enberg wrote:
> On Wed, Sep 21, 2011 at 5:55 AM, Kent Overstreet
> > <kent.overstreet@gmail.com> wrote:
> >> Short version: bcache is for making IO faster.
>
> On Wed, Sep 21, 2011 at 8:33 AM, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> > That's helpful...
>
> Your documentation isn't helpful either:
>
> +Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be
> +nice if you could use them as cache... Hence bcache.
>
> So it's a cool hack but you fail to explain why someone wants to use
> it. You also fail to explain why you decided to implement it the way
> you did instead of making it more like fscache, for example.
>
> Really, why do I need to go digging for this sort of information? It
> feels almost as if you don't want people to review your code...
The documentation should be better and better organized to be sure, but
I'm honestly not sure what's so strange about the concept of a cache for
block devices..
My changelog messages are certainly lousy but they aren't really the
place for a design doc, if that's what you're looking for.
As for bcache's design vs. fscache's design... well, they're so unlike
each other I'm not sure it even makes much sense to go into much.
Bcache caches block devices, fscache caches at the filesystem layer.
They each have uses where the other can't be used.
If you want more than that - IMO bcache's design is simpler, higher
performing, and more flexible.
bcache doesn't have to have a notion of files; it caches extents.
It can cache filesystem metadata - it can cache anything.
Because bcache has its own superblock (much like md), it can guarantee
that bcache devices are consistent; this is particularly important if
you want to do writeback caching. You really don't want to accidently
mount a filesystem that you were doing writeback caching on without the
ache - bcache makes it impossible to do so accidently.
Is any of that useful?
next prev parent reply other threads:[~2011-09-21 5:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-10 6:45 [GIT] Bcache version 12 Kent Overstreet
2011-09-11 6:18 ` NeilBrown
2011-09-11 19:23 ` Kent Overstreet
[not found] ` <FD294A0B-7127-4ED1-89B8-3E3ADA796360@dilger.ca>
[not found] ` <FD294A0B-7127-4ED1-89B8-3E3ADA796360-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
2011-09-12 1:44 ` Kent Overstreet
2011-09-15 21:15 ` Dan Williams
[not found] ` <CAA9_cmeqevWoK=9WMD9c+csc8SbaYq0aK9j1qWr_0FEa6jWZEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-15 21:33 ` Kent Overstreet
[not found] ` <CAC7rs0t_J+foaLZSuuw5BhpUAYfr-KY1iegFOxEBPCpbrkk1Dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-19 7:16 ` NeilBrown
2011-09-21 2:54 ` Kent Overstreet
2011-09-29 23:38 ` Dan Williams
[not found] ` <CAA9_cmfOdv4ozkz7bd2QsbL5_VtAraMZMXoo0AAV0eCgNQr62Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-30 7:14 ` Kent Overstreet
2011-09-30 19:47 ` Williams, Dan J
2011-09-15 22:03 ` Dan Williams
2011-09-15 22:07 ` Kent Overstreet
2011-09-19 7:28 ` Pekka Enberg
[not found] ` <CAOJsxLFPODubVEB3Tjg54C7jDKM8H-RCM_u5kvO1D0kKyjUYXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-21 2:55 ` Kent Overstreet
2011-09-21 5:33 ` Pekka Enberg
2011-09-21 5:42 ` Pekka Enberg
2011-09-21 5:57 ` Kent Overstreet [this message]
2011-10-06 17:58 ` Pavel Machek
2011-10-10 12:35 ` LuVar
2011-09-20 15:37 ` Arnd Bergmann
2011-09-21 3:44 ` Kent Overstreet
2011-09-21 9:19 ` Arnd Bergmann
2011-09-22 4:07 ` Kent Overstreet
[not found] <1280519620.12031317482084581.JavaMail.root@shiva>
2011-10-01 15:19 ` LuVar
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=20110921055708.GB6601@moria \
--to=kent.overstreet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=rdunlap@xenotime.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).