Go-ipfs: Add support for Plan 9

[fhs]

I have cmd/ipfs building and working on Plan 9. Most of the go-ipfs dependencies have already been patched to support Plan 9, however few are still pending review or not tagged with a release. The missing bits before I can submit a PR to go-ipfs itself:

• [x] Waiting for https://github.com/cheggaaa/pb/pull/163 to be merged
• [x] Waiting for https://github.com/dgraph-io/badger/pull/1451 (merged) to be part of a release. We want a new v1.x.x release so that ipfs/go-ds-badger can use it. (This isn't strictly necessary if we can remove badger from plugin/loader/preload.go if GOOS=plan9)
• [x] ipfs/go-ds-flatfs needs a new release tag
• [x] ipfs/go-fs-lock needs a new release tag
• [x] libp2p/go-tcp-transport needs to use libp2p/go-reuseport-transport >= v0.0.4 and tagged with a new release

The changes need in go-ipfs is very small (mostly build tags changes). Few things currently missing:

• cmd/ipfswatch doesn't build because of fsnotify (see https://github.com/fsnotify/fsnotify/issues/9).
• A 9P file server as an alternative to fuse

_Note:_ Go 1.15 comes with few fixes to the Plan 9 net package that are necessary for ipfs to work. Because quic currently panics on Go 1.15 (see https://github.com/lucas-clemente/quic-go/issues/2614), I ended up back-porting those fixes to Go 1.14 to get everything working.

/CC @willscott

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[fhs]

Oops, I think this should be labeled as kind/enhancement instead of kind/bug.

[willscott]

cc @djdv who i believe has made some progress towards a 9p fuse alternative

[djdv]

Very cool!
For what it's worth I have a branch of go-ipfs that's in progress, with notes about it here.

The short of it is that it supports read and (unstable) write operations for the IPFS APIs, exposed over FUSE (using cgofuse) and/or a 9P server (using p9).

The 9P library currently supports the 9p2000.L protocol version which covers Linux hosts nativley via v9fs, among a variety of virtual interfaces. But there is an issue for adding support for 9p2000.u and styx listed https://github.com/hugelgupf/p9/issues/13, https://github.com/hugelgupf/p9/pull/41
Which when implemented, would cover base Plan 9 systems.

The implementation I have retains the nofuse flag, allowing you to build go-ipfs without fuse on systems that don't have it.
And the node's fs manager should already work on Plan 9 if the rest of go-ipfs can build (I vet for it at least but haven't tested it).

When everything involved is completed (and stable), it would offer a way to spawn and manage 9P servers on a Plan 9 host. Doing things like binding IPNS to a multiaddr target which listens for 9P requests. Which could be bound to /n/ipns or whatever via bind $that-socket-addr /n/ipns.

Currently on Linux, the branch handles this automatically and the same would be done on Plan 9.
(If the user requests to mount a path, we spawn a socket transparently, and bind to the path using it. If they specify to mount a multiaddr, we just spawn the socket and don't try to mount any host paths)

[aidanharris]

@djdv Do you have any performance figures / benchmarks? The current FUSE implementation is really slow. I'd be curious to know if this improves things on Linux when using v9fs instead of FUSE?

[djdv]

@aidanharris
I'm happy to talk about mount things but I also don't want to derail this issue. So I'll just say that I don't have any numbers yet, but the alternate branch is fast enough for me to add a program on 1 LAN machine and execute it with its data on another LAN machine via FUSE, about this quickly: https://www.youtube.com/watch?v=vTYaJTbRSY4
I was also aggressively seeking around large video files and sparse audio directories in my native media players, without noticing anything funny but have no objective statistics/comparisons yet. Simple contiguous reads should be as fast as ipfs get within some small margin.

It's easy to build and run yourself, but remember that nothing is considered stable yet. They'll both get proper compliance tests later, but that hasn't happened yet. Same with standards around the config format and command line arguments, but I still need to discuss those with people from the project.

If you (or anyone) end up wanting to try it yourself, feel free to reach out to me for help and feedback (positive or negative).
I'm very eager to hear what users want out of this. The existing implementation has lasted for years without change and it's been several years of hearing users say "I wish this actually worked", so I'd like to try and help make it so while we still have the opportunity to make changes to it. But also not delay forever (I'm already way behind on this effort).

[willscott]

https://github.com/ipfs/go-ds-flatfs/releases/tag/v0.4.5
https://github.com/ipfs/go-fs-lock/releases/tag/v0.0.6

[hugelgupf]

The 9P library currently supports the 9p2000.L protocol version which covers Linux hosts nativley via v9fs, among a variety of virtual interfaces. But there is an issue for adding support for 9p2000.u and styx listed hugelgupf/p9#13, hugelgupf/p9#41
Which when implemented, would cover base Plan 9 systems.

I've been working with the Harvey folks on Plan 9 & 9P2000 support for the p9 library, but I kind of haven't had that much time lately. @sevki is on it, afaik.

[willscott]

https://github.com/libp2p/go-tcp-transport/releases/tag/v0.2.1