Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3209937pxb; Mon, 18 Oct 2021 10:19:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzR86RKW1DxWJggfJkhMt6b5q6zGEWNfDQV4IJpCY1AWlY+79EJG02PQU7h5apfLs54jcYX X-Received: by 2002:a05:6a00:13a5:b0:44c:ae90:8603 with SMTP id t37-20020a056a0013a500b0044cae908603mr29698891pfg.17.1634577547859; Mon, 18 Oct 2021 10:19:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634577547; cv=none; d=google.com; s=arc-20160816; b=U3DtJ7xrLmrUG8/wlfhVW/oLmPvjGhefGKin5CImtWwMFYMahn6ojsbulzzapyJFMU ZMStFHgNJ7wOwFXmd8Swh5M2QB5G6zW6bjJJdERwQi/gpjEpjrgQ7JAN9HPlvqifW0Vc WRCF5xeRch6De8IABbT8ZOq0hS+ywegMqJKnhxqWnMBGA9389yYHEHT5Jc3xVqEsPWxn mR4DLrSCN+2I2U0GBZ/nxC5S0RgwPMM4C06IE/qhFnGH1wHaVUVCncKVmoPmsVWBCyg+ 2UduFRKjXjUbURqVbF5c34H2PDrE9F0wuJucjK2Kizgajaz/LRqKaLSS1sHuCmYDpTWo wydw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=D10j3teew8aQinu65T/pFXaf/R5DE41yS/lUYzZTpOs=; b=SPYyvEwgw0xWppJVvEVo0An9R8TZPr4rMKwKlkx0y5WXK8a48AZ6VqQm0SMNJ8WQrm 6s5kUulVxONiO/bJ5RrTm2cF8IeM0xB6aDa2r3s09JjuzweCGQi4tzSz85Ls73m65KYn WTZh2wWRwW+Y0Vkt80KpMxG7tPV5tI5su+TYu3HbSPvyY4HpJ2AESte8RZqKCBmiBquX 2svGy8E6u0RkfPQWX9TPyp4k5CDHnkydObAbaLfSoAX7JG+t7RfEilHuKUVfDhRaNgFk hRTQ7nS8Po/zSNV7SHBKD10sLjGHqboM8wAjhqpPhIy/uNEbsEgpsTUq7lmB3KmRX1FH I2jA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o11si2739844pfu.316.2021.10.18.10.18.54; Mon, 18 Oct 2021 10:19:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233960AbhJRRVB (ORCPT + 99 others); Mon, 18 Oct 2021 13:21:01 -0400 Received: from verein.lst.de ([213.95.11.211]:35226 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233239AbhJRRVA (ORCPT ); Mon, 18 Oct 2021 13:21:00 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id E094C68AFE; Mon, 18 Oct 2021 19:18:43 +0200 (CEST) Date: Mon, 18 Oct 2021 19:18:43 +0200 From: Christoph Hellwig To: Jens Axboe Cc: Christoph Hellwig , Coly Li , Mike Snitzer , Song Liu , David Sterba , Josef Bacik , Theodore Ts'o , OGAWA Hirofumi , Dave Kleikamp , Ryusuke Konishi , Anton Altaparmakov , Konstantin Komarov , Kees Cook , Phillip Lougher , Jan Kara , linux-block@vger.kernel.org, dm-devel@redhat.com, drbd-dev@lists.linbit.com, linux-bcache@vger.kernel.org, linux-raid@vger.kernel.org, linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, jfs-discussion@lists.sourceforge.net, linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ntfs3@lists.linux.dev, reiserfs-devel@vger.kernel.org Subject: Re: don't use ->bd_inode to access the block device size v3 Message-ID: <20211018171843.GA3338@lst.de> References: <20211018101130.1838532-1-hch@lst.de> <4a8c3a39-9cd3-5b2f-6d0f-a16e689755e6@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a8c3a39-9cd3-5b2f-6d0f-a16e689755e6@kernel.dk> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, Oct 18, 2021 at 11:16:08AM -0600, Jens Axboe wrote: > This looks good to me. Followup question, as it's related - I've got a > hacky patch that caches the inode size in the bdev: > > https://git.kernel.dk/cgit/linux-block/commit/?h=perf-wip&id=c754951eb7193258c35a574bd1ccccb7c4946ee4 > > so we don't have to dip into the inode itself for the fast path. While > it's obviously not something being proposed for inclusion right now, is > there a world in which we can make something like that work? There's just two places that update i_size for block devices: set_capacity and bdev_set_nr_sectors. So you just need to update bd_nr_sectors there and you're done.