Hi Kent, it would be really helpful if kernel patches (I mean diffs) would be provided. If it wasn't necessary to clone the whole repo to get to the bcache, instead only download kernel source and apply a patch, then probably some more people would be encouraged to try bcache and report possible bugs and/or test performance. I know I would do it. With some automatic/scripted patch generation and publishing it would really require minimal work from your part and probably provide much more feedback. Tools repo is not problematic in this respect. It is small. Just a thought and a recommendation:) b. On 8 September 2011 11:16, Damien Churchill <damoxc@xxxxxxxxx> wrote: > On 8 September 2011 10:10, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: >> On Thu, Sep 08, 2011 at 09:56:12AM +0100, Damien Churchill wrote: >>> On 8 September 2011 09:49, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: >>> > I just finished updating both the bcache (off 2.6.34) and the >>> > bcache-3.1 branches with the latest stable code. >>> > >>> > Also got cgit set up and working, finally. Need to stick a link in the >>> > wiki to it.. >>> > >>> > http://evilpiepirate.org/git >>> > >>> > I still haven't figured out how to pack a git repository so cloning it >>> > doesn't take > 80% of my linode's ram, but cloning works for me so I'm >>> > done screwing with it for now. >>> > >>> >>> I was able to make a clone by cloning Linus' repository on github, >>> then adding your repository as a remote then fetching, in case that >>> helps anyone. >> >> Yeah, that's one way around that issue. I really should just flip on >> cloning over http... git's memory consumption is kind of infuriating. >> > > I have to say I haven't really encountered memory issues with it when > hosting, but then I haven't tried hosting anything as large as the > kernel. > >>> > The bcache branch compiles but hasn't been tested. I don't expect any >>> > issues though, it's pretty close to what I normally develop/test on. >>> > >>> > The bcache-3.1 branch still doesn't quite compile, but it's pretty >>> > close - I'm try and get a working version pushed tomorrow, I did boot >>> > a linux 3.1 + bcache kernel at one point... >>> > >>> >>> I made a patch using the bcache-3.1 branch that does apply to the 3.0 >>> tree as well FYI. Haven't attempted to compile it yet but will do in a >>> bit, see what happens. Do you need to set CONFIG_BCACHE=y in the >>> kernel config? >> >> I think the block layer's been fairly quiet since ~2.6.39 or .38, the >> patches in the bcache-3.1 tree should move back that far without any >> issues. But it won't compile on any of them just yet.. I think the stuff >> that's left is trivial but it's late and I have to be up too early. >> >> And yeah, you'll need CONFIG_BCACHE. >> > > Well I shall look forward to what patches tomorrow brings in that > case. Thanks a lot! > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
