Reuse, or at least cite, OpenAFS technology about ipfs HOT 5 CLOSED

@tmagik You'll want to look at the fs/afs and net/rxrpc subsystems in Linux and at https://www.infradead.org/~dhowells/kafs/. Notably, AuriStor has modernized the Rx and AFS to add IPv6 and modern cryptography ("rxgk") among other things and has supported David Howells' bringing these changes to kAFS. (ETA: I'm not sure the extent to which these changes have propagated into the OpenAFS tree.)

from ipfs.

Hey @nwf, thanks for posting here. :)

Many things apparent in the ipfs effort were pioneered a long time ago by the AFS (now OpenAFS) project, including storage location transparency; a global, automatic namespace mounted on the clients; and cross-realm authentication and permission management. At a minimum, their papers should be studied and cited.

I have studied AFS, and the IPFS paper does cite AFS, it is in fact the first citation. (Though perhaps it should be 9P, as it was much more influential :) ). AFS is one of many distributed filesystems that did these things. It certainly deserves special mention, which is why I included it. But it wasn't the first, and it wasn't the last. Then again, do note the IPFS paper is a draft, not published at any academic journal/conference, and will change a lot before it makes out of this stage. My first priority is deploying it, not publishing.

In fact, it might also make sense to reuse much of their work

While I'm all for reusing code, most of the codebases I've worked with for larger distributed systems make deep assumptions about the system's model which make the code unusable by other systems. (Sadly, we're finding it too easy to make similar assumptions in our implementation, though we try hard to abstract things out into reusable, non-ipfs-dependent modules, though there's always the tradeoff of actually shipping something good :) ).

ipfs could be implemented as an alternative AFS file server

The point of IPFS is to evolve the web, not just enhance AFS. While I'm all for interop, and would love to support efforts there, we have limited time. Happy to accept Pull Requests or answer any questions on that front for any IPFS-AFS adapters that may make sense. (This will actually be very easy-- the reference IPFS implementation will provide a flexible, multi-format and multi-transport RPC API.

However I will say that IPFS itself using AFS does not make sense. IPFS is actually pretty large, and does a lot. And, part of the point is moving away from traditional permission models, or thinking just about files. IPFS is about data/objects addressable in the web.

client/server and server/server interactions.

IPFS breaks from the client/server model. The point is to be peer-to-peer.

reuse all the effort of the AFS file system client kernel and FUSE modules.

We already have our own FUSE module, and we'll eventually write our own kernel driver. In due time. (these things aren't that hard -- legacy side-effect ridden code is much worse to deal with).

@nwf In general, i'm happy to discuss AFS-IPFS interop, but this is not a topic for today. It will be a topic for months from now. Perhaps talk then! Feel free to follow along development of our first implementation here: https://github.com/jbenet/go-ipfs/

from ipfs.

Thanks for your prompt reply. Best of luck with everything. :)

from ipfs.

So this was closed 6 years ago, with a comment about

and we'll eventually write our own kernel driver

Does such a thing yet exist, cause I'll use it.

Otherwise, if you know of a distributed filesystem that's had as much adoption and use as AFS, please let me know, as I'm about to go full-on in attempting to bring AFS into the decade where everyone has an IPv6 address, half the world has a linux based phone on their desk (thank you Google), and IPFS is the next "new big thing".

There are some really nice things about IPFS... It seems to me like a great way to package and distributed read-only AFS volumes that you want to share with the rest of the world (like say the Debian archive in AFS, or the gajillion NodeJS modules, or maybe the binaries and everything else for Golang or Rust)

But we still need a kernel module.

from ipfs.

to necro this, sadly...

[open]mosix had a pervasive rpc and vfs on its own broadcast protocol which may have fallen short in paranoid security but was unbelievably helpful and was a vehicle to virtualize entire process spaces to peer nodes in pre-hypervisor days. it held up under production even.

from ipfs.