On Thu, Aug 20, 2009 at 08:50:24AM -0600, Cornelius, Martin (DWBI) wrote: > > Josef Bacik wrote: > > > So looking at the code, with O_APPEND set, every time the app calls > > write() the > > position it's writing to is set to the end of the file. It looks like > > most > > people (with the exception of btrfs) will be holding the > inode->i_mutex > > when > > they do a generic_write_checks, which gives the position to write to. > So > > the > > position to write to and then the subsequent writing are atomic, so > unless > > the > > fs is btrfs (which may or may not be a bug, I'll leave that to the > smarter > > people), O_APPEND should appear to be atomic. > > Many thanks for your reply, Josef, but i'm still a little uncertain > about whats's going on... > > Does this mean, that in the case of two concurrent write() calls to the > same file, both with O_APPEND, one of them will be blocked until the > other one finished ? > Yeah, all writes are protected by inode->i_mutex, so if two processes are trying to write to the same file at the same time, one will block until the other one is finished. Now without O_APPEND, if they were writing to the same position, the second one would overwrite the last one. However, in the case of O_APPEND, we take the inode->i_mutex, read inode->i_size, and then write to that position, so O_APPEND will be atomic and will always end up writing to a position that has not been written to yet. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
