Barriers and journaling filesystems

Posted May 24, 2008 9:14 UTC (Sat) by Xman (guest, #10620)
In reply to: Barriers and journaling filesystems by Fats
Parent article: Barriers and journaling filesystems

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 (guest, #14882) [Link] (2 responses)

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.

Barriers and journaling filesystems

Posted May 24, 2008 18:00 UTC (Sat) by Xman (guest, #10620) [Link] (1 responses)

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.

Barriers and journaling filesystems

Posted May 24, 2008 19:48 UTC (Sat) by Fats (guest, #14882) [Link]

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.