Date: Tue, 21 Apr 2026 10:44:39 -0600 From: Alan Somers <asomers@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-testing@freebsd.org Subject: Re: pjdfstest integration Message-ID: <CAOtMX2i6mDQCpsSWzyzkjE6WuWHsrgcXcWwr4MZZ127Bm-_d_A@mail.gmail.com> In-Reply-To: <aeeorhK4k3TbmBdX@nuc> References: <aeeTmlUluD6y3VnH@nuc> <CAOtMX2jzUa56nOdnX7Yn4Rs%2BG0U3p1qSs2uA_V_pOKcoesHtyw@mail.gmail.com> <aeeorhK4k3TbmBdX@nuc>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2i6mDQCpsSWzyzkjE6WuWHsrgcXcWwr4MZZ127Bm-_d_A>