You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original issue 190 created by madthanu on 2013-07-17T03:49:34.000Z:
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.
The text was updated successfully, but these errors were encountered:
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 issue 190 created by madthanu on 2013-07-17T03:49:34.000Z:
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.
The text was updated successfully, but these errors were encountered: