Has anyone played with Bcache? (Volker, I'm looking sideways at you...)
http://bcache.evilpiepirate.org/
--
:wq
09-21-2011, 05:53 PM
Volker Armin Hemmann
Bcache
Am Mittwoch 21 September 2011, 12:40:14 schrieb Michael Mol:
> Has anyone played with Bcache? (Volker, I'm looking sideways at you...)
>
> http://bcache.evilpiepirate.org/
hm, no updates to the website for almost a year and a gb+ git clone, no
patches. I pass.
--
#163933
03-14-2012, 02:53 PM
Vivek Goyal
Bcache
On Wed, Mar 14, 2012 at 09:32:28AM -0400, Kent Overstreet wrote:
> I'm already registered to attend, but would it be too late in the
> process to give a talk? I'd like to give a short talk about bcache, what
> it does and where it's going (more than just caching).
[CCing dm-devel list]
I am curious if you considered writing a device mapper driver for this? If
yes, why that is not a good choice. It seems to be stacked device and device
mapper should be good at that. All the configuration through sysfs seems
little odd to me.
On a side note, I was playing with bcache a bit. I tried to register the
cache device and it crashes. (I guess I should post this on relevant mailing
list).
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 04:24 PM
Kent Overstreet
Bcache
On Wed, Mar 14, 2012 at 11:53 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Wed, Mar 14, 2012 at 09:32:28AM -0400, Kent Overstreet wrote:
>> I'm already registered to attend, but would it be too late in the
>> process to give a talk? I'd like to give a short talk about bcache, what
>> it does and where it's going (more than just caching).
>
> [CCing dm-devel list]
>
> I am curious if you considered writing a device mapper driver for this? If
> yes, why that is not a good choice. It seems to be stacked device and device
> mapper should be good at that. All the configuration through sysfs seems
> little odd to me.
Everyone asks this. Yeah, I considered it, I tried to make it work for
a couple weeks but it was far more trouble than it was worth. I'm not
opposed to someone else working on it but I'm not going to spend any
more time on it myself.
>
> On a side note, I was playing with bcache a bit. I tried to register the
> cache device and it crashes. (I guess I should post this on relevant mailing
> list).
Can you post the full log? There was a bug where if it encountered an
error during registration, it wouldn't wait for a uuid read or write
before tearing everything down - that's what your backtrace looks like
to me.
You could try the bcache-3.2-dev branch, too. I have a newer branch
with a ton of bugfixes but I'm waiting until it's seen more testing
before I post it.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 05:12 PM
chetan loke
Bcache
On Wed, Mar 14, 2012 at 11:53 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Wed, Mar 14, 2012 at 09:32:28AM -0400, Kent Overstreet wrote:
>> I'm already registered to attend, but would it be too late in the
>> process to give a talk? I'd like to give a short talk about bcache, what
>> it does and where it's going (more than just caching).
>
> [CCing dm-devel list]
>
> I am curious if you considered writing a device mapper driver for this? If
> yes, why that is not a good choice. It seems to be stacked device and device
> mapper should be good at that. All the configuration through sysfs seems
> little odd to me.
I'm not a dm guru but a quick scan at flash-cache seems like it does
what you are saying. Now, if performance isn't acceptable then hashes
can be replaced with trees and what-not. Also no one would need to
re-invent the stacking mechanism. I saw thin support(atleast
documented) for dm. Plus, no matter what cache you come up with you
may have to persist/store the meta-data associated with it. And dm
seems like the right place to abstract that.
> Vivek
Chetan
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 05:17 PM
Kent Overstreet
Bcache
On Wed, Mar 14, 2012 at 2:12 PM, chetan loke <loke.chetan@gmail.com> wrote:
> I'm not a dm guru but a quick scan at flash-cache seems like it does
> what you are saying. Now, if performance isn't acceptable then hashes
> can be replaced with trees and what-not. Also no one would need to
> re-invent the stacking mechanism. I saw thin support(atleast
> documented) for dm. Plus, no matter what cache you come up with you
> may have to persist/store the meta-data associated with it. And dm
> seems like the right place to abstract that.
Bcache kills flash cache on performance - bcache can do around a
million iops on 4k random reads, and beats it on real world
applications and hardware too (i.e. mysql).
I'm not aware of any real features I'm missing out on by not using dm...
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 05:33 PM
chetan loke
Bcache
On Wed, Mar 14, 2012 at 2:17 PM, Kent Overstreet <koverstreet@google.com> wrote:
> On Wed, Mar 14, 2012 at 2:12 PM, chetan loke <loke.chetan@gmail.com> wrote:
>> I'm not a dm guru but a quick scan at flash-cache seems like it does
>> what you are saying. Now, if performance isn't acceptable then hashes
>> can be replaced with trees and what-not. Also no one would need to
>> re-invent the stacking mechanism. I saw thin support(atleast
>> documented) for dm. Plus, no matter what cache you come up with you
>> may have to persist/store the meta-data associated with it. And dm
>> seems like the right place to abstract that.
>
> Bcache kills flash cache on performance - bcache can do around a
> million iops on 4k random reads, and beats it on real world
> applications and hardware too (i.e. mysql).
>
Don't get too carried away with the perf numbers. re-read what I said:
"if performance isn't acceptable then hashes can be replaced with
trees and what-not".
> I'm not aware of any real features I'm missing out on by not using dm...
But you are not explaining why dm is not the right stack. Just because
it crashed when you tried doesn't mean it's not the right place.
flash-cache works, doesn't it? flash-cache's limitation is because
it's a dm-target or because it is using hashing or something else?
There are start-ups who are doing quite great with SSD-cache+dm. So
please stop kidding yourself.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 05:41 PM
Kent Overstreet
Bcache
On Wed, Mar 14, 2012 at 2:33 PM, chetan loke <loke.chetan@gmail.com> wrote:
> On Wed, Mar 14, 2012 at 2:17 PM, Kent Overstreet <koverstreet@google.com> wrote:
>> On Wed, Mar 14, 2012 at 2:12 PM, chetan loke <loke.chetan@gmail.com> wrote:
>>> I'm not a dm guru but a quick scan at flash-cache seems like it does
>>> what you are saying. Now, if performance isn't acceptable then hashes
>>> can be replaced with trees and what-not. Also no one would need to
>>> re-invent the stacking mechanism. I saw thin support(atleast
>>> documented) for dm. Plus, no matter what cache you come up with you
>>> may have to persist/store the meta-data associated with it. And dm
>>> seems like the right place to abstract that.
>>
>> Bcache kills flash cache on performance - bcache can do around a
>> million iops on 4k random reads, and beats it on real world
>> applications and hardware too (i.e. mysql).
>>
>
> Don't get too carried away with the perf numbers. re-read what I said:
> *"if performance isn't acceptable then hashes can be replaced with
> trees and what-not".
Nobody's stopping you.
>> I'm not aware of any real features I'm missing out on by not using dm...
>
> But you are not explaining why dm is not the right stack. Just because
> it crashed when you tried doesn't mean it's not the right place.
> flash-cache works, doesn't it? flash-cache's limitation is because
> it's a dm-target or because it is using hashing or something else?
> There are start-ups who are doing quite great with SSD-cache+dm. So
> please stop kidding yourself.
If you want me to implement bcache differently, shouldn't you explain
why? I'm not sure why I _have_ to justify my decisions to you.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 05:47 PM
Christoph Hellwig
Bcache
On Wed, Mar 14, 2012 at 02:41:35PM -0400, Kent Overstreet wrote:
> If you want me to implement bcache differently, shouldn't you explain
> why? I'm not sure why I _have_ to justify my decisions to you.
You don't have to - unless you want to get bcache merged into the
mainline kernel. If you don't want to you probably shouldn't bother
appearing at the LSF, though.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
03-14-2012, 05:54 PM
"Ted Ts'o"
Bcache
On Wed, Mar 14, 2012 at 02:33:25PM -0400, chetan loke wrote:
> But you are not explaining why dm is not the right stack. Just because
> it crashed when you tried doesn't mean it's not the right place.
> flash-cache works, doesn't it? flash-cache's limitation is because
> it's a dm-target or because it is using hashing or something else?
> There are start-ups who are doing quite great with SSD-cache+dm. So
> please stop kidding yourself.
SATA-attached flash is not the only kind of flash out there you know.
There is also PCIe-attached flash which is a wee bit faster (where wee
is defined as multiple orders of magnitude --- SATA-attached SSD's
typically have thousands of IOPS; Fusion I/O is shipping product today
with hundreds of thousands of IOPS, and has demonstrated a billion
IOPS early this year). And Fusion I/O isn't the only company shipping
PCIe-attached flash products.
Startups may be doing great on SSD's; you may want to accept the fact
that there is stuff which is way, way, way better out there than
SSD's which are available on the market *today*.
And it's not like bache which is a new project. It's working code,
just like flash cache is today. So it's not like it needs to justify
its existence.
Best regards,
- Ted
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Bcache
