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. the position is old.
this bug can be reproduce
On Thu, 20 Jun 2013 15:59:30 +0800 Younger Liu younger@huawei.com wrote:
While adding a file into orphan dir in ocfs2_orphan_add(),
it calls __ocfs2_add_entry() before ocfs2_journal_access_di().
If ocfs2_journal_access_di() failed, the file is added into
orphan dir, and orphan dir
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. the
On Thu, 27 Jun 2013 09:19:52 +0800 shencanquan shencanq...@huawei.com wrote:
On 2013/6/27 5:18, Andrew Morton wrote:
My guess is that there is some other code path which is modifying
inode-i_size without holding inode-i_mutex, and while holding
ocfs2_inode_lock(). If so, that code is
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
AFAIR, this behavior has been there since day 1 and changing it will impact
performance negatively. I would recommend against making this change for
one app.
On Wed, Jun 26, 2013 at 6:50 PM, shencanquan shencanq...@huawei.com wrote:
On 2013/6/27 9:25, Andrew Morton wrote:
On Thu, 27 Jun
