Hacker News Reader

Comment by nextaccountic | Hacker News Reader

> It also goes the other way - the update to the directory can be fsynced but the file lost. This can break the "create temp file, write, close, rename to current" scenario (when the intention is to replace file contents atomically).

> POSIX doesn't guarantee the order in which data hits the disk, so the above scenario can become "create temp file, write [contents still in memory only], rename to current [written to disk], power failure".

Wait.. is there a way to do this correctly? At which points is fsync warranted, and how many fsyncs do we need for the whole "write file then mv it on top of current" to not lose data on power failure?

View on HN

Write, fsync, rename then fsync directory if you need an ordering guarantee that the rename is a transaction barrier.

Of course, the fun part is that the filesystem can’t really guarantee fsync behavior if drives lie about it which many consumer drives do for benchmark reasons. Fun, no?

It would also be a fun experiment to write, fsync, cut power. Rinse and repeat. On differential drives. It would quickly show which drives are lying about syncing.

Sqlite is much better than raw files to keep data intact on power failures, and be sure to study the options carefully

If you truly need to use files you can take other steps such as mv the old file to .bck before mv the new file, but I really think you want sqlite

SQLite doesn't do any magic other than fsync. Using it to deal with power failures is nonsense.

Well generally OP is correct that SQLite will more likely have written fsync code correctly and be fairly robust against power failures due to the WAL. Additionally, it’s not doing any renaming which you would need with plain files.

So while it doesn’t do any other magic, it’s more likely to handle power failures correctly.

`fsync()` is not necessarily enough if your on-disk format is complex because you still need to write recovery code. Of course, SQLite3's on-disk format is very complex, and so it requires correspondingly more complex power failure recovery code. But SQLite3 has an excellent test suite, and in particular they have an excellent power failure recovery test suite.

Using SQLite3 to avoid power failure issues is pretty good advice. I don't see why GP is getting downvoted.

But the authors of SQLite have studied and correctly implemented the working fsync logic, so you don't have to. It ·may* be a correct approach if it's your implementation detail, and.nobody else expects that file you're replacing.

I think the idea was to store data in the db, instead of scattered over multiple files and directories. Then you only have to worry about one file to fsync (Two if using a wal).

> SQLite doesn't do any magic other than fsync.

True.

> Using it to deal with power failures is nonsense.

Using a very well designed library for your use case is not nonsense.

> Using a very well designed library for your use case is not nonsense.

Could you recommend your personal favorite(s) of such libraries? Enquiring minds want to know! Thx.

When it comes to libraries that handle the messy details of putting data on disk, sqlite is the only one I can name off hand so that's the favorite.

Reply on news.ycombinator.com