From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Liu Date: Sun, 16 Jun 2013 15:16:26 +0800 Subject: [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup In-Reply-To: <51BD1B84.9080402@huawei.com> References: <1371237814-59365-1-git-send-email-ryao@gentoo.org> <1371237814-59365-2-git-send-email-ryao@gentoo.org> <51BBF6FE.6080502@oracle.com> <51BC080D.1090405@huawei.com> <51BD0A66.4070003@gentoo.org> <51BD1B84.9080402@huawei.com> Message-ID: <51BD664A.6000405@oracle.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: shencanquan Cc: Richard Yao , Mark Fasheh , kernel@gentoo.org, linux-fsdevel@vger.kernel.org, Ocfs2-Devel 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. >> > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Liu Subject: Re: [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup Date: Sun, 16 Jun 2013 15:16:26 +0800 Message-ID: <51BD664A.6000405@oracle.com> References: <1371237814-59365-1-git-send-email-ryao@gentoo.org> <1371237814-59365-2-git-send-email-ryao@gentoo.org> <51BBF6FE.6080502@oracle.com> <51BC080D.1090405@huawei.com> <51BD0A66.4070003@gentoo.org> <51BD1B84.9080402@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Yao , Mark Fasheh , kernel@gentoo.org, linux-fsdevel@vger.kernel.org, Ocfs2-Devel To: shencanquan Return-path: Received: from userp1040.oracle.com ([156.151.31.81]:47280 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754986Ab3FPHQf (ORCPT ); Sun, 16 Jun 2013 03:16:35 -0400 In-Reply-To: <51BD1B84.9080402@huawei.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. >> > >