On 2013/6/27 5:18, Andrew Morton wrote:
On Thu, 20 Jun 2013 16:23:59 +0800 shencanquan shencanq...@huawei.com wrote:
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END
llseek requires ocfs2 inode lock for updating the file size in SEEK_END.
because the file size maybe update on another node.
if it not . after call llseek in SEEK_END. the position is old.
this bug can be reproduce the following scenario:
at first ,we dd a test fileA,the file size is 10k.
on
The test scenario is following:
There are two node, one is nodeA, another is nodeB
On nodeA, the test program open the file and write some data to the
file and then close the file.
On nodeB, the another test program open the file and llseek the end of
file. we found that the position of file is
On 2013/6/17 23:17, Jeff Liu wrote:
On 06/17/2013 10:48 PM, shencanquan wrote:
We found that llseek has a bug when in SEEK_END. it need to 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
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 ,
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
On 2013/6/10 20:11, Goldwyn Rodrigues wrote:
On Mon, Jun 10, 2013 at 5:09 AM, shencanquanshencanq...@huawei.com wrote:
On 2013/6/8 22:34, Goldwyn Rodrigues wrote:
Hi,
I am trying to understand why the unlinks (distributed) are slow with
ocfs2. My investigation so far has revealed that
On 2013/6/8 22:34, Goldwyn Rodrigues wrote:
Hi,
I am trying to understand why the unlinks (distributed) are slow with
ocfs2. My investigation so far has revealed that ocfs2_try_open_lock
fails on the directory unlinked but works for a file unlinked. This
creates a checkpoint everytime a
On 2013/5/29 10:42, Joseph Qi wrote:
If we use le32_add_cpu to set ocfs2_dinode i_flags, it may lead to the
corresponding flag corrupted. So we should change it to bitwise and/or
operation.
I think it should be use bitwise and or operation, because one bit stand
for one meaning.
On 2013/5/29 15:57, Jeff Liu wrote:
Thanks for your patch, Joseph.
On 05/29/2013 10:42 AM, Joseph Qi wrote:
If we use le32_add_cpu to set ocfs2_dinode i_flags, it may lead to the
corresponding flag corrupted. So we should change it to bitwise and/or
operation.
Signed-off-by: Joseph
On 2013/5/23 7:00, Sunil Mushran wrote:
True. The function could do with a little bit of cleanup. Feel free to
send a patch.
from ocfs2 code , I don't found that dlm_recovery_thread always prior to
ocfs2_recovery_thread? please tell me,thanks.
On Sun, May 19, 2013 at 7:49 PM, Joseph Qi
in the
following functions.Kernel panic happens.
Hmm, I see, this patch looks good .
Reviewed-by: shencanquan shencanq...@huawei.com
On 05/22/2013 10:31 AM, shencanquan wrote:
if return 0, what's wrong with this?
On 2013/5/22 9:43, xiaowei...@oracle.com wrote:
From: Xiaowei.Huxiaowei...@oracle.com
12 matches
Mail list logo
