On Fri, Dec 27, 2019 at 12:41 AM Daniel Shahaf <d...@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
