Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 24 Jul 2020 17:22:21 -0700
From:   Vito Caputo <vcaputo@pengaru.com>
To:     linux-kernel <linux-kernel@vger.kernel.org>
Cc:     linux-fsdevel@vger.kernel.org, Dave Chinner <david@fromorbit.com>
Subject: [QUESTION] Sharing a `struct page` across multiple `struct
 address_space` instances
Message-ID: <20200725002221.dszdahfhqrbz43cz@shells.gnugeneration.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello folks,

I've been poking around the shmem/tmpfs code with an eye towards
adding reflink support to tmpfs.

Prior to looking at the code, conceptually I was envisioning the pages
in the reflink source inode's address_space would simply get their
refcounts bumped as they were added to the dest inode's address_space,
with some CoW flag set to prevent writes.

But there seems to be a fundamental assumption that a `struct page`
would only belong to a single `struct address_space` at a time, as it
has single `mapping` and `index` members for reverse mapping the page
to its address_space.

Am I completely lost here or does it really look like a rather
invasive modification to support this feature?

I have vague memories of Dave Chinner mentioning work towards sharing
pages across address spaces in the interests of getting reflink copies
more competitive with overlayfs in terms of page cache utilization.

Dave did you ever end up going down this path?

Regards,
Vito Caputo