Fuse Alternatives

Similar projects and alternatives to fuse

rclone

963 43,720 9.8 Go fuse VS rclone

"rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Yandex Files
litestream

165 9,964 7.5 Go fuse VS litestream

Streaming replication for SQLite.
InfluxDB

www.influxdata.com sponsored

Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
rqlite

112 14,835 9.9 Go fuse VS rqlite

The lightweight, distributed relational database built on SQLite.
litefs

38 3,620 8.0 Go fuse VS litefs

FUSE-based file system for replicating SQLite databases across a cluster of machines
tigerbeetle

37 1,012 9.5 Zig fuse VS tigerbeetle

Discontinued A distributed financial accounting database designed for mission critical safety and performance. [Moved to: https://github.com/tigerbeetledb/tigerbeetle] (by coilhq)
libfuse

21 4,961 8.6 C fuse VS libfuse

The reference implementation of the Linux FUSE (Filesystem in Userspace) interface
wunderbase

12 516 10.0 Go fuse VS wunderbase

Serverless GraphQL Database built on top of Firecracker, SQLite and Prisma
WorkOS

workos.com sponsored

The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
fuse-filesystem

1 2 5.0 Go fuse VS fuse-filesystem

In memory filesystem of top of FUSE

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better fuse alternative or higher similarity.

Suggest an alternative to fuse

fuse reviews and mentions

Posts with mentions or reviews of fuse. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-01-05.

FUSE Filesystem
3 projects | dev.to | 5 Jan 2023

For this first implementation I used Go. After a reviewing some solutions I decided to use https://github.com/bazil/fuse. It seemed to be the easiest way to prototype.
Introducing LiteFS
9 projects | news.ycombinator.com | 21 Sep 2022

Often, the SQLite database would fit in RAM, and reads would be served straight from the page cache, with no overhead.
Disclaimer: I wrote the FUSE framework LiteFS uses, https://bazil.org/fuse -- and I also have some pending performance-related work to finish, there...
I just upgraded to 13.1-RELEASE
2 projects | /r/freebsd | 18 May 2022

I'd love to upgrade but I rely on mounting my Google Drive via /dev/fuse and rclone. There was a post yesterday saying that is broken in 13.1-RELEASE and linking to a FreeBSD bug which links to a rclone bug which links to a bazil bug which seems to have no traction. Someone mentioned a commandline utility that can interact with gdrive but this seems like a pretty bad replacement. IIUC the FreeBSD devs' theory is that a new async system call path exposed a bug in rclone and the blame is there. Anyway, I'm still on 13.0 for now, unfortunately.
Just updated to 13.1-Release, some sort of rclone/fuse issue
4 projects | /r/freebsd | 17 May 2022

This was also reported to rclone where someone pointed out that the problem is with fuse lib on FreeBSD and as such is a FreeBSD fuse lib porting problem.
Distributed Systems Shibboleths
3 projects | news.ycombinator.com | 2 May 2022

> 'failed' state and the process itself leaving the accounting tables.
Once again, that cannot be done until the parent process consumes the exit status. That's what the zombie is there for. Zombies don't take up much space.
> Stuck mounts have a half solution (lazy unmounts) but even _that_ interface really also needs a timeout value after which operations on the target should be assumed to fail rather than return correctly.
These days most NFS etc mounts are "soft mounts", that is operations will eventually time out.
Lazy unmount doesn't really apply here, it makes the mountpoint disappear from the global namespace, but all existing open files remain untouched, and the mount lives as long as anything is still using it; it just removes the "entry point" to the mount.
On today's Linux, it's up to each filesystem to provide abort/timeout mechanism. For timeouts, this is the right design, as demonstrated by macOS complications with FUSE. I do wish there was a common way to make things abort.
There was a patch in circulation a long time ago, that could seamlessly switch all open FDs of any given mountpoint into a whole different filesystem named badfs. badfs would just return an error on any operation. As far as I know, that patch never got merged, probably because nobody ever got it working 100%.
That kind of a DoS would require a local attacker, and then the victim to access a mountpoint owned by the attacker. Using FUSE, you could get a lot of processes hanging like that, for sure. I guess you could trap a mail delivery agent, if you still had a system where mail was delivered to users' home directories.
However, forcibly aborting any FUSE mount is a single `echo 1 >/sys/fs/fuse/connection/NNNN/abort`, the only challenge is finding the right ID. (See https://github.com/bazil/fuse/blob/fb710f7dfd05053a3bc9516dd...)
A note from our sponsor - InfluxDB
www.influxdata.com | 24 Apr 2024

Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →