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. Yehuda -- 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
