Re: pjdfstest integration

> On Apr 21, 2026, at 9:44 AM, Alan Somers <asomers@freebsd.org> wrote:
> 
> On Tue, Apr 21, 2026 at 10:41 AM Mark Johnston <markj@freebsd.org> wrote:
>> 
>> On Tue, Apr 21, 2026 at 09:41:31AM -0600, Alan Somers wrote:
>>> On Tue, Apr 21, 2026 at 9:11 AM Mark Johnston <markj@freebsd.org> wrote:
>>>> 
>>>> Hi, I noticed that we install pjdfstest to /usr/tests/sys/pjdfstest,
>>>> but:
>>>> - it's not hooked up to the test suite, i.e.,
>>>>  "kyua test -k /usr/tests/Kyuafile" doesn't run it,
>>>> - contrib/pjdfstest doesn't seem to be updated regularly,
>>>> - the configuration is hard-coded, i.e., I can't easily run it against a
>>>>  filesystem of my choice.
>>>> 
>>>> How hard would it be to parameterize the tests so that we can run the
>>>> tests again a list of filesystems?  For each filesystem we'd have some
>>>> little script that sets up some scratch space, creates an empty
>>>> filesystem and points pjdfstest at it.  In some cases we'd need the test
>>>> runner to specify some additional variables, e.g., for p9fs you want the
>>>> test runner to provide a share, as we currently only support the virtio
>>>> transport.  I'm not sure if kyua can pass variables to a TAP test, so
>>>> the solution might be to wrap each pjdfstest run with an ATF test case
>>>> which handles the setup.
>>>> 
>>>> Is anyone interested in working on these things?
>>> 
>>> Yes, yes and yes.
>>> 
>>> I was indeed working on a change to pjdfstest which, among other
>>> things, would read a config file for each file system under test.  The
>>> config file specifies things like whether posix_fallocate is supported
>>> on that file system and which file flags are supported.  The change
>>> also drastically speeds up pjdfstest's runtime.
>>> 
>>> We did that as part of GSoC 2022.  The status of the project is that
>>> it's 99% complete, but requires somebody to comb through 4000 SLOC
>>> line by line to make sure nothing got left out.  That's very tedious,
>>> which is why nobody has done it yet.  I would LOVE to get it finished,
>>> but I've never made the time.
>>> The rewrite also relies on some ugly macro syntax.  We did that
>>> deliberately to save time, but it does make the code ugly, and a
>>> little bit harder to review.  It might be worth investing the time to
>>> rewrite those macros more cleanly.
>>> 
>>> Using the new pjdfstest, it would be quite easy to add an ATF test for
>>> each file system.  atf-sh would format the file system under test,
>>> then call pjdfstest with the appropriate per-filesystem config file.
>> 
>> Do you have a pointer to this work anywhere?  I can't promise to
>> complete it, but I'm pretty motivated to stand something up for p9fs.
> 
> It's at git@github.com:musikid/pjdfstest.git .  What do you think is
> the best path forward?  I could publish a 0.1 release now, and get
> this into ports, while you work on the ATF part.  Then we could slowly
> open a series of reviews that delete the old sh-based stuff.

What musikid did was a good effort, but it would make pjdfstest into a purely FreeBSD test suite since many other platforms don’t come with ATF installed on them; the project currently supports Solaris (to a lesser degree) and Linux (we still get pinged from time to time about Linux-related support requests).
-Enji