Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible bug: fsync() required after file creation. #196

Closed
cmumford opened this issue Sep 9, 2014 · 2 comments
Closed

Possible bug: fsync() required after file creation. #196

cmumford opened this issue Sep 9, 2014 · 2 comments
Assignees

Comments

@cmumford
Copy link
Contributor

@cmumford cmumford commented Sep 9, 2014

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.

@cmumford
Copy link
Contributor Author

@cmumford cmumford commented Sep 9, 2014

Comment #1 originally posted by dgrogan@chromium.org on 2013-07-17T22:26:06.000Z:

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.

@cmumford cmumford self-assigned this Sep 9, 2014
@cmumford
Copy link
Contributor Author

@cmumford cmumford commented Sep 9, 2014

Comment #2 originally posted by dgrogan@chromium.org on 2013-12-10T19:51:56.000Z:

Fixed in 1.13

@cmumford cmumford closed this Sep 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant