separate ipfs mount into its own separate binary

[whyrusleeping]

It might be nice to have ipfs-mount be a separate binary called through the same mechanism as ipfs update. I don't think we will hit any performance issues with all I/O being done through http rpc, but it might be worth the effort to separate out that code from the rest of the daemon.

[jbenet]

I like the idea in general.

It will be painful unless we use some sort of no copy ipc. Fuse is already
slow and will get slower piping through another rpc later. It will get bad
because Kernel scheduling is now he arbiter not golang runtime.

Let's investigate ipc-- I want it for exo transports in libp2p
On Sat, Jan 2, 2016 at 06:30 Jeromy Johnson [email protected]
wrote:

It might be nice to have ipfs-mount be a separate binary called through
the same mechanism as ipfs update. I don't think we will hit any
performance issues with all I/O being done through http rpc, but it might
be worth the effort to separate out that code from the rest of the daemon.

—
Reply to this email directly or view it on GitHub
#2148.

[elitak]

I'd like this for purposes of sharing a repository on the same host between VMs/containers. They can already connect to the same API endpoint, using the --api option, but ipfs mount mounts locally to the daemon, when it should instead mount wherever the command is run.

Also, the binary does not have to be independent of the main one. The "mount-daemon" mode could be invoked via something like ipfs --api <remote-api-endpoint> mount-daemon --ipfs-mtpt=/ipfs --ipns-mtpt=/ipns --allowOther. Probably this mode should use none of the config file, if possible, and not require local initialization. Wrapping this invocation in a systemd unit (or whatever downstream maintainers want to do to manage the daemon) would be ideal, I think.

[whyrusleeping]

@elitak I like that idea a lot