Received: by 2002:ac0:8c8e:0:0:0:0:0 with SMTP id r14csp119332ima; Wed, 6 Feb 2019 18:29:49 -0800 (PST) X-Google-Smtp-Source: AHgI3IakMBmQNq86N1WcDm9dnyJmKnGWBoIKigP1YO/1/PWFFNG/zCmik9fztkNOkbsKRjurq7eP X-Received: by 2002:a63:197:: with SMTP id 145mr4600138pgb.40.1549506589473; Wed, 06 Feb 2019 18:29:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549506589; cv=none; d=google.com; s=arc-20160816; b=DOvkmy4EVmiVDA+HVTBZkOlkpINHtrM4nTKoalyUWK+xEF2WUZL//qcQYjB8Un596G ljot8y9lwh1kEIiiMIl0n8Y4Yn1Sz//7c8f4RwVe829e62q/lhPJ3qDnp/P5Cm+O3qOb 84CPU3k5Qz2hc+bb2GemDqys6+IjsfH1FK/Rhf3Lh5qBuPW37LLp9HHJYkN/HxXrZY3E m8u9SIVoiATk8rp8a8TVWbm9ds5k4pGVXKOhBWBV5B7+ZUJR9yFP9Q1GoDGYjsywHxnI KSRJY+DkGYa0hQ++N6OSHMg/GXVZKwiquNbMyZnBVkhlIgfnp8gTVc2hasCModu3Z2OX YcTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:openpgp:from:references:cc:to:subject; bh=ZlJksEYdThEzUsF0PALNzIvwpmjhMhA4jaRJH8HfDSA=; b=HytDF7kWtqsDJwQ++pG/rsqQwR952JBdTuLKb1p9Gf7WjiG83Sno8c1mXynhBrxviv 7G8C9NAC8N3BcFC9N7Q8Qqcn1GqU3Kzy298Pl6okIUyQQkEpFRcd3f0vhDPBEf6xMSW7 Pp4L4UySXDX47sSYPmTqHQ3FnG8qIauHoFmpS/cM+ecxfou63FkJDoyQLgsZZF6l3HLg EfhRiSIQrAfU7HDeToRudev1nLfi6ji1y24BNt9IhgORitQMjZrA5mwReEtKHOhGoFzU AOx7gzqxWkbRyRGjSK7oBl5t93PKZXQNdinK0KRUv53y5sDrzNexHEsFyCi8s6Yg4SvK UEWg== 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 w24si7391110plp.304.2019.02.06.18.29.34; Wed, 06 Feb 2019 18:29:49 -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 S1726914AbfBGC1W (ORCPT + 99 others); Wed, 6 Feb 2019 21:27:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:44436 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726266AbfBGC1W (ORCPT ); Wed, 6 Feb 2019 21:27:22 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7A602AEBB; Thu, 7 Feb 2019 02:27:20 +0000 (UTC) Subject: Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all? To: Andre Noll , Dave Chinner Cc: Nix , linux-bcache@vger.kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , axboe@kernel.dk References: <87h8dgefee.fsf@esperi.org.uk> <20190206234328.GH14116@dastard> <20190207002425.GX24140@tuebingen.mpg.de> From: Coly Li Openpgp: preference=signencrypt Organization: SUSE Labs Message-ID: Date: Thu, 7 Feb 2019 10:27:11 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190207002425.GX24140@tuebingen.mpg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/2/7 8:24 上午, Andre Noll wrote: > On Thu, Feb 07, 10:43, Dave Chinner wrote >> File data readahead: REQ_RAHEAD Metadata readahead: REQ_META | >> REQ_RAHEAD >> >> drivers/md/bcache/request.c::check_should_bypass(): >> >> /* * Flag for bypass if the IO is for read-ahead or background, * >> unless the read-ahead request is for metadata (eg, for gfs2). */ >> if (bio->bi_opf & (REQ_RAHEAD|REQ_BACKGROUND) && !(bio->bi_opf & >> REQ_PRIO)) goto skip; >> >> bcache needs fixing - it thinks REQ_PRIO means metadata IO. >> That's wrong - REQ_META means it's metadata IO, and so this is a >> bcache bug. > > Do you think 752f66a75abad is bad (ha!) and should be reverted? Hi Dave and Andre, Correct me if I am wrong: REQ_META is used for blktrace to tag metadata IO, and REQ_PRIO is used for block layer to handle metadata IO. I discussed with Christoph Hellwig about this topic quite long time ago, and got the above conclusion. If different file system handles metadata flags in unified ways, it is OK to me to change the code to: !(bio->bi_opf & (REQ_META |REQ_PRIO)). Thanks in advance. -- Coly Li