FUSE With Linux 5.15 Now Allows Mounting An Active FUSE Device

[jbean]

FUSE isn't necessarily meant for classical file systems like NTFS, but rather specialized virtual file systems that provide a certain view on data or have other special functionality.
I employ several FUSE file systems for personal use. They're useful for data aggregation across many different devices/network sources and I also use it for a parity-based backup system that is similar to RAID4.

Can you tell me what you're using? I'd love for an open source option for doing something like this, but it sounds to me you're just describing Unraid...

[tildearrow]

Now with the new NTFS driver being merged into mainline Linux kernel, what use is FUSE these days?

Are there any file system that FUSE supports that the kernel does not?
I guess FUSE will still continue to be useful for prototyping file systems when developing a new file system. Maybe?

Linux still does not have support for Apple's file system APFS.

SSHFS

[ssokolow]

Can you tell me what you're using? I'd love for an open source option for doing something like this, but it sounds to me you're just describing Unraid...

Possibly mergerfs on top of underlying fliesystems that provide for the data checksumming and healing.

It's very configurable as a way to merge multiple devices into one at a higher level and define rules for which files should wind up on which backing drives based on their paths.

[edgmnt]

Honestly, aside from normal filesystems, SSHFS and a few others, it really isn't such a great idea to present things as POSIX filesystems.

If I'm designing an application, I'd much rather work with a native API which matches the semantics of the target (pseudo-)storage closely. Especially if you need transactional semantics or metadata access is expensive.

Sometimes it's nicer for regular filesystems too. For example, we had to implement remote SD card access on a Linux device. The kernel VFAT is horribly insecure for untrusted filesystems (think of directory entries that start with a slash, you can easily create those with a hex editor) and FUSE probably doesn't help a lot here considering you still have to mount it somewhere. It was easier to just use a library to access the SD card through an API, an embedded FTP server and everything is isolated. No more nasty (um, traditional) standalone FTP servers to chroot and stuff like that.

Everything-is-a-file isn't that great.

[ssokolow]

It was easier to just use a library to access the SD card through an API, an embedded FTP server and everything is isolated. No more nasty (um, traditional) standalone FTP servers to chroot and stuff like that.

By this, I assume you mean that the goal was always to expose a filesystem-like interface on the abstract level, given that's what FTP does too, so "everything is a file" as a principle still applies, even if you've diverged from the implementation UNIX chose. (Remember what the creators of UNIX did with Plan 9 as a post-networking expression of that philosophy.)

[edgmnt]

By this, I assume you mean that the goal was always to expose a filesystem-like interface on the abstract level, given that's what FTP does too, so "everything is a file" as a principle still applies, even if you've diverged from the implementation UNIX chose. (Remember what the creators of UNIX did with Plan 9 as a post-networking expression of that philosophy.)

Yes, clients still used FTP and files. However, the uploads were automated and the device was actually supposed to do something with those files besides just storing them. How do you know the file or batch of files is ready to be processed? Well, you don't really, such semantics do not exist in the plain file abstraction, leading to other problems down the way even if it seems convenient at first glance.

[ssokolow]

Yes, clients still used FTP and files. However, the uploads were automated and the device was actually supposed to do something with those files besides just storing them. How do you know the file or batch of files is ready to be processed? Well, you don't really, such semantics do not exist in the plain file abstraction, leading to other problems down the way even if it seems convenient at first glance.

I think you're misjudging things. "Everything is a file" has nothing to say on the "separate process or library" distinction and, at least in my opinion, it's wrong to expect the filesystem layer to be the IPC mechanism for signalling task completion when a task doesn't map one-to-one to a file. (Though, if you really want, you could agree to open a file at the start of the task and the listener could ask inotify to poke it on IN_CLOSE_WRITE.)

You don't want the filesystem becoming the next "X.org once had a print server in it because they tried to shoehorn everything into that layer of the stack".

Heck, how is the FTP system supposed to know that a task is complete? FTP doesn't have a clearly defined equivalent to SQL's COMMIT.

[jbean]

Possibly mergerfs on top of underlying fliesystems that provide for the data checksumming and healing.

It's very configurable as a way to merge multiple devices into one at a higher level and define rules for which files should wind up on which backing drives based on their paths.

Yea I'm aware of merger fs. Great stuff. I'm more interested in the parity side of things though. There's nothing that I'm aware of that compares to the realtime parity unraid provides for independently formatted disks.