From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 F0F782E414; Thu, 22 Jan 2026 08:41:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769071267; cv=none; b=MolxB9bRUrxOSrDJwNB6SCnhWjI2BVGaZ9NfRZzmDUy2VM25+2sTOL6A8AHKbZBjDOf3RTyAnUZdq7z0unAINL0beEn9CAUpHh2iv4UlygHpAeQOpVGwVP+UwDV2SpCKFNXQOPjLUZlW+MCuEYeWCbgoTNQkDPgbiZdTMyqx0ew= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769071267; c=relaxed/simple; bh=tP9is0/H7vqHiwvdJ5kbuXSDgP/FdiFh7Ii0X89G5BA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=vDuJtja00EhSmgeyBy9AWNX2BVG0mWun506FfGhrrdhYBcFG38W4QT392NoT8eD2Iz4qNUA8GxRDjFpc1qR8MM9nbQ69x3WUaQRqpDmKuf4tQAjWrKb8m9V8HRMXIr4QEgPgPqBRPTeoSLINPgnALIaucTiCKYGI7d5Gyy93b0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=WFcaReBh; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="WFcaReBh" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1769071259; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=gJSzOWSqPre+2yZ8/cQcaEgo/1k5YiDdjzLGF45ntF8=; b=WFcaReBhDlm2rnq4OeLezvOIKLuIn2sVr+qaxj6AYFkxHip3wogyyghyTLZYU9cwylWwMmEtb9eQtg5BRne7zj7tg9yYeTjXEWs/HkBR2ZtkWoBkrkfvdi3p6MVNnP5ST1N3gj1/IFKDsToK2lHqV3I2gStAFzE+VspfFSOgOyw= Received: from 30.221.131.199(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WxbgvIV_1769071257 cluster:ay36) by smtp.aliyun-inc.com; Thu, 22 Jan 2026 16:40:58 +0800 Message-ID: Date: Thu, 22 Jan 2026 16:40:56 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature To: Christoph Hellwig Cc: Hongbo Li , chao@kernel.org, djwong@kernel.org, amir73il@gmail.com, linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, Linus Torvalds , Christian Brauner , oliver.yang@linux.alibaba.com References: <20260119072932.GB2562@lst.de> <8e30bc4b-c97f-4ab2-a7ce-27f399ae7462@linux.alibaba.com> <20260119083251.GA5257@lst.de> <20260119092220.GA9140@lst.de> <73f2c243-e029-4f95-aa8e-285c7affacac@linux.alibaba.com> <50db56b8-4cf9-4d62-b242-c982a260a330@linux.alibaba.com> <20260120065242.GA3436@lst.de> <5892c7bb-f06e-45d7-ad84-99837788e5ab@linux.alibaba.com> <20260122083310.GA27928@lst.de> From: Gao Xiang In-Reply-To: <20260122083310.GA27928@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/1/22 16:33, Christoph Hellwig wrote: > On Tue, Jan 20, 2026 at 03:19:21PM +0800, Gao Xiang wrote: >>> It will be very hard to change unless we move to physical indexing of >>> the page cache, which has all kinds of downside.s >> >> I'm not sure if it's really needed: I think the final >> folio adaption plan is that folio can be dynamic >> allocated? then why not keep multiple folios for a >> physical memory, since folios are not order-0 anymore. > > Having multiple folios for the same piece of memory can't work, > at we'd have unsynchronized state. Why not just left unsynchronized state in a unique way, but just left mapping + indexing seperated. Anyway, that is just a wild thought, I will not dig into that. > >> Using physical indexing sounds really inflexible on my >> side, and it can be even regarded as a regression for me. > > I'm absolutely not arguing for that.. > >>>> So that let's face the reality: this feature introduces >>>> on-disk xattrs called "fingerprints." --- Since they're >>>> just xattrs, the EROFS on-disk format remains unchanged. >>> >>> I think the concept of using a backing file of some sort for the shared >>> pagecache (which I have no problem with at all), vs the imprecise >> >> In that way (actually Jingbo worked that approach in 2023), >> we have to keep the shared data physically contiguous and >> even uncompressed, which cannot work for most cases. > > Why does that matter? Sorry then, I think I don't get the point, but we really need this for the complete page cache sharing on the single physical machine. > >> On the other side, I do think `fingerprint` from design >> is much like persistent NFS file handles in some aspect >> (but I don't want to equal to that concept, but very >> similar) for a single trusted domain, we should have to >> deal with multiple filesystem sources and mark in a >> unique way in a domain. > > I don't really thing they are similar in any way. Why they are not similiar, you still need persistent IDs in inodes for multiple fses, if there are a content-addressable immutable filesystems working in inodes, they could just use inode hashs as file handles instead of inode numbers + generations. Thanks, Gao Xiang