pfpacket/rust-9p

Tokio-based asynchronous filesystems library using 9P2000.L protocol, an extended variant of 9P from Plan 9.

rust-9p

Tokio-based asynchronous filesystems library using 9P2000.L protocol, an extended variant of 9P from Plan 9.

Documentation

Build

Use Rust nightly.

Usage

Add the following to your crate:

extern crate rs9p;

unpfs

unpfs is the reference implementation of a file server which exports your filesystem. You can build unpfs with the following commands below:

cd example/unpfs/
cargo build --verbose --release

and run unpfs with the following command to export /exportdir:

# TCP
cargo run --release 'tcp!0.0.0.0!564' /exportdir
# or
./target/release/unpfs 'tcp!0.0.0.0!564' /exportdir

# Unix domain socket:
#  port number is a suffix to the unix domain socket
#  'unix!/tmp/unpfs-socket!n' creates `/tmp/unpfs-socket:n`
cargo run --release 'unix!/tmp/unpfs-socket!0' /exportdir

You are now ready to import/mount the remote filesystem. Let's mount it at /mountdir:

# TCP
sudo mount -t 9p -o version=9p2000.L,trans=tcp,port=564,uname=$USER 127.0.0.1 /mountdir
# Unix domain socket
sudo mount -t 9p -o version=9p2000.L,trans=unix,uname=$USER /tmp/unpfs-socket:0 /mountdir

Mount option	Value
version	must be "9p2000.L"
trans	an alternative v9fs transport. "tcp" or "unix"
port	port to connect to on the remote server
uname	user name to attempt mount as on the remote server

See v9fs documentation for more details.

License

rust-9p is distributed under the BSD 3-Clause License. See LICENSE for details.

rust-9p's Issues

Add lf94/hackernewsfs as an example

https://github.com/lf94/hackernewsfs

Apple M2 Max Macbook Pro support

Very cool project! I'm using rust-9p to explore 9p after reading about plan9 online for so long.

In my plan98 project, i'm using the README cargo run --release 'tcp!0.0.0.0!8888' to expose my project files as a metaphorical thumb drive, with the idea that the user can remix their own web client, without needing a new mental model, if they already can edit files on a thumb drive.

This works on all the linux distros i've hopped before, but i'm doing quality assurance and testing on an macbook for the first time, M2 specifically, if that matters, and getting this error.

tychi@tychis-MBP .plan98 % deno task start-server
Task start-server plan98client=$(pwd)/client; cd rust-9p-master/example/unpfs && cargo run --release 'tcp!0.0.0.0!8888' $plan98client
   Compiling rust-9p v0.0.1 (/Users/tychi/.plan98/rust-9p-master)
error[E0308]: mismatched types
   --> /Users/tychi/.plan98/rust-9p-master/src/fcall.rs:328:21
    |
328 |             blocks: buf.blocks(),
    |                     ^^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
   --> /Users/tychi/.plan98/rust-9p-master/src/fcall.rs:329:20
    |
329 |             bfree: buf.blocks_free(),
    |                    ^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
   --> /Users/tychi/.plan98/rust-9p-master/src/fcall.rs:330:21
    |
330 |             bavail: buf.blocks_available(),
    |                     ^^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
   --> /Users/tychi/.plan98/rust-9p-master/src/fcall.rs:331:20
    |
331 |             files: buf.files(),
    |                    ^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
   --> /Users/tychi/.plan98/rust-9p-master/src/fcall.rs:332:20
    |
332 |             ffree: buf.files_free(),
    |                    ^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `rust-9p` (lib) due to 5 previous errors

happy to help troubleshoot on my end. i can code, primarily javascript, but i've got a rust tool chain installed, just no idea where to start to open a PR myself.

Publish to crates.io

Hi!

Im working on a 9p server for a subset of the nix store. It would be great if I can refer to this crate from crates.io rather than as a submodule.

Any chance this could be published?

Thanks!
Tom

Input/output errors when ctrl-c in the middle of a rreaddir

In my project hackernewsfs, if I ls but Ctrl-C before it finishes, v9fs sends a Tflush to my server which causes an error, which causes my whole server to cease function.

I will open a PR to hopefully resolve this.

Error: I/O error: Unsupported protocol: tcp\

Hi! Wanted to say thanks for this. I've been looking around at a lot of different implementations in other languages, and this was the first one I got to work, and also find it understandable.
Following along with the README demo I ran into an error:

Error: I/O error: Unsupported protocol: tcp\

I'm not sure if its do to my OS (Ubuntu), but your util library wasn't splitting correctly when using this. So I just took the \ out, and I used single quotes.

cargo run --release 'tcp!0.0.0.0!564' ./foobar

Worked for me.

Qid should derive Default

It would be extremely useful to have Qid derive Default so it can be used in the Fid structure.

Example of the error I'm currently hitting because of the lack of derivation:

error[E0277]: the trait bound `rs9p::fcall::Qid: std::default::Default` is not satisfied
  --> src/main.rs:63:3
   |
63 |   qid: RwLock<Qid>,
   |   ^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `rs9p::fcall::Qid`
   |
   = note: required because of the requirements on the impl of `std::default::Default` for `tokio::sync::rwlock::RwLock<rs9p::fcall::Qid>`
   = note: required by `std::default::Default::default`
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

