On Fri, Dec 27, 2019 at 12:41 AM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Thu, Dec 26, 2019 at 17:02:21 -0500:
> > (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).
Yes, it's kind of dumb to sync to a ramdisk. I'll play around with
eatmydata and see how much of a difference it makes in execution time.
Maybe I'll use that when I'm in a hurry. The full test suite with all
RA and backends took nearly 2.5 hours. I didn't know about eatmydata.
Thanks for mentioning it.
> > 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.
I'll give it a try. I have to study how the makefile invokes the
regression tests.
There is a variable THREADING in the makefile; it defaults to yes and
activates threading and thread-safety stuff in apr, gettext, ruby, and
sqlite. It has no effect on the Subversion build or tests.
Nathan
Received on 2019-12-27 21:39:34 CET