Open Error: IO error Invalid argument

[caio-ribeiro-pereira]

Hi, this is my first time using and learning about LevelDB with Node.js, and my simple app, can't run, this is my simple code:

var
  level = require('level'),
  express = require('express'),
  uuid = require('node-uuid'),
  db = level('./users.db', {valueEncoding: 'json'}),
  app = module.exports = express();

app.use(express.logger('dev'));
app.use(app.router);

app.get('/users', function(req, res) {
  db.get('users', function(err, users) {
    if (err) return res.json(404, err);
    return res.json(200, users);
  });
});

app.post('/user', function(req, res) {
  db.put('users', req.body.user, function(err) {
    if (err) return res.json(404, err);
    return res.json(200);
  });
});

app.listen(5000, function() {
  console.log('LevelDB API running on port 5000');
});

And when I run: node app
It throws the error:

OpenError: IO error: ./users.db/MANIFEST-000001: Invalid argument

I am using latest stable: Node.js 0.10.23

Does anybody can help me? Thanks!

[caio-ribeiro-pereira]

I'm using Ubuntu 12.04 LTS

[rvagg]

obvious starting questions are:

• are you sure there is only one process accessing that database location? this isn't being run in cluster or multi-process?
• does the process have proper filesystem permissions to create that directory and files in it?
• is there an existing database in that location? perhaps it's corrupted and you could try removing it if the data isn't so important.

[caio-ribeiro-pereira]

Well there is no cluster running, it's a simple and small app which I built just to learn LevelUp.
It's probably a problem with filesystem permission in my Ubuntu, because into my MacOSX my app runs normally.
And about the database it's a empty db.

This is my ls -al

drwxr-xr-x 1 vagrant vagrant  204 Dec 12 23:55 .
drwxr-xr-x 1 vagrant vagrant  476 Dec 12 16:54 ..
-rw-r--r-- 1 vagrant vagrant 1526 Dec 12 23:55 app.js
drwxr-xr-x 1 vagrant vagrant  272 Dec 12 23:48 node_modules
-rw-r--r-- 1 vagrant vagrant  381 Dec 12 23:48 package.json
drwxr-xr-x 1 vagrant vagrant  340 Dec 12 23:55 users.db

Another detail, my ubuntu 12.04 LTS is a vagrant virtual machine.

[rvagg]

I'm not really much of an expert with vagrant but does your app run as user 'vagrant'? Perhaps it's not and therefore doesn't have write access to the users.db directory?

[caio-ribeiro-pereira]

Vagrant is just a Ubuntu VM sharing the same project directory with my Mac.
Probably some chmod from levelup has not the full access.

[juliangruber]

there are known problems with leveldb and virtualbox: https://groups.google.com/forum/#!topic/leveldb/MjFwXk6_RgY (and more but can't find the link)

[caio-ribeiro-pereira]

Yeah! I having the same problem using ubuntu virtualbox :-/

[juliangruber]

many developers use vagrant so this is kinda important...anyone?

[rvagg]

ah yes, I remember this issue now, it popped up somewhere else but I'm not sure where...

I'm wondering if this might change with leveldb 1.15.0 given they've moved away from mmap writes, it'll be worth trying out when we upgrade leveldown.

[pluma]

+1

A workaround seems to be to simply symlink the db folder from a non-shared location. Of course this only works if you're not interested in sharing the db between host and guest.

[caio-ribeiro-pereira]

+1

This solve my problem! Thanks!

[eugeneware]

I'm having the same problem. It's also effecting the lmdb leveldown driver too (I guess because it would use mmap).

fingers crossed that the new leveldb fixes the problem.

I'm doing development with virtualbox and docker images, and coming up against this issue when using synced folders from vagrant into docker.

I wonder if the same problem occurs with using an nfs share?

[eugeneware]

OK. mmap works with nfs. So just add this to your Vagrantfile:

  config.vm.synced_folder "/your/local/path", "/home/vagrant/share", id: "core", :nfs => true,  :mount_options   => ['nolock,vers=3,udp']

