Message-ID: <20250529013713.GA8282@frogsfrogsfrogs>
Date: Wed, 28 May 2025 18:37:13 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Theodore Ts'o <tytso@....edu>
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCHSET 1/6] fuse2fs: even more bug fixes

On Fri, May 23, 2025 at 10:03:44AM -0400, Theodore Ts'o wrote:
> On Wed, May 21, 2025 at 03:34:36PM -0700, Darrick J. Wong wrote:
> > Hi all,
> > 
> > This series fixes even more bugs in fuse2fs.
> 
> Thanks, applied.  I found that it didn't compile, because it used
> fuse2fs_{read,write}_inode() which doesn't get defined until PATCHSET
> 2/6.  So I've also applied the second patchset, and then split the
> patch "fuse2fs: simplify reading and writing inodes" into two commits,
> and applied the first half before "fuse2fs: fix removing ea inodes when
> freeing a file" to keep the fuse2fs changes bisectable.
> 
> Also, I cleaned up some patches to keep fuse2fs portable enough to
> work with MacOS.  I've lightly tested fuse2fs with MacFuse (installed
> via MacPorts) on macOS Sequoia and it works without having to pay $$$
> to Apple.  You do need to enable the MacFuse system extension (which
> is signed by Benjamin Fleischer, so I guess Fleischer is the one who
> paid $3000 to Apple) and reboot, but it does work.
> 
> I'll reach out to someone in FreeBSD land to test whether fuse2fs
> works there, since I'd like to maintain cross-OS portability as much
> as possible.

Hrmm.  A question I've been pondering for a couple of weeks is whether
or not fuse2fs-iomap should actually care about cross-OS portability.
The further I wander into the two layers of libfuse, the more I realize
that the low level fuse library is for fuse servers that want to tie
themselves to Linux (e.g. you can implement statx and copy_file_range)
and the high level library, which seems to be maintaining compatibility
with the osx/bsd variants.

At this point I don't know if one can actually /create/ a hybrid fuse
server that talks to both layers (layering violation!!) since the upper
level hides the guts of the low level library.  If you've looked at the
fuse2fs iomap code, you'll notice that I've passed the Linux fuse
driver's nodeid (aka the iget number) all the way up to fuse2fs along
with the ext2 ino number which is basically a u64 cookie that gets
passed along with the nodeid.

If the Linux fuse driver maintainers accept the fuse-iomap code then
maybe it would make sense to fork fuse2fs: one for general compatibility
across filesystems, and second one optimized for Linux.

> It does mean that I'm a bit concerned about the fuseblk
> patchset because I'm pretty sure that's Linux-specific, correct?

That's a good question.  libfuse says that fuse_operations::bmap only
makes sense for filesystems mounted with the "blkdev" option (which is
what turns on fuseblk mode) and doesn't #ifdef it away on any platforms.
libfuse itself seems to be built on freebsd, but then ...

Looking through what I think is the mount option parsing code in
fuse_vfsop_mount, I don't think they support a blkdev= option?
https://raw.githubusercontent.com/freebsd/freebsd-src/refs/heads/main/sys/fs/fuse/fuse_vfsops.c

So maybe it's not supported on !linux.  Unfortunately, it's not easy to
tell from the one other fuseblk server I know of (ntfs-3g) if they even
try to use fuseblk mode on freebsd because of course they vendored
libfuse into their own source code(!)

Will have a closer look tomorrow.  At worst we can always wrap it in
more #ifdef __LINUX__ magic.

--D

> Cheers,
> 
> 						- Ted
> 

Powered by blists - more mailing lists