From nobody Thu Apr 23 17:05:00 2026 X-Original-To: freebsd-testing@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4g1jBl1Dd5z6b7YQ for ; Thu, 23 Apr 2026 17:05:03 +0000 (UTC) (envelope-from markj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g1jBl0cQCz3CjP; Thu, 23 Apr 2026 17:05:03 +0000 (UTC) (envelope-from markj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1776963903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5+yl7b3VHX8TU9dJ3WX9laihMUZno/6pPWWZEjxF9+g=; b=ry8TdTl5PIqoG5Kqoy1jlzPoW01c0DXxiZWL2Y400hJ5z/h2p6gG0pGsfCpBR4smEU/H2M 2QlcS1MVQOFQCmjb1umFlcoxD8V2RWkdUg0AXX0j9lL+h7Z0KIj8O9OfrMvN7Oi7/Veun9 BufO9UGEDzjKqaKnOMuuCTFAbKRnPGSVZkpUodg5SfLdGu+8I4mMz8m9rYxYbKvh++J+Oi tvKPs4ZO0okiYPxycQsFtWMFSBz2r5EUb6cgITrT521fCJ40YR9G7aL/9mepOcSnFPWAAg +TDPGX34vpyijd65rBABLyAdzcfcOCl1kYjc9Kd/+5VNNaSjo4L3NSW5vS04kA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1776963903; a=rsa-sha256; cv=none; b=BQFsxtNWw2VBhdv2HvRoL3xercyG3Nh8F0B1cS9XnNbZREr+/8pv22cxRrrH+2q0E7xIYd FHWha16+0AvWEpDtw6kaHgsZ25AYbf0VcGdLvasXdJzRj5OkqXmKadp8MyG831lZsk99jB MwzsnLKoaKC6I3YPbesRHXFiQd8SVT+sDmJy6Uas13epB1ID5Z6ADWjH+dPdEdIwqXvnM/ nm1Xfhtggwne4YMrGsH4Zb9m8tQ5zYFPfPi2KMZPkJKdd/bR//OBHYcKYsi1RQYiuTnF2P UcH+Y0E7qZTU2gvSaHqGlZfHanXHSGXo/yBxsGD0YFZMG/IoWfu9nHFc3sDWzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1776963903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5+yl7b3VHX8TU9dJ3WX9laihMUZno/6pPWWZEjxF9+g=; b=aEeQRALeXPdDO47EzTxPWwOQPa/y527XEs0/YH9Ngk2OXbuwVfHrAeyzp7vn9fIhEJOXRC uoD7grS+Mvqj5rOpTQQOcZNCt/BxRKiUhPtLMRfwqb4a3+FzE8FDpa5K7fli9csOY/qiEI cBv9fnYxZRcNTCTATAm9ArHp0rbktFtpGCjXUGGGvi8Va1rOp3HmzpREko6uNKxfGHiw+l 0lUbkayREI59/++V7ZW+y/yrdZ9ZsNAGKUGfOyHWKzb7E53TOnYbN9rwsFTNCuBCPS3BGN S6pDSvEjG5zv7E3e7umGSsduSjEYxSWaEAluSyIdMv6uK/ZYmvq27oGS+VNDig== Received: from nuc (192-0-220-237.cpe.teksavvy.com [192.0.220.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: markj) by smtp.freebsd.org (Postfix) with ESMTPSA id 4g1jBk5t2rzySv; Thu, 23 Apr 2026 17:05:02 +0000 (UTC) (envelope-from markj@freebsd.org) Date: Thu, 23 Apr 2026 13:05:00 -0400 From: Mark Johnston To: Alan Somers Cc: freebsd-testing@freebsd.org Subject: Re: pjdfstest integration Message-ID: References: List-Id: Testing List-Archive: https://lists.freebsd.org/archives/freebsd-testing List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-testing@freebsd.org Sender: owner-freebsd-testing@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Apr 22, 2026 at 04:27:08PM -0600, Alan Somers wrote: > On Wed, Apr 22, 2026 at 3:43 PM Mark Johnston wrote: > > > > On Tue, Apr 21, 2026 at 10:44:39AM -0600, Alan Somers wrote: > > > On Tue, Apr 21, 2026 at 10:41 AM Mark Johnston 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 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. > > > > That sounds fine to me. I'm not really set up to review the > > implementation, but I'll try writing some integration scripts. I have a > > couple of questions though: > > - Do you know of any requirements on the filesystem under test? > > Specifically, how big does it need to be? I'm wondering if we want to > > use md(4) disks to provide the backing store for each FS, or whether > > we should rely on the test harness to provide some raw devices. > > Puny. I just ran it on a 16MB UFS partition and it worked fine. Cool. Here's some simple ATF integration: https://reviews.freebsd.org/D56605 All of the tests except the UFS1 one pass for me, some comments are in the review. I think the main obstacle is the need for a new test user: why does pjdfstest need two unprivileged users? It's already using the "tests" user. > > - I noticed that pjdfstest (both old and new) don't seem to execise > > getdirentries(2) at all. Is there any particular reason for that? > > I doubt it. Probably PJD just never got around to writing any. > Although, pjdfstest probably isn't the best way to test > getdirentries(), as there are lots of corner cases that you can't > reach without knowing a file system's internals. But it would still > be nice to have. Yeah, I started looking into this since I have some local modifications to p9fs' VOP_READDIR implementation, and I wanted to make sure they get exercised by the test suite somehow. > BTW, here's a related test I wrote but never committed. It sets up a > tmpfs file system using the code in > ./contrib/netbsd-tests/fs/tmpfs/h_funcs.subr and runs fsx on it. Like > pjdfstest, fsx is file system agnostic. Ooh, that'd be nice. I wonder if my patch should be generalized to allow running other test utilities?