Re: Crash when trying to mount ext4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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,
>> 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,
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]