On 28 October 2011 04:17, Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx> wrote: > On Thu, Oct 27, 2011 at 1:51 PM, Damien Churchill <damoxc@xxxxxxxxx> wrote: >> On 27 October 2011 17:25, Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx> wrote: >>> On Thu, Oct 27, 2011 at 5:59 AM, Damien Churchill <damoxc@xxxxxxxxx> wrote: >>>> Hi, >>>> >>>> I've been testing bcache with the latest sources from the git tree. >>>> I've been attempting to use a rbd (RADOS block device) as the backing >>>> device. I can format the bcache0 device with mkfs.ext4, however when I >>>> mount it, there is a kernel bug when it attempts to initialize the >>>> filesystem. >>>> >>>> I'm unsure if this is a bug in rbd or bcache however, I'm including >>>> the stack trace outputted by the kernel. The kernel has been based off >>>> the current Ubuntu Precise kernel (3.1.0) patched with the changes >>>> from the bcache git repository as well as the changes from the ceph >>>> repository in for-next (the same thing happened without the changes >>>> from the ceph repository). bcache does function as expected when using >>>> a raw disk drive. >>>> >>> >>> Can you push a tree somewhere that has the exact kernel that you're >>> using, patched with the specific bcache version? It'll make it easier >>> for us to look at the issue. >>> >>> Thanks, >>> Yehuda >>> >> >> Certainly, I've pushed it up to github, >> https://github.com/damoxc/linux.git. It's in the branch "testing". >> > > I was able to reproduce the issue. It seems that bcache creates bios > without invoking the merge_bvec callback (which we implement), so we > end up with a request that holds pages that exceed the rbd block > boundaries. The call to bio_split then crashes as it shouldn't have > more than a single page trailing outside. So it's either a problem in > bcache that doesn't call that callback, or an issue with rbd code that > assumes that it'll always be called. A relatively quick workaround for > rbd would be to create a special bio_split function that would do the > required splitting for this case, but I'm not sure whether that would > be the proper solution. If that's a bcache oversight and not an > incorrect assumption I'd rather leave it for bcache. > Thanks a lot for looking. I agree that it should be fixed in the correct place instead of a workaround being implemented. I will try and have a look at the bcache code to see if I can spot anything and whip up a patch. Thanks again, Damien -- 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