Incorrect response to an unsupported version.

Afaik a server must always respond to Tversion with Rversion. If the version is unknown then it must respond with an 'unknown' version string.

Build fails on Raspberry Pi

I was trying to build this on my Raspberry Pi and I ran into this error:

error[E0308]: mismatched types                                                  
   --> /home/pi/rust-9p/src/fcall.rs:331:19                                     
    |                                                                           
331 |             fsid: buf.f_fsid,                                             
    |                   ^^^^^^^^^^ expected u64, found u32                      
help: you can cast an `u32` to `u64`, which will zero-extend the source value   
    |                                                                           
331 |             fsid: buf.f_fsid.into(),                                      
    |                   ^^^^^^^^^^^^^^^^^                                       
                    

My guess is that its because the Raspberry Pi is a 32 bit architecture.

Is there any way to build on MacOS?

I'm trying to build the unfp on MacOS/Darwin, but following errors was returned:

I'm using rustc 1.37.0-nightly (37d001e4d 2019-05-29). Thanks in advance.

Performance is slower than sshfs

Great project - looks really nice.

I would have expected 9p with the nice rust tokio runtime to easily beat sshfs, but it turns out sshfs is faster by factor of 3x.

Note: I am using a Mac and a qemu VM as that is the use case for me.

Anything I can tweak in terms of using more CPUs and better threading for the tokio co-routines?

Edit: Here are the benchmarks (all done on QEMU on Silicon Mac):

TL;DR:

• SSHFS has the lowest latency and okay raw data throughput
• virtio has the best throughput for raw data writing by far
• rust-p9 is unfortunately slowest right now, latency for find is comparable with virtio so this might be a 9P protocol limitation

Setup

QEMU option for virtio:

-virtfs local,path=projects/oss/rust-9p,mount_tag=foo,id=foo,security_model=mapped-xattr

All 9p mounts have been done with:

# virtio
sudo mount -t 9p -o version=9p2000.L,trans=virtio,uname=$USER,msize=104857600,cache=mmap foo /mnt

# rust-9p
sudo mount -t 9p -o version=9p2000.L,trans=tcp,port=8564,uname=$USER,msize=104857600,cache=mmap 192.168.5.2 /mnt

and the target directory is the one of rust-9p.

Benchmarks

9p-virtio:

colima:~$ sh /mnt/perf.sh 
+ cd /mnt/foo
+ time find target
real	0m 0.78s
user	0m 0.00s
sys	0m 0.10s
+ time cp -r target target3
real	0m 8.83s
user	0m 0.00s
sys	0m 1.10s
+ time rm -rf target3
real	0m 1.56s
user	0m 0.00s
sys	0m 0.30s
+ time dd 'if=/dev/zero' 'of=test.dat' 'bs=1G' 'count=3'
3+0 records in
3+0 records out
real	0m 1.72s
user	0m 0.00s
sys	0m 0.70s

SSHFS:

+ cd /mnt/foo
+ time find target
real	0m 0.45s
user	0m 0.04s
sys	0m 0.00s
+ time cp -r target target3
real	0m 5.28s
user	0m 0.03s
sys	0m 0.62s
+ time rm -rf target3
real	0m 0.74s
user	0m 0.00s
sys	0m 0.09s
+ time dd 'if=/dev/zero' 'of=test.dat' 'bs=1G' 'count=3'
3+0 records in
3+0 records out
real	0m 17.55s
user	0m 0.00s
sys	0m 2.26s

https://github.com/pfpacket/rust-9p via TCP transport:

colima:/$ sh /mnt/perf.sh 
+ cd /mnt/foo
+ time find target
real	0m 0.77s
user	0m 0.00s
sys	0m 0.11s
+ time cp -r target target3
real	0m 10.25s
user	0m 0.00s
sys	0m 1.45s
+ time rm -rf target3
real	0m 1.40s
user	0m 0.03s
sys	0m 0.17s
+ time dd 'if=/dev/zero' 'of=test.dat' 'bs=1G' 'count=3'
3+0 records in
3+0 records out
real	1m 8.48s
user	0m 0.00s
sys	0m 5.01s
colima:/$ 

Support 9p2000 (and maybe 9p2000.u)?

Currently there appears to be no way to choose between 9p2000 or 9p2000.L. There appears to be residual code from possibly an earlier time which suggests there used to be support for 9p2000.

Are there any suggestions on how this should be organized and accessed?

Do we need rust-9pL and rust-9pu and rust-9p?

Do we use different internal modules for each 9p version?

Do we use an enum and have the behavior changed on which is passed? (Most common solution)

Why are handlers named by what they will return?

If we are writing functions which are handling incoming T messages, why are using their R message names for the function names?

For example: When receiving a Tattach, why is rattach called instead of a "tattach" function, and returning Rattach message?

Maybe there is some good reason but I don't know :)

Client Support?

Would you have any interest in incorporating client support into the library?

Incorrect errno depending on platform

errno values are not consistent across platforms - to convert for other platforms you would need to copy paste the linux errno codes and do a translation.

Stop using try_trait

It would be nice if this worked with a stable Rust version, rather than nightly.

I may open a PR.