From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8212DC87FDE for ; Fri, 9 Jun 2023 04:20:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237095AbjFIEUc (ORCPT ); Fri, 9 Jun 2023 00:20:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbjFIEUb (ORCPT ); Fri, 9 Jun 2023 00:20:31 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 889E11A1; Thu, 8 Jun 2023 21:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Bf0Imcmrff8IiflvMMZwKHn+EPzovpKROa1e5HANUoM=; b=nue2TtmTamk9kJkszgPEGMpwte lhHnwHuuxogMyeD0BQGtvyzl9mYliO0ISA7i4oG4Eg26b4hQtdcmoQUUCz1Am7UpYm5S66D9LPRcN 5/Uy48E/9SEM/MtyvLfTqnHleWvImTBEULArcgIPOro0eI0uH/g8x7xGkNc5T8q6fWD0qd8OLdc97 ElapA2f8xr6rBQxc1qCGSsaN+zI29pxUboyrxPIpW2N4x9lZz6fqH1w//lOov0U+KiyyY8W/8QHLC OQ3XqldDQHaU2nU4fWrkx05LA8/dDA0VYONM/hMe7D6Vat+V5OW3FTF5aiXDBdyIfisWlNbvL2C/X YUBAuQVw==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1q7Tbj-00Ba1H-02; Fri, 09 Jun 2023 04:20:15 +0000 Date: Thu, 8 Jun 2023 21:20:14 -0700 From: Christoph Hellwig To: Luis Chamberlain Cc: Christoph Hellwig , Matthew Wilcox , djwong@kernel.org, dchinner@redhat.com, kbusch@kernel.org, hare@suse.de, ritesh.list@gmail.com, rgoldwyn@suse.com, jack@suse.cz, patches@lists.linux.dev, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, p.raghav@samsung.com, da.gomez@samsung.com, rohan.puri@samsung.com, rpuri.linux@gmail.com, corbet@lwn.net, jake@lwn.net Subject: Re: [RFC 4/4] bdev: extend bdev inode with it's own super_block Message-ID: References: <20230608032404.1887046-1-mcgrof@kernel.org> <20230608032404.1887046-5-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Jun 08, 2023 at 10:45:10AM -0700, Luis Chamberlain wrote: > > > and then considering only two superblocks instead of having a list of > > > all bdevs? > > > > Or why the heck we would even do this to start with? > > That's what I gathered you suggested at LSFMM on hallway talk. No. I explained you that sharing the superblock or has absolutely no effct on the aops after you wanted to it. I said it might be nice for other reasons to have a sb per gendisk. > > iomap has absolutely nothing to do with superblocks. > > > > Now maybe it might make sense to have a superblock per gendisk just > > to remove all the weird special casing for the bdev inode in the > > writeback code. But that's something entirely different than this > > patch. > > The goal behind this is to allow block devices to have its bdev cache > use iomap, right now now we show-horn in the buffer-head aops if we > have to build buffer-heads. > > If this sort of approach is not desirable, let me know what alternative > you would prefer to see, because clearly, I must not have understood > your suggestion. Again, every non-trivial file system right now has more than one set of aops per superblock. I'm not sure what problem you are trying to solve here.