Re: [Ocfs2-devel] Buffer read will get starvation in case reading/writing the same file from different nodes concurrently

2015-12-07 Thread Joseph Qi
On 2015/12/8 12:51, Eric Ren wrote: > Hi, > > On Tue, Dec 08, 2015 at 11:55:18AM +0800, joseph wrote: >> Hi Gang, >> Eric and I have discussed this case before. >> Using NONBLOCK here is because there is a lock inversion between inode >> lock and page lock. You can refer to the comments of >> ocf

Re: [Ocfs2-devel] [PATCH] ocfs2: dlm: fix deadlock due to nested lock

2015-12-07 Thread Eric Ren
Hi junxiao, On Tue, Dec 08, 2015 at 10:41:03AM +0800, Junxiao Bi wrote: > Hi Eric, > > On 12/07/2015 05:01 PM, Eric Ren wrote: > > Hi Junxiao, > > > > On Mon, Dec 07, 2015 at 02:44:21PM +0800, Junxiao Bi wrote: > >> Hi Eric, > >> > >> On 12/04/2015 06:07 PM, Eric Ren wrote: > >>> Hi Junxiao, >

Re: [Ocfs2-devel] Buffer read will get starvation in case reading/writing the same file from different nodes concurrently

2015-12-07 Thread Gang He
Hello Jeseph, >>> > Hi Gang, > Eric and I have discussed this case before. > Using NONBLOCK here is because there is a lock inversion between inode > lock and page lock. You can refer to the comments of > ocfs2_inode_lock_with_page for details. > Actually I have found that NONBLOCK mode is only

Re: [Ocfs2-devel] Buffer read will get starvation in case reading/writing the same file from different nodes concurrently

2015-12-07 Thread Eric Ren
Hi, On Tue, Dec 08, 2015 at 11:55:18AM +0800, joseph wrote: > Hi Gang, > Eric and I have discussed this case before. > Using NONBLOCK here is because there is a lock inversion between inode > lock and page lock. You can refer to the comments of > ocfs2_inode_lock_with_page for details. > Actually

Re: [Ocfs2-devel] Buffer read will get starvation in case reading/writing the same file from different nodes concurrently

2015-12-07 Thread Joseph Qi
Hi Gang, Eric and I have discussed this case before. Using NONBLOCK here is because there is a lock inversion between inode lock and page lock. You can refer to the comments of ocfs2_inode_lock_with_page for details. Actually I have found that NONBLOCK mode is only used in lock inversion cases. Th

[Ocfs2-devel] Buffer read will get starvation in case reading/writing the same file from different nodes concurrently

2015-12-07 Thread Gang He
Hello Guys, There is a issue from the customer, who is complaining that buffer reading sometimes lasts too much time ( 1 - 10 seconds) in case reading/writing the same file from different nodes concurrently. According to the demo code from the customer, we also can reproduce this issue at home

Re: [Ocfs2-devel] [PATCH] ocfs2: dlm: fix deadlock due to nested lock

2015-12-07 Thread Junxiao Bi
Hi Eric, On 12/07/2015 05:01 PM, Eric Ren wrote: > Hi Junxiao, > > On Mon, Dec 07, 2015 at 02:44:21PM +0800, Junxiao Bi wrote: >> Hi Eric, >> >> On 12/04/2015 06:07 PM, Eric Ren wrote: >>> Hi Junxiao, >>> >>> The patch is likely unfair to the blocked lock on remote node(node Y in >>> your case)

Re: [Ocfs2-devel] [PATCH] ocfs2: fix SGID not inherited issue

2015-12-07 Thread Srinivas Eeda
Thanks Junxiao! Acked-by: Srinivas Eeda On 12/06/2015 08:09 PM, Junxiao Bi wrote: > commit 8f1eb48758aa ("ocfs2: fix umask ignored issue") introduced an issue, > SGID of sub dir was not inherited from its parents dir. It is because SGID > is set into "inode->i_mode" in ocfs2_get_init_inode(), bu

Re: [Ocfs2-devel] [PATCH V2] jbd2: fix null committed data return in undo_access

2015-12-07 Thread Theodore Ts'o
On Wed, Dec 02, 2015 at 02:54:15PM +0800, Junxiao Bi wrote: > commit de92c8caf16c ("jbd2: speedup jbd2_journal_get_[write|undo]_access()") > introduced jbd2_write_access_granted() to improve write|undo_access > speed, but missed to check the status of b_committed_data which caused > a kernel panic

Re: [Ocfs2-devel] [PATCH] ocfs2: dlm: fix deadlock due to nested lock

2015-12-07 Thread Eric Ren
Hi Junxiao, On Mon, Dec 07, 2015 at 02:44:21PM +0800, Junxiao Bi wrote: > Hi Eric, > > On 12/04/2015 06:07 PM, Eric Ren wrote: > > Hi Junxiao, > > > > The patch is likely unfair to the blocked lock on remote node(node Y in > > your case). The original code let the second request to go only if