From: Matthew Wilcox <willy@infradead.org>
To: Cong Wang <cwang@multikernel.io>
Cc: Gao Xiang <hsiangkao@linux.alibaba.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Cong Wang <xiyou.wangcong@gmail.com>,
multikernel@lists.linux.dev
Subject: Re: [ANNOUNCE] DAXFS: A zero-copy, dmabuf-friendly filesystem for shared memory
Date: Mon, 26 Jan 2026 20:40:50 +0000 [thread overview]
Message-ID: <aXfRUlu61nrIqCZS@casper.infradead.org> (raw)
In-Reply-To: <CAGHCLaSe8g+BQ5OtRv0_Ft3o-G0gR4oVSOW0DtdsQJdwuJsDCA@mail.gmail.com>
On Mon, Jan 26, 2026 at 11:48:20AM -0800, Cong Wang wrote:
> Specifically for this scenario, struct inode is not compatible. This
> could rule out a lot of existing filesystems, except read-only ones.
I don't think you understand that there's a difference between *on disk*
inode and *in core* inode. Compare and contrast struct ext2_inode and
struct inode.
> Now back to EROFS, it is still based on a block device, which
> itself can't be shared among different kernels. ramdax is actually
> a perfect example here, its label_area can't be shared among
> different kernels.
>
> Let's take one step back: even if we really could share a device
> with multiple kernels, it still could not share the memory footprint,
> with DAX + EROFS, we would still get:
> 1) Each kernel creates its own DAX mappings
> 2) And faults pages independently
>
> There is no cross-kernel page sharing accounting.
>
> I hope this makes sense.
No, it doesn't. I'm not suggesting that you use erofs unchanged, I'm
suggesting that you modify erofs to support your needs.
next prev parent reply other threads:[~2026-01-26 20:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGHCLaREA4xzP7CkJrpqu4C=PKw_3GppOUPWZKn0Fxom_3Z9Qw@mail.gmail.com>
[not found] ` <55e3d9f6-50d2-48c0-b7e3-fb1c144cf3e8@linux.alibaba.com>
2026-01-26 17:38 ` [ANNOUNCE] DAXFS: A zero-copy, dmabuf-friendly filesystem for shared memory Cong Wang
2026-01-26 19:16 ` Matthew Wilcox
2026-01-26 19:48 ` Cong Wang
2026-01-26 20:13 ` Gao Xiang
2026-01-26 20:40 ` Matthew Wilcox [this message]
2026-01-27 0:02 ` Cong Wang
2026-01-27 0:55 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXfRUlu61nrIqCZS@casper.infradead.org \
--to=willy@infradead.org \
--cc=cwang@multikernel.io \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=multikernel@lists.linux.dev \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox