From nobody Thu Apr 23 17:40:34 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 4g1k070J9wz6bBtj for ; Thu, 23 Apr 2026 17:40:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4g1k063wltz3MGf for ; Thu, 23 Apr 2026 17:40:54 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-671c5eb7fb0so8577314a12.3 for ; Thu, 23 Apr 2026 10:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776966047; cv=none; d=google.com; s=arc-20240605; b=IYisDHgXHOBqfAqBNZLVJH12BM/Km7mqNknKD/mKWlsjkaexCdBiKFqZAdKdyQa3OD 3Bn9sy7xxVRm7ILZsuXtRYlTX1AVhdDfU04P2NoHjYCTX+7w0BaH32uTExE7t4l82nqN OFRO/sa3r6oQJ9MYb93JmIXg6bdYuPuqPVkfiYNJGuKi/Q8f34CEnr6ZJcRVxorQeIwn GXBamea6S4+sFZZlSN02YRLApRwMBobZpoIPrZMZK2c8JRfydr67wwaxcIICV9ss40lm jgCHJtN+Sn2N8dY31U0EubHaXeYvtOK6Rzz+os9A1zWRVwmDwWB8Aq3hilMXz6TIiif6 THaA== 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:dkim-signature; bh=hozZC3dYnWaZq+5BYoJr6H9AnysjZlzgQPNIzzc7xWA=; fh=74tsVJV2kG4w1nSeB2bYBUwY4eC4dd+v4fIuFboTppM=; b=ZRGNz8kVsfHe/fH+uNFXKrQbjBka6/wG3HNvLr3As7B9dK0OLyLW2JeTnugnW9dDPH M+WuefB+UAPlmDhpUP3Val+lftKP9qILz0e+svD5T3L58voDE9rbSa23FYp/mMDzWYGD vQ8e3ejorO5GRihTW0epCSd2ybSuYD8YWudrD3z3HtvCYMXCaZhciGgE46OeuDbvW5Ug V6stZSBzB0BZay+I9jUCznKhqIUR7Qblr5mtrecfqMrebidIHEfFY4YiyrZLY8fiODHo I+A+fjwhSgsOGSqxa1hJx9621imkUNUtKUAsP4DM/KBtdsut7f7pZGXAqNm8NZZ7RTqp O4QA==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776966047; x=1777570847; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hozZC3dYnWaZq+5BYoJr6H9AnysjZlzgQPNIzzc7xWA=; b=S8b72v5pcJJGUb3VZWbBfIaNRP7UzUS8HPRrkOqMrQNT2O17AcJSYBN7tzNiOWPMQV 49YXFyIfIU1wDvcLgoKE+N3w1B3OPnwFc3bqUQXu8tuLGPoiAV1uXkuNJrYJpaNS2MGP czYFUNd3zDFN+yVb2Gl5oYOQJ7/g8d3dZNpEQRNsgOIqCsQ6abdSMg0XG7N1/VPv9MI3 XQZxQ20M2/1uhiyPTbHbhevnBXIl5DKAxVPcLPHoaDPWoncIV2UF7spv1IzF2x2rGxAi 2+bRFJbx1Vwp7VrNt1xKZ+yohoX5t3o4GjO+2PVj6cSfac3pceu8dmS1DiBTT8BbMWsF HtRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776966047; x=1777570847; 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=hozZC3dYnWaZq+5BYoJr6H9AnysjZlzgQPNIzzc7xWA=; b=sO/x+PU0ih9LqHWR7xwBsFcuFZD4MGDMfT0YprydAqu7ehz7Jg/SSObPCilZO82rgf 5znK7HdAlN08khLi61+MSuGFmiYEHm3PfEaet8JYEw/cR9m4QwKTxq9EX0C6c8Ov0EnT pPaQlqjZyH8D2dY9peHg2wM1Rb6joBW8sfmNY1TkDNSCsO+WAQ+POQn8DPgGTOnqkmka gE+lcx5EyOYyDchqpvP4FTKWau7acdAqjRvlM7zwzG/8VNSJ7htHsvNupVCuR9kNYx69 M2WrU2ucRJMcL+YtUs2qaZuFYoonbpuWHWZkWfhHvmIGtBrmtjohAF80nFLgBCCueyZC SY8w== X-Forwarded-Encrypted: i=1; AFNElJ+B57pTaUsBYn0jqa0ultpeiML2tc4y2kR9+r+o+mR8bvpInSCS4qbmxmHODkjMZxgGF9yyTDYacj8ff05Mark=@freebsd.org X-Gm-Message-State: AOJu0Yx9QAcdfwUJKhVl2njw60PPktcTGjnNXoOkEEc1/j5CaDp9oIWn qJvNvZSE5m4xd/EJlqOqJWVSpn62no6rpjjzCDSIkbc9MGL/J8KQLpbWETELHM7RzgeDg3nnPNX azampkjEGJ3SropU1yHJJQQKVmIkIPMY= X-Gm-Gg: AeBDiesTCMRRsetbTUWqtqGq25yIMElGHyAqB9mT0nj3swnL2Nt2aBQGVhVugCObVYm 4PqHRQVLE37Pnveyu/ad4x8N1UxjSj4Nak/z2xuhKFMlelz0ktRbj6/I9bk1kGDFHSSB7ha7Pea j8Qt7/yuL9ObfAIEfMARgiJvblJ0O1D866w7tUmxhxNalV/BWc3ytToyA59wv0MOjGasxD477nG W2JHMoM7eq4cftZgCJf33DiYaw2op0NBt0IIBK++JMhRsaHsf48RbkhFI4ScHetpOSx5V3VXTWb vjCjJj8qQ37XPbgG7UMlq9kd9UZXq4mNQC2IxOXoowI7tu4JDy7Xw8k+YcnxTcCcQ88lyo1W4HW K+x8= X-Received: by 2002:a05:6402:22dc:b0:674:2565:f27a with SMTP id 4fb4d7f45d1cf-6742565f5cemr7296014a12.19.1776966047121; Thu, 23 Apr 2026 10:40:47 -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: Thu, 23 Apr 2026 11:40:34 -0600 X-Gm-Features: AQROBzCMjiAyWV8vrlzV5hOJUzPWaTUoaGXDy1HSEIlylqD_mk4uLHjuhXSQ4D4 Message-ID: Subject: Re: pjdfstest integration To: Mark Johnston Cc: Alan Somers , 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4g1k063wltz3MGf X-Spamd-Bar: ---- On Thu, Apr 23, 2026 at 11:05=E2=80=AFAM Mark Johnston = wrote: > > On Wed, Apr 22, 2026 at 04:27:08PM -0600, Alan Somers wrote: > > On Wed, Apr 22, 2026 at 3:43=E2=80=AFPM Mark Johnston wrote: > > > > > > 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/pjd= fstest, > > > > > > > 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 i= t 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 emp= ty > > > > > > > filesystem and points pjdfstest at it. In some cases we'd ne= ed the test > > > > > > > runner to specify some additional variables, e.g., for p9fs y= ou 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 othe= r > > > > > > things, would read a config file for each file system under tes= t. The > > > > > > config file specifies things like whether posix_fallocate is su= pported > > > > > > on that file system and which file flags are supported. The ch= ange > > > > > > 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 S= LOC > > > > > > line by line to make sure nothing got left out. That's very te= dious, > > > > > > which is why nobody has done it yet. I would LOVE to get it fi= nished, > > > > > > 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 t= ime to > > > > > > rewrite those macros more cleanly. > > > > > > > > > > > > Using the new pjdfstest, it would be quite easy to add an ATF t= est for > > > > > > each file system. atf-sh would format the file system under te= st, > > > > > > 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 p= 9fs. > > > > > > > > It's at git@github.com:musikid/pjdfstest.git . What do you think i= s > > > > 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 slo= wly > > > > 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 hav= e 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 whethe= r > > > 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. Yes, a few tests do need two unprivileged users. For example nfsv4acl::chown::gid . But it doesn't have to be named "pjdfstest". In addition to "tests" we could probably use "nobody" or "tests2" or something. > > > > - 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?