[Ocfs2-devel] [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
Jeff Liu
jeff.liu at oracle.com
Sun Jun 16 00:16:26 PDT 2013
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.
>>
>
>
More information about the Ocfs2-devel
mailing list