[AdamJacobMuller]

> It also writes files in it's own uninterpretable format to object storage, so if you lose the metadata store, you lose your data.

That's so confusing to me I had to read it five times. Are you saying you lose the metadata, or that the underlying data is actually mangled or gone, or merely that you lose the metadata?

One of the greatest features of something like this to me would be the ability to durable even beyond JuiceFS access to my data in a bad situation. Even if JuiceFS totally messes up, my data is still in S3 (and with versioning etc even if juicefs mangles or deletes my data, still). So odd to design this kind of software and lose this property.

[mrkurt]

It backs its metadata up to S3. You do need metadata to map inodes / slices / chunks to s3 objects, though.

Tigris has a one-to-one FUSE that does what you want: https://github.com/tigrisdata/tigrisfs

[ifoxhz]

FUSE generally has low overall performance because of an additional data transfer process between the kernel space and user space, which is less than ideal for AI training.

[suavesu]

The MLPerf performance of JuiceFS last year, FUSE client, and TCP/IP network. There're some analysis about performance and bottleneck. -> https://juicefs.com/en/blog/engineering/mlperf-storage-v2-ai...

[cbarrick]

As I understand it, if the metadata is lost then the whole filesystem is lost.

I think this is a common failure mode in filesystems. For example, in ZFS, if you store your metadata on a separate device and that device is destroyed, the whole pool is useless.

[suavesu]

metadata backup is very important. don't forget.