Received-SPF: pass (google.com: domain of linux-nfs+bounces-2280-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 13 Mar 2024 03:20:52 -0400
From: Jeff King <peff@peff.net>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org,
	linux-nfs@vger.kernel.org
Subject: Re: t0032 fails on NFS mounts
Message-ID: <20240313072052.GC125150@coredump.intra.peff.net>
References: <ZfBwZTL9zqDsac5m@manet.1015granger.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZfBwZTL9zqDsac5m@manet.1015granger.net>

+cc Patrick for reftable

On Tue, Mar 12, 2024 at 11:10:29AM -0400, Chuck Lever wrote:

> Unit test t0032 fails when run on an NFS mount:
> 
> [vagrant@cel t]$ ./t0032-reftable-unittest.sh 
> not ok 1 - unittests
> #	
> #		TMPDIR=$(pwd) && export TMPDIR &&
> #		test-tool reftable
> #	
> # failed 1 among 1 test(s)
> 1..1

The output for this test script is particularly unhelpful because it's
not using our test harness at all, but just running a bunch of internal
tests using a single program.

Running with "-v" should give more details about what's failing.

I set up a basic loopback server like:

  mkdir /mnt/{server,client}
  exportfs -o rw,sync 127.0.0.1:/mnt/server
  mount -t nfs 127.0.0.1:/mnt/server /mnt/client

and then ran:

  ./t0032-reftable-unittest.sh --root=/mnt/client -v

Looks like it fails at:

  running test_reftable_stack_compaction_concurrent_clean
  reftable/stack_test.c: 1063: failed assertion count_dir_entries(dir) == 2
  Aborted

> v2.43.2 seems to work OK.

For me, too. Bisecting shows the problem appearing in 4f36b8597c
(reftable/stack: fix race in up-to-date check, 2024-01-18).

-Peff

PS That test seems to run ~20x slower on NFS versus directly on ext4.
   I'd expect a little overhead, but that's quite a bit.