Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
fsync *still* isn't going to help you much if I/O reordering is allowed.
Barriers and journaling filesystems
Posted May 24, 2008 9:30 UTC (Sat) by Fats (subscriber, #14882)
AFAIK fsync explicitly tells the hard drive to perform all outstanding IOs and then returns.
So, of course, if your hard drive lies to you, you are screwed.
Don't know if LVM is broken here also.
Posted May 24, 2008 18:00 UTC (Sat) by Xman (guest, #10620)
fsync will block until the outstanding requests have been sync'd do disk, but it doesn't
guarantee that subsequent I/O's to the same fd won't potentially also get completed, and
potentially ahead of the I/O's submitted prior to the fsync. In fact it can't make such
guarantees without functioning barriers.
Posted May 24, 2008 19:48 UTC (Sat) by Fats (subscriber, #14882)
Sure, my comment was in response to hpp and what I wanted to say is that user land code has to
take care of transactions as defined in relation databases and that fsync is the tool to use
A journaled file system only takes care that the file system stays in a consistent state so no
expensive fsck is needed with possible loss of data. Open write files may lose some of the
last writen data if no fsync was performed. To keep the file system consistency barriers are
used to guarantee a certain order of the writes. This limited guarantee allows file system to
be faster the relational databases.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds