From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 AC7503947AE for ; Wed, 26 Aug 2026 06:12:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787724731; cv=none; b=ZgILvji+cak4LoeRO/+rgNpEGjttwLkdgVjYlOdNx4bxG0v6RNldPgZOy81W3WUrb/1vJaOODevCKVE+t650QtbmcUuKriGgwvo0b91YdWFkmeLA5z1wRjtFfXKT7yo0BpRggR7IEMtYpNpfBdSG0qmIae1nu/eMZExjH9yrvow= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787724731; c=relaxed/simple; bh=t1r8AU34b8zyh5h1G4Uir/zsvA7EHfsalp3di0JQtt8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CTlNC6xWUnRf3PQr7zS/wkydklKPxVcIuE7I045MfCvToxOaHlvO1XMsCFCVK7gj7jvHROLrQW7YkCRBtL7txU+ws+PH4mY/Mkw8bZ/M1HO5sOSD4BvvxuZP2zaEX1nE183loXu6imUhfC8I7jgdS1um+fJDLfM/RrKZg59bfJg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IyzB0WfR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IyzB0WfR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D91C1F000E9; Wed, 26 Aug 2026 06:12:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787724730; bh=wOXH9hORSWj/yUkhv682PeI+oAkc2FTnLriQfuLGgF4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IyzB0WfR7qLAdReauYSafBClrKz8zlltbJD9kX/1D1ku8AdguWAbT8o8M9N02yrCA lxDrvB59EL7+UHqrtVnomcfn7iDv7bGSLt3OsQSYcjwtNVM+LUWIO7vZs2hgxg6Xgz NkTu4ID2g1UmMSJNwO48gJz7HnWQKisYTpNQLIxmC/OWdSUjan0eGQd0uRKSMY4RR7 aNLMoeYFxgEB0CL4CYT7tUGjNqClJqq+RBxmr3xfZ+fp88nE7frNQui/V4bUyjpkRX 3fGjL5DPCxBNmcwRSpn7IeLJe6+tbr3HkB/bwDCmP0CNs+AzMSIP0lD7Dj7mOm/HcE aaI/50YzpjyAA== Date: Wed, 26 Aug 2026 14:12:02 +0800 From: Gao Xiang To: Christoph Hellwig Cc: Gao Xiang , linux-erofs@lists.ozlabs.org, LKML , Chao Yu Subject: Re: [PATCH v2] erofs: use dedicated meta inodes for file-backed mounts Message-ID: Mail-Followup-To: Christoph Hellwig , Gao Xiang , linux-erofs@lists.ozlabs.org, LKML , Chao Yu References: <20260811080852.29418-1-xiang@kernel.org> <20260811090717.29787-1-xiang@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Hi Christoph, On Tue, Aug 25, 2026 at 09:44:03PM -0700, Christoph Hellwig wrote: > On Thu, Aug 20, 2026 at 09:40:46PM +0800, Gao Xiang wrote: > > Hi Christoph, > > > > On Tue, Aug 18, 2026 at 10:55:47PM -0700, Christoph Hellwig wrote: > > > On Tue, Aug 11, 2026 at 05:07:17PM +0800, Gao Xiang wrote: > > > > access on file-backed mounts (although I still don't think it is > > > > necessary due to the EROFS immutable model). As the result, metadata > > > > cache won't use the page cache of backing inodes anymore. > > > > > > > > The "managed cache" was originally used to cache physical compressed > > > > data according to the current cache strategy and I/O patterns; since > > > > file-backed mounts also need to access physical data for metadata > > > > access, it's natural to reuse the managed cache for this too, providing > > > > a unique inode for all physical data access. > > > > > > This look sane. Any reason to not use the meta inode unconditionally > > > to simplify the code? > > > > I guess you meant avoid using bd_inode page cache? > > > Yes. > > > I'm not sure if it simplifies a lot, also like fadvise(WILLNEED) to blkdev > > can perform to bd_inode too so I think it can still have some benefits. > > This is actually an artefact of why using the bdev page cache is a bad > idea, because it opens your metadata cache up to external modification > and side channel attacks. See my reply to Christian before: https://lore.kernel.org/r/95a5fc3a-4259-44a7-bb72-8ff35a49a26f@linux.alibaba.com EROFS is unlike generic writable filesystems which need to consider writing to the disk and keep various cache (extent cache, ...) and complex metadata relationship. EROFS itself is only designed for archive use cases (like tar/zip), and it never changes its data and metadata itself at runtime, and it intentionally only uses the physical view as the unique metadata cache (never duplicate a different form of in-memory metadata cache) by design. For unexpected external modification, it generally behaves undefined (nevertheless, the physical device can be modified in various ways). In short, our implementation is always designed to harden and tolerate this so it won't cause severe in-memory <-> on-disk or on-disk <-> on-disk inconsistency. You could doubt that, but here I claim again that one of EROFS main ondisk/runtime design goals (which is very unlike to other generic filesystems, and that is one of EROFS's main value), for human-made random implementation bugs, we will fix them all after reported since the implementation bug cannot be totally avoidable from an engineering perspective (unless the implementation is totally auto code generated.) For side channel attack, the Linux page cache model is always vulnerable to that, and I really think it's a trade-off (for shared kernel apporaches, cache side channel attack is unavoidable and no need to avoid; if you need a strongest protection, you should use isolated kernels or seperate VM instead.) We could switch to use per-fs metadata cache, but in that way, we have to develop a new way to warm up the cache instead, I guess in that way it will be much like switched into an EROFS-specific ioctl interface instead since fadvise no longer works. > > > I think bd_inode page cache can be used for filesystems so maybe leave it > > as-is for now, or maybe a follow-up work if it's really needed. > > That's how it has historically been done. We generally try to avoid > it for newer designs. TR;DR: I will switch later when I find another slot, but it should just based on a fact is that bd_inode page cache is deprecated in the long term simply. Thanks, Gao Xiang > >