From nobody Wed Apr 22 22:27:08 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 4g1DP63cVnz6ZyP2 for ; Wed, 22 Apr 2026 22:27:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g1DP61g53z3Rys for ; Wed, 22 Apr 2026 22:27:22 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-676e62faf2bso2574489a12.1 for ; Wed, 22 Apr 2026 15:27:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776896840; cv=none; d=google.com; s=arc-20240605; b=NGd82yrq3zQkCkjLrV9aRkQ1Jjutl+5rkoFDm2uOj1i44fz7tnQvoYSF8RVrjaJ94t zHpKKhOndi2wH65eh/3P+X2UC2XTpxvoQ4IIUV5dCQj/EnzaxiK2xb6o0X+8Cc/pn4eO fclzg7Yv5ToAbDHjnmGKL0nHQWjuYwFGPBd8J2/eIDqaU3AAGfAf0ynWX756O+AWxYND 0cvolhGCa3TM84eLCtl1QVT/7uMdWUJK5D+gTybD22rVAg/kQFmJk9YU5NFn+8yZEIB2 JUhYtdasdpfOyceg99x5999OQbkM24VAeQgNvyipBLA98qAqxmLiVpcu1RC5cuNjRMq9 HB3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=moCt8NlHGwB77u5K+eokJUcwlOsMyiuuO8bfPIf/JZk=; fh=PQPw1mCwQriwC61i4/6EVcEgbLxf4fHtKP5V2bgwYVk=; b=HHCqb3+rQz+P1ew5qXw251HB15IQQUGJ1hR8Ly0jhFq4ZBVLpG0pal+o9FZ7PuBNpZ SIqeVgCN3hvA8rMMrFqygi3243ju1C0KrnBbbAYnnAPi+McsY5uCbKhWFKbRlr/7c/pG 7yCyi4bMbo3x5S8zLQoXGPuVg0av9qVKHV+JsVQ42Efu9En4AcUmWH4EXMbvZZe65wwv SZWp2qmXIxBpaIPeglEX6GthOwSq2y1UCCG/Svkl06zMv9fjI+gq4esGSYwi+bxxr/WT /it5aYYtekXCGMpAMZ5n+qgLQx1pydK6Bp5zu1QaFDEUDOsqvWC0ezVoC2cnqJ9uFVV9 f0OQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776896840; x=1777501640; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=moCt8NlHGwB77u5K+eokJUcwlOsMyiuuO8bfPIf/JZk=; b=C4+kdUXFowPTB/TkjTTCRt+a8aobRle+GkEUpGLFkbVqIiWUEAKVG0Rn53fIYijaiM ndDk9Xq5vA9YnFa0kIScziuveJkXHT8fyrZjkbDH4hvfa6d01z64JFOGImeAOYX1NsIE IZY7kwsY6/lpdI6756Tl1UY4Yd4apGk2J1lxrxzoi7uB2iiPtCS0l9zpP9YTnmJHiILd sET+WU6WUuOlzvaoo25f8fvP/uJDVDFRJzEWx42jUnF5SVAFBHbr2+HQD0ZJ5K9m+aAH /BVvaqKQDO4Gj+XUfOBx1KGVRCQcb/zFwg+GQq5q1QjZWXzenBymGUwLCNGylil8rkxh 43Pg== X-Gm-Message-State: AOJu0YzJGYvOcjORherGxuG+WhWsqBoMhkF/kq1sH84mMyl/lIE4OD5r TL9hBeQAciV3nQrbaPmnehP8SEQMKU95Bs29rS6PbAKHRKzreTzGIXV7tAIi6kCKXDnba9GKcSj ty6qqHDliW2YWtYZlxWQGltK2zxGEbXM= X-Gm-Gg: AeBDietfC2dhpiH+yS+5JWRC4v0K93HU52ok60aLEFR5U/kXW3Xa35iNoYP1IHnYF/q L8CpaZLO2hluv7pdax5SA6BEm2MuwfVag2f+WUAdGgh64p7a5y8Fd8HhE06jJVIURbBFX112G8H buqQcfmhVRUOYrEgiI2OmSj7RE/lLcauLdWQZzAdLEY5RqhsNxVl8HU8wc0go+TwrqCBThj6No7 2LuyFUyrYdsJoSNPlhUBJBjGEviPu9Jp0EkNnrh+KGYiAI6jpCGjwzAndvKiJ4bAzgmFcDeQ5KI dMErfu2NrTjG5HwesTr7m8zXZ9DFxYVQrVpWl7S3oduWa3DR4AHYpfj8P26HtI6omuq0csw10wR 6hDlFHoATwSas8w== X-Received: by 2002:a05:6402:a54e:10b0:669:cc03:334a with SMTP id 4fb4d7f45d1cf-672bfd9db0dmr8657003a12.11.1776896840362; Wed, 22 Apr 2026 15:27:20 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Wed, 22 Apr 2026 16:27:08 -0600 X-Gm-Features: AQROBzCp1MZgVKgWUtPHEFnWiZo4RI2eDrt1LdhruSLiFVGTwOCIAxRvQn1xSCY Message-ID: Subject: Re: pjdfstest integration To: Mark Johnston Cc: freebsd-testing@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4g1DP61g53z3Rys X-Spamd-Bar: ---- On Wed, Apr 22, 2026 at 3:43=E2=80=AFPM Mark Johnston w= rote: > > On Tue, Apr 21, 2026 at 10:44:39AM -0600, Alan Somers wrote: > > On Tue, Apr 21, 2026 at 10:41=E2=80=AFAM Mark Johnston wrote: > > > > > > On Tue, Apr 21, 2026 at 09:41:31AM -0600, Alan Somers wrote: > > > > On Tue, Apr 21, 2026 at 9:11=E2=80=AFAM Mark Johnston wrote: > > > > > > > > > > Hi, I noticed that we install pjdfstest to /usr/tests/sys/pjdfste= st, > > > > > 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 ag= ainst 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 t= he test > > > > > runner to specify some additional variables, e.g., for p9fs you w= ant 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 suppor= ted > > > > 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 tha= t > > > > 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 tediou= s, > > > > which is why nobody has done it yet. I would LOVE to get it finish= ed, > > > > 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. > - 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. 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. -Alan