FUSE Passthrough Mode Merged For Linux 6.9

[phoronix]

Phoronix: FUSE Passthrough Mode Merged For Linux 6.9

The FUSE passthrough mode that's been years in the making for better performance was merged upstream today for the in-development Linux 6.9 kernel!..

https://www.phoronix.com/news/Linux-6.9-FUSE-Passthrough

[Jumbotron]

WHOO-HOOH !! Yes !!

[Jumbotron]

Now that I think about it, will this dovetail nicely and enhance the performance of the newly merged NTFS-3G ?

In addition how will this effect WINE performance, if any ?

[erniv2]

Now that I think about it, will this dovetail nicely and enhance the performance of the newly merged NTFS-3G ?

In addition how will this effect WINE performance, if any ?

There are 2 ntfs3 drivers one is the fuse one and the 2nd is the newly merged kernel driver, and the kernel driver is allready in the kernel ?

https://wiki.ubuntuusers.de/FUSE/

[Kjell]

This is great for PuzzleFS since their kernel filesystem driver is still being worked on

[euduvda]

Is it enabled by default?
Do we have to do something to use it?

[dlq84]

Now that I think about it, will this dovetail nicely and enhance the performance of the newly merged NTFS-3G ?

In addition how will this effect WINE performance, if any ?

FUSE is used for user-space filesystem implementations, it has nothing to do with implementations of ntfs in kernel-space.

[linuxgeex]

Now that I think about it, will this dovetail nicely and enhance the performance of the newly merged NTFS-3G ?

In addition how will this effect WINE performance, if any ?

It won't effect actual filesystems in any way. What it does is pass through file handles from an underlying filesystem, such as squashfs or ext4fs, to the process opening the file from a FUSE filesystem mount, such as overlayfs. That allows process IO calls directly on VFS to the underlying filesystem without going through FUSE any more.

It won't be 100% compatible, since when you look up the inode and device it will then report for the filesystem which is actually backing the file, not the FUSE mountpoint and its options. So if you looked up the free space of the device via its file handle, when it's a file backed on read-only squashfs, with a writable ext4fs overlay, then it would report zero free space, whereas without passthrough it would report the free space for the overlay. It will also have some security problems if it was used with containers, which is sad, as that would otherwise be a really awesome use case.

How will it affect wine? I guess that depends on whether your OS or wine app or wine bottle is provided via a FUSE mount. If you use a snap for wine, then maybe it improves performance a tiny fraction of 1%. The real savings are to do with the page cache and skipping the FUSE layer, and those savings would only really present if you were doing massively heavy file IO, like tens or even hundreds of thousands of small IO transactions per second, ie running a windows database server and pointing a large production workload at it.

[Jumbotron]

FUSE is used for user-space filesystem implementations, it has nothing to do with implementations of ntfs in kernel-space.

Sorry, I knew that already but I was thinking about what I read long ago about the relationship of NTFS-3G and FUSE. Can’t find that article but here’s a snip from Wikipedia…

NTFS-3G is an open-source cross-platform implementation of the Microsoft WindowsNTFS file system with read/write support. NTFS-3G often uses the FUSE file system interface, so it can run unmodified on many different operating systems

[Jumbotron]

It won't effect actual filesystems in any way. What it does is pass through file handles from an underlying filesystem, such as squashfs or ext4fs, to the process opening the file from a FUSE filesystem mount, such as overlayfs. That allows process IO calls directly on VFS to the underlying filesystem without going through FUSE any more.

It won't be 100% compatible, since when you look up the inode and device it will then report for the filesystem which is actually backing the file, not the FUSE mountpoint and its options. So it has some security problems if it was used with containers, which is sad, as that would otherwise be a really awesome use case.

How will it affect wine? I guess that depends on whether your OS or wine app or wine bottle is provided via a FUSE mount. If you use a snap for wine, then maybe it improves performance a tiny fraction of 1%.

Ok thanks for that…interesting note about possible security issues with containers but perhaps a tiny speed boost with said container albeit Snap.