Possible bug: fsync() required after file creation.

[GoogleCodeExporter]

Similar to issue 189, this bug is about what happens during a power-failure. 
Also similar to that issue, this bug is not actually triggered atop 
file-systems that I'm aware of; it seems wrong from the behavior explained in 
the Linux fsync() man-page, though.

The bug: Leveldb, after creating any file and issuing a fsync()-like call on 
it, assumes that the file is persistent on disk. If these files actually don't 
get persisted to disk, there are lots of chances of (LevelDB) corruption and 
wrong-behavior. Of course, with bad system configurations consisting of lying 
file-systems and lying hard drives, this can't be helped.

However, even with "correct" system configurations, the Linux man-page for 
fsync() reports that the file need not be persistent, unless fsync() was called 
on the parent directory.

Saying that, ext2 is the only file-system I know of that might actually expect 
an fsync() on the parent directory. Moreover, fsync()-ing the parent directory 
is not even allowed on many OSes, even Linux-family ones. On the other hand, 
SQLite does fsync()s to the parent directory for this purpose, so it is 
possible that there are some cared-about file-systems that actually rely on 
this.

Original issue reported on code.google.com by madthanu@gmail.com on 17 Jul 2013 at 3:49

[GoogleCodeExporter]

The next release includes a change that addresses this. It calls fsync on the 
parent directory just before syncing the manifest near the end of a compaction. 
It's not perfect but does reduce the window in which a crash could cause 
corruption.

Original comment by dgrogan@chromium.org on 17 Jul 2013 at 10:26

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Fixed in 1.13

Original comment by dgrogan@chromium.org on 10 Dec 2013 at 7:51

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****