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:

• Waiting for Fix build on Plan 9 cheggaaa/pb#163 to be merged
• Waiting for Fix build on Plan 9 dgraph-io/badger#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)
• ipfs/go-ds-flatfs needs a new release tag
• ipfs/go-fs-lock needs a new release tag
• 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 Polling fallback fsnotify/fsnotify#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 quic-go/quic-go#2614), I ended up back-porting those fixes to Go 1.14 to get everything working.

/CC @willscott

[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 hugelgupf/p9#13, hugelgupf/p9#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

[lolbinarycat]

I have cmd/ipfs building and working on Plan 9.

how?

[fhs]

I have cmd/ipfs building and working on Plan 9.

how?

@lolbinarycat The Plan 9 changes have already been merged. I think v0.8.0 will be the first go-ipfs release to support Plan 9. You can try out v0.8.0-rc2.

[lolbinarycat]

I have cmd/ipfs building and working on Plan 9.

how?

@lolbinarycat The Plan 9 changes have already been merged. I think v0.8.0 will be the first go-ipfs release to support Plan 9. You can try out v0.8.0-rc2.

what I don't get is what commad to use to build ipfs on plan9. just typing make doesn't work obviously, mk isn't compatible as well. I recently heard of ape/make, but that doesn't seem to work either.

[djdv]

@lolbinarycat
(I'll butt in with a reply just cause I saw this quickly)
I tend to just run the go tool directly, regardless of platform.
From this repo's srcdir you should be able to do go build ./cmd/ipfs and get a resulting ipfs binary.

Platforms with working C compilers I'll usually pass in the openssl build tag as well (just cause), and then on most unices I'll remove bazil fuse too with nofuse.
A complex example on Windows might be: go install -tags="openssl nofuse" .\cmd\ipfs (build would work fine too here)

I imagine on P9 you can just bind the Go compiler and do something similar.
Curious to know myself if there's any portability notes. I'll be doing testing on Plan 9 (eventually) also.

[lolbinarycat]

@djdv
even with nofuse, I keep getting errors mentioning basil.org/fuse and the non-existance of /sys/lib/tls/ca.pem.

[fhs]

@lolbinarycat Run go build with GO111MODULE=on. You shouldn't need to specify nofuse tag. Plan 9 doesn't come with ca.pam, so you need to download it. Also, make sure you're using Go >= 1.15. This works for me:

cpu% hget https://curl.haxx.se/ca/cacert.pem > /sys/lib/tls/ca.pem
cpu% hget https://github.com/ipfs/go-ipfs/releases/download/v0.8.0-rc2/go-ipfs-source.tar.gz > go-ipfs-v0.8.0-rc2.tar.gz
cpu% mkdir go-ipfs-v0.8.0-rc2
cpu% cd go-ipfs-v0.8.0-rc2
cpu% tar xf ../go-ipfs-v0.8.0-rc2.tar.gz 
cpu% cd cmd/ipfs
cpu% GO111MODULE=on go build
cpu% ./ipfs version
ipfs version 0.8.0-rc1

[lolbinarycat]

@fhs now it's giving me "can't open version list lockfile: ... : file locked"

[fhs]

@lolbinarycat Go expects that error to have certain format. The error should be file is locked, not file locked. I fixed this a while ago on 9front ramfs (the fix). You may need update your 9front ramfs if that's what's giving that error, or fix whatever other file server that's giving that error.

[lolbinarycat]

@fhs now I'm getting failed to write version list: ...: file exists

[djdv]

Does this seem related: ipfs/go-fs-lock#19 ?
Windows is having lock issues in regards to the lock error value's being compared similar to these.
The Plan 9 variant seems to account for multiple values , but I don't see "file exists" in there.

[fhs]

@lolbinarycat I've been using cwfs on 9front and fossil on 9legacy to test Go, so it's likely other file servers (e.g. hjfs) aren't that well tested. Try changing the error strings in hjfs if that's what you're using.

cwfs errors:

data.c:38: 	[Elocked]	"open/create -- file is locked",
data.c:18: 	[Eexist]	"create/wstat -- file exists",

hjfs errors (note: Elocked is wrong):

main.c:14: char Elocked[] = "file locked";
main.c:13: char Eexists[] = "file exists";

[lolbinarycat]

@fhs I got it built, most things seem to work, but ipfs daemon results in an error about 127.0.0.1 not being a local address.

[fhs]

@lolbinarycat You need to configure loopback addresses:

ip/ipconfig -P loopback /dev/null 127.1
ip/ipconfig -P loopback /dev/null ::1

[ec1oud]

On latest HEAD (4403946)

cpu% go build ./cmd/ipfs
# go.uber.org/fx
/usr/glenda/go/pkg/mod/go.uber.org/fx@v1.15.0/app.go:790:19: undefined: _sigINT
/usr/glenda/go/pkg/mod/go.uber.org/fx@v1.15.0/app.go:790:28: undefined: _sigTERM
/usr/glenda/go/pkg/mod/go.uber.org/fx@v1.15.0/shutdown.go:52:31: undefined: _sigTERM