From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3A3E168DF for ; Tue, 19 Dec 2023 12:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id CA05F68C4E; Tue, 19 Dec 2023 13:19:11 +0100 (CET) Date: Tue, 19 Dec 2023 13:19:11 +0100 From: Christoph Hellwig To: Gao Xiang Cc: Christoph Hellwig , Chris Mason , Josef Bacik , David Sterba , "linux-btrfs@vger.kernel.org" , Christian Brauner , Eric Biggers , Johannes Thumshirn Subject: Re: [PATCH 5/5] btrfs: use the super_block as holder when mounting file systems Message-ID: <20231219121911.GA21959@lst.de> References: <20231218044933.706042-1-hch@lst.de> <20231218044933.706042-6-hch@lst.de> <04e599b9-5d6d-4ac0-bf74-da9bedfb585f@wdc.com> <20231218150234.GB19041@lst.de> <5dc7ecdd-8bd3-4016-b8da-49ff306bcd3c@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5dc7ecdd-8bd3-4016-b8da-49ff306bcd3c@linux.alibaba.com> User-Agent: Mutt/1.5.17 (2007-11-01) On Tue, Dec 19, 2023 at 01:33:54PM +0800, Gao Xiang wrote: >>> ext4, f2fs and xfs use the super_block, erofs uses 'sb->s_type' as well >>> here. Reiser uses the journal and so does jfs. So while these two might >>> not be the best examples in the world, all other is an exaggeration. >> >> As of 6.8-rc every file system but btrfs should be using the superblock. > > Just saw this by chance. Currently EROFS uses 'sb->s_type' to refer > external binary source devices (blobs) across different mounts. Since > these devices are treated readonly so such external sources can be > shared between mounts as some shared data layer. Makes sense for that somewhat unusual use case. Note that this means you can't really use blk_holder_ops based notifications from the block driver, but for read-only devices that's not all that important anyway.