Re: adding proper O_SYNC/O_DSYNC, was Re: O_DIRECT and barriers

From: Ulrich Drepper
Date: Fri Aug 28 2009 - 17:09:02 EST

On 08/28/2009 09:44 AM, Jamie Lokier wrote:
However, for userspace, there's an issue with applications which were
compiled with an old libc and used O_SYNC. Most of them probably
expected O_SYNC behaviour but all they got was O_DSYNC, because Linux
didn't do it right.

Right. But these programs apparently can live with the broken semantics. I don't worry too much about this. If people really need the fixed O_SYNC semantics then let them recompile their code.

When using a newer kernel which actually implements O_SYNC behaviour,
I'm thinking those applications which asked for O_SYNC should get it,
even though they're still linked with an old libc.

In general yes, but it's too expensive. Again, existing programs expect the current behavior and can live with it.

(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

O_SYNC is a superset of O_RSYNC. In the absence of a true O_RSYNC that's the next best thing. Of course I didn't know the Linux O_SYNC is really O_DSYNC. In that context the definition doesn't make sense.

Although libc's __new_open() could have this:

/* Old kernels only look at O_DSYNC. It's better than nothing. */
if (flags& O_SYNC)
flags |= O_DSYNC;

Imho, it's better to not do that, and instead have


Why should it be better? You're replacing something the compiler can do with zero cost with active code.

Again, these O_* constant changes are sufficient.

â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at