Broken direct I/O support not caught on ReiserFS in journaled data mode about rethinkdb HOT 4 CLOSED

Hmm, if I had to guess, I'd say reiser probably opens the file with the page cache but doesn't fsync on every write (just an uneducated guess, though)

I don't like the idea of explicitly checking for it -- we should actually figure out why we crash. We also shouldn't crash on a bad rethinkdb file in this way (we should give a friendlier error message). I'm moving this issue to backlog because there are more pressing issues at the moment and this seems like a rare configuration. I added #30 for documenting this limitation.

from rethinkdb.

Here's a related bug in older PostgreSQL version by the way, even though it refers to ext3/4, not ReiserFS.
http://postgresql.1045698.n5.nabble.com/We-really-ought-to-do-something-about-O-DIRECT-and-data-journalled-on-ext4-td3287127.html
It seems that ext3/ext4 do report a failure on opening a file with O_DIRECT in journaled mode though, while ReiserFS seems to accept it and then maybe just misbehaves (whatever that means for semantics so badly defined and/or documented as the direct I/O ones on Linux).

PS: Indeed, on ext4 with data=journal, RethinkDB detects the condition properly and prints the appropriate message, including the text "- the database file is located on a filesystem that doesn't support O_DIRECT open flag (e.g. in case when the filesystem is working in journaled mode)".

from rethinkdb.

Cool, thanks!

from rethinkdb.

I don't know if something changed in RehtinkDB, or if this was a a fix in the Ubuntu 10.04 kernel, but it's actually working now. Closing! :-)

from rethinkdb.