Messages in this thread | | | Date | Sun, 30 Aug 2009 17:58:34 +0100 | From | Jamie Lokier <> | Subject | Re: adding proper O_SYNC/O_DSYNC, was Re: O_DIRECT and barriers |
| |
Ulrich Drepper wrote: > On 08/28/2009 09:44 AM, Jamie Lokier wrote: > >(Oh, and Ulrich: Why is there a "#define O_RSYNC O_SYNC" in the Glibc > >headers? That doesn't make sense: O_RSYNC has nothing to do with > >writing.) > > O_SYNC is a superset of O_RSYNC. In the absence of a true O_RSYNC > that's the next best thing.
That's an error - O_SYNC is not a superset of O_RSYNC.
O_SYNC (by itself) only affects writes.
O_RSYNC only affect reads.
In the absence of O_RSYNC support in the kernel, it's better to not define O_RSYNC at all in userspace. That tells applications they can call fsync/fdatasync themselves before reading to get an equivalent effect.
In fact O_RSYNC, when implemented correctly, can be used by applications to get the effect of range-fsync/fdatasync when such system calls aren't available (by reading a range), but not as efficiently of course. Defining O_RSYNC as O_SYNC fails to do that.
-- Jamie
| |