Received: by 2002:ac0:8c8e:0:0:0:0:0 with SMTP id r14csp119051ima; Wed, 6 Feb 2019 18:29:25 -0800 (PST) X-Google-Smtp-Source: AHgI3IZBvGkhHaacIS2+m4NU/GqI8poZ4KIN55TN8BEJtmBtQJ+tekTblQgjubC63h0xX/X/S9fO X-Received: by 2002:a62:710a:: with SMTP id m10mr13766995pfc.69.1549506565426; Wed, 06 Feb 2019 18:29:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549506565; cv=none; d=google.com; s=arc-20160816; b=vVxRIhGxLs5MvJfo+KZ0CAYGsU1Dr4BKwbH4H/l6mLWw5foZz7ueVhie2793GePhqX rq/0/ygFoHDKhdCZY1ezR/5xCyLjuXa2/5Ity3Emaz74v5YyYvCes6RjnR8rRov/+rvT nTWcAJrrEv7y0YELVgdYPPtPuSFsxFmHfU+3AqexohYJsoBYVo32gVsRgYvZZlZgZV+d B6Z1t2RSXVmQh3FxW/1bitgoDAxFygr+Zl+wN7xi4q8T11kbWKYorTYr4O3RwQFiUb62 B6CiU5ml8CR1AcRdnUPRWQI7Wz+CKWml+7ZbOjq+qBnlF2DEnCzEtOvY6RmBsTs6WKiQ HFjg== 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=0jJfA5UyoLSaWD9nSx6RbqtpxmV26HSowUCzgES3iRI=; b=lVrF0Q/ICDAYDN5ioECKjXJ9/p2EJG6T2mQa6+G30H/REqunb1el4LoPMwuia1kn5a iiSJCsDodPYN1WQawE4fEEJrE0TvfgS1Ov2M4RDVc7gvrmETw5K1a2dyWSdZ1S4InYKH 9FuDiS3hzgpOzyAueu3lxubGk02HuvZ3XCs6t1cBTfqNdqOa0Ap+pymECp8vt8B/g6PV SRx2vV8vRrK1jolDCRsAmD/t3lbLBgP0aSycbhmVh7dfHwEV4+WVCpo2DvRzT+JzD6dy kzRSvs3b2F0KInF7OOkgtxqb7RywkxVDZrlBJRFd5KM4osOjn1/Law04OJ6WM6SajpUE 5SKQ== 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 d17si3175892pgp.274.2019.02.06.18.29.09; Wed, 06 Feb 2019 18:29:25 -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 S1726830AbfBGC1C (ORCPT + 99 others); Wed, 6 Feb 2019 21:27:02 -0500 Received: from ipmail03.adl2.internode.on.net ([150.101.137.141]:5890 "EHLO ipmail03.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726266AbfBGC1B (ORCPT ); Wed, 6 Feb 2019 21:27:01 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail03.adl2.internode.on.net with ESMTP; 07 Feb 2019 12:56:58 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1grZOz-0003dZ-OI; Thu, 07 Feb 2019 13:26:57 +1100 Date: Thu, 7 Feb 2019 13:26:57 +1100 From: Dave Chinner To: Andre Noll Cc: Nix , linux-bcache@vger.kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Coly Li Subject: Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all? Message-ID: <20190207022657.GI14116@dastard> References: <87h8dgefee.fsf@esperi.org.uk> <20190206234328.GH14116@dastard> <20190207002425.GX24140@tuebingen.mpg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190207002425.GX24140@tuebingen.mpg.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 07, 2019 at 01:24:25AM +0100, 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? Yes, that change is just broken. From include/linux/blk_types.h: __REQ_META, /* metadata io request */ __REQ_PRIO, /* boost priority in cfq */ i.e. REQ_META means that it is a metadata request, REQ_PRIO means it is a "high priority" request. Two completely different things, often combined, but not interchangeable. So, yeah, that needs to be reverted if you want bcache to function properly for metadata caching. Cheers, Dave. -- Dave Chinner david@fromorbit.com