Fwd: [rust-users] Reviewer for a sandboxfs rewrite in Rust

[Taylor Cramer]

FYI

---------- Forwarded message ---------
From: Cliff L. Biffle <cbi...@x.team>
Date: Wed, May 16, 2018 at 1:55 PM
Subject: Re: [rust-users] Reviewer for a sandboxfs rewrite in Rust
To: JP Sugarbroad <jps...@google.com>
Cc: <jm...@google.com>, rust-users <rust-...@google.com>

I'd be interested in taking a look as well.

On Wed, May 16, 2018 at 1:46 PM JP Sugarbroad <jps...@google.com> wrote:

I'll take a look for you. :)

On Wed, May 16, 2018 at 12:50 PM Julio Merino <jm...@google.com> wrote:

Hello all,

For a few months already, I've been writing a FUSE file system in Go called sandboxfs. This file system offers an arbitrary view of the host's file system under the mount point and allows for "dynamic" reconfiguration. You can read more about the motivation behind this and what it does in these two posts:

https://blog.bazel.build/2017/08/25/introducing-sandboxfs.html

https://blog.bazel.build/2018/04/13/preliminary-sandboxfs-support.html

But a month ago, I decided to learn Rust and, in order to apply my new skills, rewrote sandboxfs in Rust. I have now a mostly fully-functional replacement that passes the same test suite.

The main reason behind this exercise was to compare performance between the two implementations because the Go variant ends up spending a lot of CPU time in the Go scheduler. The results have been impressive, both in code sanity (I've caught multiple potential bugs in the Go code during the rewrite thanks to Rust's strictness, and I just trust the Rust version much more) and in performance: the Rust implementation performs better than the Go one even before any kind of profiling or optimizations.

So question: is anyone interested in reviewing this kind of code (a file system)?

What I've written so far is a prototype and cannot be reviewed. But if I have a taker, I can start cleaning up the pieces to make this decent. (Needless to say, this is pretty much my 20% project at this point so progress will be slow, and you have to understand I'm a newbie ;-)

Thanks!

PS: Now... I'd be lying if I didn't disclose that I've found the source of the slowness in the Go version: the use of goroutines: removing all concurrency makes the Go variant similar to the Rust one in performance, but the Rust one still beats it. And considering that the Rust variant hasn't been optimized at all yet, I'm confident it can be made even faster.

--

Julio Merino / go/jmmv / Blaze

--

Cliff L. Biffle  is building something at x.company