From patchwork Wed Jun 18 02:11:27 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 4372751 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8B38E9F3B4 for ; Wed, 18 Jun 2014 02:12:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 01F6E20179 for ; Wed, 18 Jun 2014 02:12:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 585BD202D1 for ; Wed, 18 Jun 2014 02:12:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933112AbaFRCLb (ORCPT ); Tue, 17 Jun 2014 22:11:31 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:32496 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932987AbaFRCL3 (ORCPT ); Tue, 17 Jun 2014 22:11:29 -0400 Received: from pps.filterd (m0004077 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id s5I28MKH004180; Tue, 17 Jun 2014 19:11:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type; s=facebook; bh=WkSoE6Skl5Ehk+DmBQlf76Kz/eX78K/qVLI/RZbEs9Q=; b=OAo+XbbJitafTsPE3EoZw6zKJBO2gHPlKrrRmx8LjtcXGOYGElIeubhGERoJmX6XkXLr PwqSSyPD0g4xNzkOOIS20xZH5v4b8Gp+4CN5WVxZwyJZO7lHiAZJwN54UqK6jKdBHqmU iY0/OFFobcrlveX4J83z0n5TOl43eBDtn4U= Received: from mail.thefacebook.com (mailwest.thefacebook.com [173.252.71.148]) by mx0b-00082601.pphosted.com with ESMTP id 1mjgv9amh8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jun 2014 19:11:27 -0700 Received: from [10.0.51.190] (192.168.57.29) by mail.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 17 Jun 2014 19:11:25 -0700 Message-ID: <53A0F54F.2060205@fb.com> Date: Tue, 17 Jun 2014 19:11:27 -0700 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Konstantinos Skarlatos , CC: Subject: Re: commit 762380a "block: add notion of a chunk size for request merging" stops io on btrfs References: <53A0B491.1040901@gmail.com> In-Reply-To: <53A0B491.1040901@gmail.com> X-Originating-IP: [192.168.57.29] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-18_01:2014-06-17, 2014-06-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=7.54951656745106e-15 kscore.compositescore=0 circleOfTrustscore=1590.80820394217 compositescore=0.533125042697551 urlsuspect_oldscore=0.533125042697551 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=1996008 rbsscore=0.533125042697551 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406180023 X-FB-Internal: deliver Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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? diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 31e11051f1ba..713f8b62b435 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -920,7 +920,7 @@ static inline unsigned int blk_max_size_offset(struct request_queue *q, sector_t offset) { if (!q->limits.chunk_sectors) - return q->limits.max_hw_sectors; + return q->limits.max_sectors; return q->limits.chunk_sectors - (offset & (q->limits.chunk_sectors - 1));