[ https://issues.apache.org/jira/browse/KUDU-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hao Hao reassigned KUDU-2102: ----------------------------- Assignee: Hao Hao > PosixRWFile::Sync doesn't guarantee durability when used with multiple threads > ------------------------------------------------------------------------------ > > Key: KUDU-2102 > URL: https://issues.apache.org/jira/browse/KUDU-2102 > Project: Kudu > Issue Type: Bug > Components: util > Affects Versions: 1.5.0 > Reporter: Adar Dembo > Assignee: Hao Hao > > PosixRWFile uses an AtomicBool to "optimize" calls to Sync(). It works as > follows: > # The bool starts as false. > # It is set to true in WriteV(). > # In Sync(), we CAS it from true to false. If the CAS succeeds, we actually > do the fsync(). > The idea is that if two threads call Sync() at the same time, only one will > actually do the fsync(). However, there's a problem here: the "losing" thread > returns from Sync() early and operates under the assumption that the file's > data has been made durable, even though it is still in the process of being > synchronized to disk. > We have two options: > # Preserve the optimization but fix it so that the losing thread(s) wait for > the "winning" thread to finish the fsync. This can be done with some more > synchronization primitives (off the top of my head: a lock, a condition > variable, and another boolean). > # Remove the optimization and let the losing thread(s) perform additional > fsyncs. > To measure the effect of the optimization, I wrote a test program that opens > a file and fsyncs it 1000 times. I ran it on an el6.6 box, on spinning disks > mounted as xfs and ext4, and on files that were empty and 10G in size > (dropping caches first). I measured the cost of an fsync to be around 200 > microseconds, suggesting that no I/O is being performed and that the overhead > is purely syscall-related. -- This message was sent by Atlassian JIRA (v6.4.14#64029)