On 2013/6/16 8:44, Richard Yao wrote: > On 06/15/2013 02:22 AM, shencanquan wrote: >> Hello, Richard and Jeff, >> we found that llseek has another bug when in SEEK_END. it should be >> add the inode lock and unlock. >> this bug can be reproduce the following scenario: >> on one nodeA, open the file and then write some data to file and >> close the file . >> on another nodeB , open the file and llseek the end of file . the >> position of file is old. > Did these operations occur sequentially or did they occur concurrently? > > If you meant the former, the inode cache is not being invalidated. That > should be a bug because Oracle claims OCFS2 is cache-coherent. However, > it is possible that this case was left out of the cache-coherence > protocol for performance purposes. If that is the case, then this would > be by design. someone who works for Oracle would need to comment on that > though.
it is a occur sequentially. after close the file on NodeA , on nodeB and then open the file and llseek the end of file. > > If you meant the latter, you should ask yourself what would happen when > you run two separate programs on the same file in a local filesystem. > There should be no way to avoid a race without some kind of a locking > mechanism. > _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel