Re: [GIT PULL 2/4] fuse4fs: run servers as a contained service

["Theodore Tso" <tytso@mit.edu>]

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.

Cheers,

						- Ted