I've tested this with the coreos image, and it works great.

[eugeneware]

The core issue is to do with a bug in virtualbox:

https://www.virtualbox.org/ticket/819#comment:55

I was able to replicate the problem on any vboxfs partition with this code:

https://gist.github.com/eugeneware/9045290

So it's not really leveldb related at all.

For now, use the nfs workaround, and please upvote my bug on the oracle virtualbox bugtracker to try to get this resolved quickly! :-)

[eugeneware]

And retweet this for good measure :-) https://twitter.com/EugeneWare/status/435288808490143744

[olalonde]

I had the same problem running bitcoind (which uses leveldb) in a mounted folder with boot2docker. Fixed it by mounting the folder with nfs instead of vboxfs and wrote a script to do the switch automatically: https://gist.github.com/olalonde/3f7512c0bd2bc8abb46d

[eugeneware]

Great news everyone (/cc @groundwater), the latest version of docker (you can register for at https://beta.docker.com/) which does NOT require virtualbox (uses xhyve under the hood - with the native hypervisor that comes with OS X) - doesn't suffer from this mmap bug. You can happily create databases on your OS X host operating system, and volume map them to the xhyve docker host and it works beautifully! Woo!

You can read more about the new docker here and get the full docs here

It is a glorious day!

[MicahZoltu]

Not sure if anyone is watching this anymore, but I am experiencing similar symptoms running Docker for Windows beta. I have an Ubuntu image that does some LevelDB stuff (not sure what exactly as its third party) and I get this error:

events.js:141
      throw er; // Unhandled 'error' event
      ^
OpenError: IO error: /data/farmdata/farmer.db: Invalid argument
    at /usr/lib/node_modules/storjshare-cli/node_modules/storj/node_modules/levelup/lib/levelup.js:119:34
    at /usr/lib/node_modules/storjshare-cli/node_modules/storj/node_modules/leveldown/node_modules/abstract-leveldown/abstract-leveldown.js:39:16

In the Windows host I see farmdata/farmer.db folder in the folder I mounted to /data, and it even has some files in it; mostly log files, but also some other stuff like CURRENT, LOCK, LOG, MANIFEST-000001 (I'm not sure if these are LevelDB files or the app's).

Windows for Docker uses Windows Hyper-V to run a Moby Linux VM which acts as the host OS for the docker client. The Windows volume is therefore mapped to the Moby Linux VM which I then mount with docker run -v //d/foo:/data.

If I don't hear anything I'll open another issue, I just didn't want to clutter the open issues with this if it is already solved.

[eugeneware]

I don't run windows, but it could be that mmap() doesn't work correctly under the windows bash emulation. You can try compiling and running this file against a file on your file system to see if mmap works or not

https://gist.github.com/0d991472c71409f5cdf0ed7aeb4e6222

[MicahZoltu]

I don't believe bash is being emulated in this scenario. I believe Moby Linux is being virtualized (by way of hypervisor) and then it is running a docker host which is in turn running a docker container which is running the code. That being said, I'll do a bit of googling to see if I can find any outstanding problems with mmap on docker for windows. There is a lot of stuff out there about VirtualBox and mmap, but nothing I can find for the new stuff.

Also, I don't currently have a setup that would let me easily compile/run that gist in Windows. :/

[eugeneware]

I've wrapped everything into a docker image so you can test. Check out the details here

[MicahZoltu]

Both tests passed:

PS C:\Users\Micah> docker run --rm -it eugeneware/mmap
hello
world
mmap works from internal filesystem - hoorah!
PS C:\Users\Micah> docker run --rm -it -v //d/mmap/local.txt:/app/test.txt eugeneware/mmap
test mmap file

[eugeneware]

Hmm. Not sure what it could be. Most likely not an mmap() issue then which is the focus of this issue thread. I'd open up a new issue with some clear steps and code to replicate the issue.