Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756354AbaFRHVV (ORCPT ); Wed, 18 Jun 2014 03:21:21 -0400 Received: from mail-we0-f181.google.com ([74.125.82.181]:61413 "EHLO mail-we0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751576AbaFRHVT (ORCPT ); Wed, 18 Jun 2014 03:21:19 -0400 Message-ID: <53A13DE9.4020001@gmail.com> Date: Wed, 18 Jun 2014 10:21:13 +0300 From: Konstantinos Skarlatos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Thunderbird/32.0a2 MIME-Version: 1.0 To: Jens Axboe , linux-kernel@vger.kernel.org CC: linux-btrfs@vger.kernel.org Subject: Re: commit 762380a "block: add notion of a chunk size for request merging" stops io on btrfs References: <53A0B491.1040901@gmail.com> <53A0F54F.2060205@fb.com> In-Reply-To: <53A0F54F.2060205@fb.com> Content-Type: text/plain; charset=windows-1253; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> 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 > > 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. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/