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 ? ************************************************ The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ************************************************ -- 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
