Nathan Hartman wrote on Thu, Dec 26, 2019 at 17:02:21 -0500:
> On Thu, Dec 26, 2019 at 12:04 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > > Here are the contents of fails.log.svn-check-svn-bdb -- could be some
> > > kind of fluke? I just started another full test run. Let's see if it
> > > repeats:
> >
> > It's _possible_ that some dependency upgrade introduced a heisenbug, but
> > Occam's razor says it's more likely to be something in your setup. I guess
> > svn-test-work is on a ramdisk, so it could be its mount options.
>
> Hmmm. I reran the tests (same sources, with r1866425-rework-patch
> applied). This time all the tests passed, including autoprop_tests.py
> #7 for svnserve x bdb.
The test failure was in the bowls of sbox.build(), in the part that's run for
the vast majority of test functions. It's fairly likely that it had nothing to
do with that particular test function and test file.
> Both times, I ran everything under a ramdrive, which is mounted with
> rw,relatime:
>
> $ cat /proc/mounts | grep ramdrive
> /dev/sdb1 /home/nate/ramdrive ext4 rw,relatime 0 0
>
> (If you're wondering about /dev/sdb1, it appears to be a regular disk,
> not a ramdrive, because this is a virtual machine and the ramdrive is
> a disk image in RAM on the host. This allows it to persist through
> reboots of the guest, moved to other guests, etc).
But if the guest's kernel sees an ordinary block device, it'll still try to
sync(2) it, won't it? I wonder if you'll see any benefit from eatmydata(1).
> I don't know why the test failed before. Could be timing or something
> else happening on the computer? As I continue experimenting, we'll see
> if it fails again... I'll keep everyone posted.
Forgot to say this earlier, but you might try running a threaded svnserve. In
plain trunk that's «make svnserveautocheck THREADED=1»; I don't know how to do
that in stsp's distro.
Cheers,
Daniel
Received on 2019-12-27 06:41:59 CET