Badger: Couple of test failures due to mmap changes

[deepakjois]

This seems to be happening because the AppVeyor instance does not have enough virtual address space to map the value log. I am guessing this should not prevent Badger from working on a Windows machine with enough RAM, but I don’t have one around to test.

[fjl]

Maybe it could fall back to file IO in this case?

[deepakjois]

This seems like a problem specific to the AppVeyor instance, and may not happen for users trying out Badger on Windows. But I don’t have a Windows machine with me at the moment, to confirm.

Moreover, falling back to File I/O would also mean maintaining two different code paths. Windows is not a primary target for us at the moment. We try to make sure that the code builds so that people can try out Badger on that platform. Maintaining a separate code path with File I/O fallback just for Windows doesn’t sound like a great option.

Hopefully, we can figure out a workaround to get the build fixed.

[manishrjain]

We could set the max value size to be the same as the size of log file (a parameter in options). Then we can set the write mmap to be twice the size of the log file. That way, we know that we won't exceed that limit. And it would also work on Appveyor.

[manishrjain]

IPFS is failing because of this. Let's fix this asap.

[deepakjois]

I don’t have a Windows machine, so I am using AppVeyor as a remote build bot to investigate. I created a small project. Here is the build history.

• When I mmap the file with it’s exact size, it works fine.
• When I mmap it with math.MaxUint32 or 500*1024*1023 (500MB), it fails.

There is probably an issue in the way we mmap on Windows. This code was probably never actually exercised on Windows (in the tables package we load to RAM by default).

I will investigate further.

[deepakjois]

So after a lot of trial and error, I made some changes which work well in my test project replicating this problem.

But the changes are still causing test failures (screenshot below):

• TestWrite is failing with : truncate:The requested operation cannot be performed on a file with a user-mapped section open.. This refers to the truncate operation during value log replay. It seems that we cannot use truncate on windows while a file is mmap-ed. A fix for this would require changes in the way we do value log replay. I can’t really say if it is a trivial change or not, without further investigation.

• TestConcurrentWrite is failing because it just takes too long to run. This indicates that there is some sort of race condition, but it only happens when we use mmap. We need to understand how Windows mmap-ing works more deeply to dig into this.

Sigh… @manishrjain I hate to say it, but it seems like #235 might be the easiest way to get around this, after all.

[manishrjain]

Based on our last chat, a good solution here would be to not mmap until replay has been completed. Also, to preallocate the write file to 2xvalue log size, and then truncate it when done.