In D55362#1364561, @ayushjayaswal.connect_gmail.com wrote:

Hi @asomers

What should I do next for this patch?

The 2026 Capsicumize FTS project is complete. In 16.0-CURRENT there is now an fts_openat function. Hopefully it can be used to finish this port.

Other than that inline comment, this LGTM. Thanks for fixing it. Do you need me to commit it for you? I can do that, after you address the one remaining comment.

• Don't heap-allocate a std::vector
• Use mount_fusefs with memfs

@arrowd what do you think of this? If we merge it, then we can eliminate my depedence on fuse-ext2 and your dependence on fuse-hello.

In D56165#1334631, @kib wrote:

In D56165#1334568, @asomers wrote:

In D56165#1285144, @kib wrote:

As was discussed elsewhere, fuse server which times out the responses could cause lock cascades in VFS. This would have global consequences for the whole system.

Until the vnodes are locked around communication with userspace, I do not think this change is appropriate.

I think kib means "unlocked around communication with userspace". But I do not see how such a change could possibly work.

Fuse needs to make some way to ensure liveness of the inode (not vnode) around calls to the userspace.

In D56165#1285144, @kib wrote:

As was discussed elsewhere, fuse server which times out the responses could cause lock cascades in VFS. This would have global consequences for the whole system.

Until the vnodes are locked around communication with userspace, I do not think this change is appropriate.

LGTM

Respond to @markj's latest comments

The new dtrace probes are just to help develop these test cases. I'll remove them before I commit.

• Convert tests from sh to C++
• Fix a mutex recursion panic

In D56605#1321861, @ngie wrote:

This version of pjdfstest requires a pjdfstest user, which we currently
don't have. The current plan is for the pjdfstest package to create the
user upon installation.

What about just using the tests user in the upstream port?

% id tests
uid=977(tests) gid=977(tests) groups=977(tests)

In D56605#1321860, @ngie wrote:

Dang -- not bad. Are there any known data creation races that need to be managed in the Rust implementation? How much "tire kicking" has the Rust version gotten so far? How about A/B test code coverage from the kernel?

In D56605#1321843, @ngie wrote:

I'm sorry -- y'all are right about the 2 implementations being able to coexist. 15 seconds is really short, but that's done on an in-memory filesystem, whereas our tests are run on physical device/virtual compute (so vSphere, etc) backed devices with a WITNESS/INVARIANTS enabled kernel (runtime is ~10 minutes). I'm not sure what the kernel options were for the 15 second run, but regardless, it would probably be at least an order of magnitude longer than the runtime for the new pjdfstest implementation.

In D56605#1321359, @ngie wrote:

It's a regression for folks that use the tool in-tree as-designed because:

1. The existing tool does not support the configuration format required by the rust tool. Execution is driven by prove/kyua .

In D56605#1321284, @ngie wrote:

In D56605#1321277, @asomers wrote:

...

It's all yours: https://github.com/asomers/py-pjdfstest .

Thank you!

Also, I want to caution you that Python has an additional handicap: it's C interface is much more awkward than Rust's. The Rust standard library is simple enough that for many things, we use it directly to test the file system. And for other stuff, it's pretty easy to call Rust's libc bindings. But the Python version needs to define a Python-C interface for pretty much everything that touches the file system.

Yeah, the CFFI part is kind of annoying, but it's a part of the joy of doing C bindings in python, unless you have a thing for SWIG or doing everything with the raw python-C APIs *shudders*.

BTW, what version of Rust is OneFS stuck on? If it isn't too old, we may be able to make pjdfstest work on it.

1.74.1, which was released in 12/2023. I don't honestly know if you want to deal with that pain :(.

In D56605#1321251, @ngie wrote:

I can't get into details too much, but yes.. ~12 hours if I'm lucky because it has to bootstrap using the stage 1 compiler instead of rebuilding everything with the stage 2 compiler (which FreeBSD can do).

In D56605#1321232, @ngie wrote:

This forces all end-users of pjdfstest to build/install the new rust application/binding instead of the simple C application in tree. I would argue that's a regression.

Dell is stuck on an old version of rust for various reasons and upgrading the builder image/toolchain requires a proverbial act of Congress (I love that compiling a new toolchain requires a builder host with 768GB+ of RAM/12 CPUs in order to get the operation done sometime within a day of when operation is started). This is part of the reason why I wasn't on the bandwagon of adopting rust in everything in base, despite the fact that I really like rust as a language in concept.

In D56605#1321232, @ngie wrote:

This forces all end-users of pjdfstest to build/install the new rust binding instead of the simple C application in tree.
I think it would be a good idea to add a build option to build/run either one or the other. Otherwise, some consumers will be broken by this change because not every has access to the rust toolchain.