From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [GIT PULL 2/4] fuse4fs: run servers as a contained service
Date: Tue, 22 Sep 2026 21:54:45 -0700 [thread overview]
Message-ID: <20260923045445.GY6283@frogsfrogsfrogs> (raw)
In-Reply-To: <arL6faQ3Nq8MJHvg@mit.edu>
On Tue, Sep 22, 2026 at 08:46:50PM -0400, Theodore Tso wrote:
> On Fri, Sep 11, 2026 at 11:41:59PM -0500, Darrick J. Wong wrote:
> > libext2fs: fix MMP code to work with unixfd IO manager
>
> So a quick comment about this:
>
> * It's also broken if the unixfd IO manager was passed a string with a
> * file descriptor number instead of a /dev/fd/XX path, but the
> * internet thinks there are no users of the manager outside of Google.
>
> Specifically, it's not Google, it's "Android", and it's used for a
> similar reason as unprivileged containerized use case --- namely
> security. In the case of Android, a volume server daemon passes the
> file descriptor over a unix domain socket so that the fsck can be run
> on the file system without giving it wider access to the system. The
> difference is that Android didn't care about MMP, so they never tested
> or cared about that particular corner case.
>
> Honestly, MMP only really makes sense when you have specialized
> hardware where the storage device can be simultaneously connected to
> two host servers, and you want to do block device level failover
> between devices. This doesn't really make sense for Android or for
> the containerized fuse service, so _not_ supporting it for FUSE (or
> Android) is a perfectly valid choice.
>
> Even in the software defined block device world for Cloud VM's, you
> generally don't need it because this can be handled at the control
> plane level. For example, Google Cloud's Persistent Disk has an I/O
> fencing feature where if one of the VM loses network connectivity, you
> can do a forced failover where the backup VM can "take over" the cloud
> disk, and the previous VM that had exclusive writer access will have
> its access cut off before the secondary VM gains exclusive write
> access to the disk. If you have this, you don't need MMP.
<shrug> So what should we do? I'd be fine with dropping the patch and
simply not supporting MMP in containerized fuse*fs. It's a rather niche
feature anyway.
--D
> Cheers,
>
> - Ted
>
>
prev parent reply other threads:[~2026-09-23 4:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 6:41 [GIT PULL 2/4] fuse4fs: run servers as a contained service Darrick J. Wong
2026-09-23 0:46 ` Theodore Tso
2026-09-23 4:54 ` Darrick J. Wong [this message]
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=20260923045445.GY6283@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.