Working bcache patchset?

Working bcache patchset?

[Heiko Wundram]

Hey!

I'm currently evaluating bcache for a pet project of mine (seeing the 
great performance numbers in the hosting environment tests posted here 
really sold me on to the idea), but I'm currently stumped by the bcache 
HEAD repository state (bcache on a 3.4.0+) from 
http://evilpiepirate.org/cgi-bin/cgit.cgi/linux-bcache.git, which does 
compile fine (but only if you don't activate CGROUP support for bcache, 
that is broken, and the "simple" naming fixes for struct bcache_group I 
tested don't allow it to compile either...), but:

* the current head implements a (slightly) different kind of sysfs-API 
than is documented (concerning cache_mode, the "writeback" flag doesn't 
exist anymore), which is self-documenting mostly, at least from what I 
gather,
* and secondly, it's easy to lose a volume completely by simply setting 
a backing volume to writeback caching mode. Detaching the cache from a 
working writeback volume doesn't work at all (gives no dmesg output, 
does not seem to start the flush), stopping the backing volume does 
work, reattaching the cache device after registering the backing device 
again is impossible: "bcache: Couldn't find uuid for md127 in set",
* and thirdly, setting readahead to anything else than zero makes 
bcache access blocks behind the end of device (the backing device isn't 
a multiple of the readahead size I tested): "md127: rw=0, 
want=5816029416, limit=5816028912"

As people have had success with bcache from what I gather: is there any 
working revision/patch I can up/downgrade to? ;-) All other tags 
published on the mentioned gitweb don't seem to be versions which could 
be used pseudo-productively, and cloning from the published repository 
git://evilpiepirate.org/~kent/linux-bcache.git currently fails:

modelnine # git clone git://evilpiepirate.org/~kent/linux-bcache.git
Cloning into 'linux-bcache'...
remote: Counting objects: 2441832, done.
remote: aborting due to possible repository corruption on the remote 
side.
fatal: early EOF
fatal: index-pack failed
modelnine #

Scrolling through the repository state published by web didn't 
immediately hint at a previous tag/state in the repository that would be 
usable. Thanks for any hints!

-- 
--- Heiko.

Re: Working bcache patchset?

[Kent Overstreet]

On Mon, Jun 11, 2012 at 03:30:46AM -0700, Kent Overstreet wrote:
> On Fri, Jun 08, 2012 at 12:40:31PM +0200, Heiko Wundram wrote:
> > Hey!
> > 
> > I'm currently evaluating bcache for a pet project of mine (seeing
> > the great performance numbers in the hosting environment tests
> > posted here really sold me on to the idea), but I'm currently
> > stumped by the bcache HEAD repository state (bcache on a 3.4.0+)
> > from http://evilpiepirate.org/cgi-bin/cgit.cgi/linux-bcache.git,
> > which does compile fine (but only if you don't activate CGROUP
> > support for bcache, that is broken, and the "simple" naming fixes
> > for struct bcache_group I tested don't allow it to compile
> > either...), but:
> 
> Yeah, the block cgroup stuff changed and I've been meaning to ask Tejun
> the best way to do that now since he's been working on that stuff.
> 
> > 
> > * the current head implements a (slightly) different kind of
> > sysfs-API than is documented (concerning cache_mode, the "writeback"
> > flag doesn't exist anymore), which is self-documenting mostly, at
> > least from what I gather,
> 
> The documentation is perpetually out of date.
> 
> > * and secondly, it's easy to lose a volume completely by simply
> > setting a backing volume to writeback caching mode. Detaching the
> > cache from a working writeback volume doesn't work at all (gives no
> > dmesg output, does not seem to start the flush), stopping the
> > backing volume does work, reattaching the cache device after
> > registering the backing device again is impossible: "bcache:
> > Couldn't find uuid for md127 in set",
> > * and thirdly, setting readahead to anything else than zero makes
> > bcache access blocks behind the end of device (the backing device
> > isn't a multiple of the readahead size I tested): "md127: rw=0,
> > want=5816029416, limit=5816028912"
> 
> Thanks for the bug reports - you weren't the only one who noticed
> writeback issues, I spent the weekend chasing down bugs and I should
> have new code up soon.
> 
> I think I've probably got all the writeback issues sorted out now - the
> one that was affecting you was a bug where background writeback wasn't
> marking anything as clean, so it'd never finish. When you try to detach
> a device with dirty data, the detach is supposed to finish as soon as
> all the dirty data is flushed.
> 
> The reregister after you stop was probably because when you detached, it
> marked the superblock as detached... but that shouldn't happen until
> after the dirty data is flushed, so there might be a bug there. Were you
> unable to reattach, or was that just not reattaching automatically?
> 
> > 
> > As people have had success with bcache from what I gather: is there
> > any working revision/patch I can up/downgrade to? ;-) All other tags
> > published on the mentioned gitweb don't seem to be versions which
> > could be used pseudo-productively, and cloning from the published
> > repository git://evilpiepirate.org/~kent/linux-bcache.git currently
> > fails:
> 
> Unfortunately no, the old well tested stuff is for older internel
> kernels (and it's now very old) and the stuff for upstream kernels has
> been in quite a state of flux since I've been finally trying to push it
> upstream.
> 
> But I've been devoting more time to the public branches lately, so I
> ought to have the last of these issues sorted out soon.
> 
> > 
> > modelnine # git clone git://evilpiepirate.org/~kent/linux-bcache.git
> > Cloning into 'linux-bcache'...
> > remote: Counting objects: 2441832, done.
> > remote: aborting due to possible repository corruption on the remote
> > side.
> > fatal: early EOF
> > fatal: index-pack failed
> > modelnine #
> 
> That's the server side OOMing. I eventually gave up trying to get it to
> work consistently. The workaround is to clone from a different repo and
> add it as a remote and then fetch.
> 
> > 
> > Scrolling through the repository state published by web didn't
> > immediately hint at a previous tag/state in the repository that
> > would be usable. Thanks for any hints!
> > 
> > -- 
> > --- Heiko.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html