Benchmarking Rust Coreutils and the RapidFile Toolkit

Recently, I became aware of a very exciting open source project that aims to reimplement the GNU Coreutils entirely in Rust. As far as programming languages go, Rust is one of the more exciting developments of the last decade. The goal of Rust is to provide a high-performance, memory-efficient programming language while offering guaranteed memory safety and thread safety. Programs written in Rust therefore avoid one of the most common classes of bugs and security threats: memory mismanagement that results in overflows or use-after-free scenarios. These types of bugs can lurk undetected for years, and once discovered, provide bad actors vectors for exploitation. In the era of large language models (LLMs) scanning code repositories for issues, more and more of these types of bugs are being found, even as recently as this month (April 2026).

So it’s extremely exciting to see projects like Rust-Coreutils looking to rebuild essential pieces of the GNU ecosystem in Rust to eliminate this class of flaws from being exploited in the future. However, the development team is also focused on performance improvements to many of these core utilities. Very often, the original GNU tools were written before symmetric multiprocessing (SMP) was commonplace in systems, and thus are highly serialized processes that scale poorly on today’s modern hardware.

Everpure ran into this same challenge back in 2017 when we introduced FlashBlade®. We found that the metadata performance of FlashBlade was so great that the bottleneck in many workflows was the serial nature of these core utilities. That’s why we built the RapidFile Toolkit, a subset of Linux coreutils designed to be highly parallel and run in userspace to improve performance by more than 20X.

So I was curious to see how these new Rust-coreutils compared to what Everpure has implemented in the RapidFile Toolkit. To be fair up front, both the goals and scope of these two projects are very different. In a pre-nconnect world, our goal was to specifically speed up certain kinds of operations over NFS mounts, leveraging userspace libraries like libnfs. The scope of Rust-coreutils is much more broad, and performance improvements are not the top priority.

Nevertheless, I wanted to satisfy my curiosity about whether the amazing work of the team building Rust-coreutils made the RapidFile Toolkit obsolete.

The test environment

The data set I used for my experiments was the latest Linux 7.0 source code tree. All tests were performed on a single-chassis FlashBlade//S500 system with a single Oracle Linux 8 host connected over NFSv4.1. Due to the nature of the data set (many small files, very deep nested directories), throughput was never the bottleneck in this test. This is entirely a metadata and host-CPU benchmark. I utilized Rust-coreutils version 0.8.0, and the RapidFile Toolkit was version 2.1.1.

Since I was benchmarking the Rust-coreutils binaries, I also used their recommended benchmarking tool hyperfine, which you can find more details on in the tutorial. I intentionally wipe the OS VFS cache before every run in order to benchmark from a “cold start.” 

The results

Listing files

Of course, the first test I ran was a recursive ls command. Here are my results from the following:

Here, we see that while Rust-coreutils performs the same job in about a third of the time, it pales in comparison to RapidFile Toolkit, which executes it in less than 5% of the time (or more than 20X faster). Also of note, the RapidFile Toolkit spent significantly more time in userspace than the other two runs, indicating that it’s using its accelerated userspace NFS implementation across many cores to reduce the effective wall-clock time.

Measuring disk usage

Next, I ran the du utility to list the size of every folder in the directory tree.

Here, with du, we see almost no difference between the GNU coreutils and the Rust version. However, we see a decrease of more than 10X when using RapidFile Toolkit.

Copying files

This was an even more interesting result. Unlike the previous two tests, here, the Rust-based cp was significantly slower than the original GNU tool. Meanwhile, RapidFile Toolkit continues to clean up with a significant lead over the other two tools, performing 24X faster than the GNU tool and 48X faster than Rust.

What was more interesting was what I saw when I started looking into why the Rust copy might be slower. First, I verified that the FlashBlade was seeing 16 client connections at the same time and each one was pushing similar IO numbers, confirming that the Rust tool was leveraging all the TCP sessions afforded by nconnect. I also noted that the average IO size between both tools’ runs was not materially different, ruling out a block size issue (which makes sense considering the small size of the files in the data set). But when looking at the IO performance of the system, I saw that metadata IOPS (what the UI here calls “Other IOPS”) were significantly higher than with the default tool, despite the run taking longer by wall clock.

I dug deeper by looking at specific RPC calls that were different between the two runs, and the Rust run showed a significant threefold increase in OPEN4_GETATTR RPC calls, and also a significant number of SETATTR4 calls (which weren’t present at all in the GNU cp run). So it seems that Rust’s Copy command isn’t yet as well optimized for this exact use case as the GNU tool.

Meanwhile, pcopy finished the 10 iterations in less than half the time of one run of GNU copy.

Deleting files

Lastly, I wanted to test deleting the source tree folder.

The fourth row there is a bit tongue-in-cheek, as Purity//FB includes a feature called Fast Remove, which lets you remove entire folders by just moving them into a hidden .fast-remove folder. As you can see, this is even faster than prm and requires only 1 RPC. But I won’t bother charting it here:

Here, we don’t see a meaningful difference between the C-based and Rust-based tools. But we do see an almost 50X improvement going to RapidFile Toolkit.

Conclusion

So what did I learn from this exercise? First, it’s very exciting that in most of the cases I tested so far, the Rust-based tools are equivalent to or outperform their C-based counterparts. Once the Rust-coreutils achieves full feature parity, I’m hopeful that we will see more adoption of these as the default tools in the future, not necessarily for performance reasons but for safety ones.

Second, RapidFile Toolkit still provides a meaningful uplift in performance for operations that it supports. I was curious if RapidFile Toolkit had become obsolete, and clearly it hasn’t. But coreutils includes dozens of commands, which RapidFile Toolkit doesn’t make any attempt to replicate. So even for customers using RapidFile Toolkit, there’s merit to looking into adopting the Rust-coreutils alongside RapidFile Toolkit.