Barriers and journaling filesystems

Barriers and journaling filesystems

"Summary: filesystem implementors ought to talk to database implementors. I'm sure both groups can teach each other a lot, but in this area databases are still quote a bit ahead of ext3/ext4."

The purpose of a journal is not to be sure that everything is written to disk when you do a write. It's to be sure that the file system is always in a consistent state so you don't need a very expensive fsck and risk loosing other data then what was being written. If you need to be sure that something is written to disk you have to use the fsync function in your code.

greets,
Staf.

fsync *still* isn't going to help you much if I/O reordering is allowed.

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.

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.

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
for this.
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.

greets,
Staf.