Re: commit 762380a "block: add notion of a chunk size for request merging" stops io on btrfs

[Jens Axboe]

On 2014-06-18 00:21, Konstantinos Skarlatos wrote:
> On 18/6/2014 5:11 πμ, Jens Axboe wrote:
> > On 2014-06-17 14:35, Konstantinos Skarlatos wrote:
> > > Hi all,
> > > with 3.16-rc1  rsync stops writing to my btrfs filesystem and stays at a
> > > D+ state.
> > > git bisect showed that the problematic commit is:
> > >
> > > 762380ad9322951cea4ce9d24864265f9c66a916 is the first bad commit
> > > commit 762380ad9322951cea4ce9d24864265f9c66a916
> > > Author: Jens Axboe <axboe@xxxxxx>
> > > Date:   Thu Jun 5 13:38:39 2014 -0600
> > >
> > >      block: add notion of a chunk size for request merging
> > >
> > >      Some drivers have different limits on what size a request should
> > >      optimally be, depending on the offset of the request. Similar to
> > >      dividing a device into chunks. Add a setting that allows the driver
> > >      to inform the block layer of such a chunk size. The block layer
> > > will
> > >      then prevent merging across the chunks.
> > >
> > >      This is needed to optimally support NVMe with a non-zero stripe
> > > size.
> > >
> > >      Signed-off-by: Jens Axboe <axboe@xxxxxx>
> >
> > That's odd, should not have any effect since nobody enables stripe
> > sizes in the kernel. I'll double check, perhaps it's not always being
> > cleared.
> >
> > Ah wait, does the attached help?
>
> Yes, it works! I recompiled at commit
> 762380ad9322951cea4ce9d24864265f9c66a916 with your patch and it looks
> ok. Rebooted back to the unpatched kernel and the bug showed up again
> immediately.
>
> The funny thing is that the problem only showed on my (multi-disk) btrfs
> filesystem. / which is on ext4 seems to work fine.

Probably because the multi-disk setup doesn't have hw_sectors set, I'm 
guessing. But great, I'll get this upstream asap. Thanks for testing!

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/