Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2456467imu; Mon, 19 Nov 2018 00:26:28 -0800 (PST) X-Google-Smtp-Source: AJdET5dEJAmdP23NfZ1VFYrZORpilm75uw0LCj756Bgw8YbsBP+VHCGZ1PurGoxKTEFz1D4OT6Up X-Received: by 2002:a63:495b:: with SMTP id y27mr19233602pgk.32.1542615988660; Mon, 19 Nov 2018 00:26:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542615988; cv=none; d=google.com; s=arc-20160816; b=NFPgFiB4hzUE5hwrohqcWOLYhjHo7DS2PeT3wxCznT9sjC6Grajb943W0kqldt+w2i 8KUSvjlVZnlVj8fTaduxr0jb6l/zWxe0ts4myZyfb5J0/rkAy/z3ljyLvKI12UxlN6BO vL3zNSgYDOB3xdrKDBeQUtu2klK0ZlSbAdtusEB9uQXe4yjvrR3XTLha3ZgkojoovVo6 NfwDyzwHf7BGoshskn3DaAcGU7SPPUCJ3awEtuHmt0KM1NB+fpwa1Ofa5ZeNaH9j9yFL DtEfzbuWrjhCt6VOL64eSDVikT3xgQeEjNqgRiurTA0N8Jh4BdXfzCUTnGb2EAQo+yvC Jxyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=okLtDlEi+tq5ceDq8M+1r1bDc2HCLbRag7S9aEfzc6o=; b=Ksc3rz3ghjpwIxqYtgOOdN9b7NfNTNhk4h08Z8uaRCdKQhh7N00u16+Ne//LdpE10A xao6B9vVkt+lnIXuCxBfVsd0Gn9hN6WxcEELFYOfCzMRmkjRL4IUcTvHjGVVcKN44Xed LAmSQCHMjizdPK7raMBdU86reBGcRkcS8j6ciNUoH2ykzaLJlgfzyIoltR5fD8ZMqaf+ 5lPnbJ8t7Ie4EfLsFspfkT6R7DWEhGJVqM+83Kw2nnUsRUfFDrTpmYGTbgdzWX2XQZab h3jCcCZ+99NVcwW2WYXJ0FmFIcmafNq+gWOjWaA4cvWDMIzyFYcoj+E39TQxH3VLjaG8 VFoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t74si28345673pgc.150.2018.11.19.00.26.12; Mon, 19 Nov 2018 00:26:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727135AbeKSSrM (ORCPT + 99 others); Mon, 19 Nov 2018 13:47:12 -0500 Received: from verein.lst.de ([213.95.11.211]:36660 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726784AbeKSSrL (ORCPT ); Mon, 19 Nov 2018 13:47:11 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 8B0BF68B02; Mon, 19 Nov 2018 09:24:14 +0100 (CET) Date: Mon, 19 Nov 2018 09:24:14 +0100 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, Shaohua Li , linux-raid@vger.kernel.org, linux-erofs@lists.ozlabs.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , Theodore Ts'o , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com, Chandan Rajendra Subject: Re: [PATCH V10 08/19] btrfs: move bio_pages_all() to btrfs Message-ID: <20181119082414.GA10678@lst.de> References: <20181115085306.9910-1-ming.lei@redhat.com> <20181115085306.9910-9-ming.lei@redhat.com> <20181116133845.GG3165@lst.de> <20181119081922.GB16736@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181119081922.GB16736@ming.t460p> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 19, 2018 at 04:19:24PM +0800, Ming Lei wrote: > On Fri, Nov 16, 2018 at 02:38:45PM +0100, Christoph Hellwig wrote: > > On Thu, Nov 15, 2018 at 04:52:55PM +0800, Ming Lei wrote: > > > BTRFS is the only user of this helper, so move this helper into > > > BTRFS, and implement it via bio_for_each_segment_all(), since > > > bio->bi_vcnt may not equal to number of pages after multipage bvec > > > is enabled. > > > > btrfs only uses the value to check if it is larger than 1. No amount > > of multipage bio merging should ever make bi_vcnt go from 0 to 1 or > > vice versa. > > Could you explain a bit why? > > Suppose 2 physically continuous pages are added to this bio, .bi_vcnt > can be 1 in case of multi-page bvec, but it is 2 in case of single-page > bvec. True, I did think of 0 vs 1. The magic here in btrfs still doesn't make much sense. The comments down in btrfs_check_repairable talk about sectors, so it might be a leftover from the blocksize == PAGE_SIZE days (assuming those patches actually got merged). I'd like to have the btrfs folks chime in, but in the end we should probably check if the bio was larger than a single sector here.