All modern disk drives support cache flushing and/or write barriers. For example, if you look at he barrier option to ext3/4 mount you will see that the filesystems guarantee proper cache flushing for journal commits.
fsync and fdatasync are definitely designed to work with disk caches and should commit to the platters. The posix man page ( http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html ) says: "The fsync() function is intended to force a physical write of data from the buffer cache, and to assure that after a system crash or other failure that all data up to the time of the fsync() call is recorded on the disk." Also, the current implementation of fsync works *correctly* when the length of the file changes. The problem I identified happens only when the length of the file is constant. Mounting with data=journal (and cache still on) *works around the problem* by triggering different kernel code. Only a few KB are written to the journal. The 10x speed difference is not due to the few extra KB/s, it is because the flush command is correctly sent to the disk in this scenario. The number of transactions per second is equal to the rotational frequency of the disk (~100 per second). To summarize, there is a bug in the kernel when fsync is called for a file who's length does not change (such as a DB file). The kernel fails to send a flush/barrier command to the drive in this scenario (and just in this scenario). -- ext3/4 fsyncdata does not flush disk cache https://bugs.launchpad.net/bugs/504632 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
