Skip to content

9P File sharing #4858

@redbeam

Description

@redbeam

This issue is concerned with describing the 9P File sharing integration as a whole, so that other related issues can link to it.

The goal of the integration is to replace the current file sharing solution that involves SMB.

An approach similar to Podman was desired, but the main obstacle was the missing support for a kernel module-based 9P client in RHEL (and RHCOS). I did some experiments trying to compile the kernel module from various sources, but only one of them was successful, and ultimately, after discussions, we decided to abandon this option due to the many difficulties this would bring.

The other option is a FUSE-based userspace client. This required finding a working program that could readily be used. Out of many repositories on GitHub, I was able to select two that could be used: ftrvxmtrx/9pfs and aperezdc/9pfuse.

The server part was a different story - a Go library enabling 9P server functionality was needed. Fortunately, there was a greater selection of options to choose from and I was able to select these libraries:

I then implemented the server code using each of the libraries, followed by testing of each combination.

The first problem was 9P version incompatibility. With the exception of hugelgupf/p9, the only supported 9P version is 9P2000 (the original version). Against the standard, hugelgupf/p9 supports only 9P2000.L and not 9P2000, so this meant that none of the clients could be used with it.

Next, I found out that docker/go-p9p, knusbaum/go9p and lionkov/ninep actually don't support Windows. This is due to how they get file information from the filesystem. I was able to trivially fix this, but not for lionkov/ninep, where the changes required a lot more work.

What remained were 3 server libraries and 2 clients that worked successfully, although with different performance results. Performance evaluation results can be found in #4746.

In the end, I decided to use the combination of DeedleFake/p9 for the server library and ftrvxmtrx/9pfs for the client, since they seem to be the most supported, even though the performance is worse than the other combinations. I do think it can be improved though, it just requires more investigation.

The main drawback of docker/go-p9p is its unsupported status (the repository is actually an archive), and for knusbaum/go9p it's the slightly more complicated implementation of the server.

The client needs to be integrated into the bundle, this will be done through installation from a COPR repository set up for it on https://copr.fedorainfracloud.org/coprs/mskvarla/9pfs/. The bundle integration will be done in crc-org/snc#1123.

Metadata

Metadata

Assignees

Labels

kind/spikeInvestigation to provide direction and workable tasks

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions