Remove kernel-dev from the CC-list as this is particular to OCFS2. On 06/16/2013 09:57 AM, shencanquan wrote: > 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. This sounds like a bug because SEEK_END references the file size, hence it requires the OCFS2 specified inode lock protection. So patch is always welcome. Thanks, -Jeff >> 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. >> > > -- 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
