What are the tradeoffs of using MFS

Hello there!

Having been using IPFS since 2017, I have come across very limited discussions and documentation on the MFS(Mutable File System).

Although https://docs.ipfs.io/guides/concepts/mfs/ and this this thread gives minmal context, I believe there is more information required to understand MFS adequately for developers to make key decisions in using MFS.

So, here are some of my questions:
1. Are there any design documents made available for MFS?
For e.g., how the in-memory file system works, how the state change are committed back to DAG, how the File and Directory are being mapped to their CIDs to maintain trail of changes etc.

2. Can MFS be consumed by applications, compared to directly consuming IPFS through the HTTP APIs? If so, what are the potential trade-offs?
A trade-off could not necessarily be a functional, but also inherent features of IPFS that could be missed out, by directly pointing all the changes to MFS maybe?

3. Although MFS is accessible directly from the ipfs cli, what is the current production-readiness compared to that of IPFS HTTP APIs?
Can MFS be used in a file sharing application per se? Also, it would be nice to mention a few applications adopting MFS, if any.

I thank in advance for the answers from the community. Cheers to IPFS.

@whyrusleeping and @stebalien , I am tagging and requesting you to review my Question. Thank you.

1 Like

Not really. From the user’s perspective, it should look like each operation updated the root hash. MFS just reserves the right to do this lazily.

Can MFS be consumed by applications, compared to directly consuming IPFS through the HTTP APIs? If so, what are the potential trade-offs?**

There should be little to no difference between using, e.g., ipfs ls and ipfs files ls.

2. Can MFS be consumed by applications, compared to directly consuming IPFS through the HTTP APIs? If so, what are the potential trade-offs?

MFS is also a part of the HTTP API.

3. Although MFS is accessible directly from the ipfs cli, what is the current production-readiness compared to that of IPFS HTTP APIs?

The primary downside of using MFS instead of ipfs add, etc. is that it isn’t used/tested as much.

However, the webui and ipfs-desktop currently use it as the default interface for working with files.

Also, it would be nice to mention a few applications adopting MFS, if any.

The primary use-case for MFS is that it’s a nicer way to work with files than the ipfs pin interface. It also makes it easy to add files to existing hierarchies.

1 Like

@stebalien, thank you very much for your answers.

One follow-up question (it may sound impractical):

Is there a plan for replicating the MFS file structure in the ipfs-cluster-service ?

Awaiting your answer, much thanks.

I have no idea. @hector?