Hi,
On 08/12/15 07:57, Dave Chinner wrote:
On Wed, Dec 02, 2015 at 11:42:13AM -0500, Bob Peterson wrote:
- Original Message -
(snip)
Please take a look at this
again and figure out what the problematic cycle of events is, and then
work out how to avoid that happening in the first place
On Wed, Dec 02, 2015 at 11:42:13AM -0500, Bob Peterson wrote:
> - Original Message -
> (snip)
> > Please take a look at this
> > again and figure out what the problematic cycle of events is, and then
> > work out how to avoid that happening in the first place. There is no
> > point in repla
- Original Message -
> On Fri, Dec 04, 2015 at 09:51:53AM -0500, Bob Peterson wrote:
> > it's from the fenced process, and if so, queue the final put. That should
> > mitigate the problem.
>
> Bob, I'm perplexed by the focus on fencing; this issue is broader than
> fencing as I mentioned i
On Fri, Dec 04, 2015 at 09:51:53AM -0500, Bob Peterson wrote:
> it's from the fenced process, and if so, queue the final put. That should
> mitigate the problem.
Bob, I'm perplexed by the focus on fencing; this issue is broader than
fencing as I mentioned in bz 1255872. Over the years that I've r
Hi,
- Original Message -
> > Hi Steve,
> >
> > Another possibility is to add a new inode work_queue which does the work of
> > gfs2_clear_inode(). Its only function would be to clear the inode, and
> > therefore, there should not be any competing work, as there is in the case
> > of
> > a
Hi,
On 02/12/15 17:41, Bob Peterson wrote:
- Original Message -
- Original Message -
(snip)
Please take a look at this
again and figure out what the problematic cycle of events is, and then
work out how to avoid that happening in the first place. There is no
point in replacing
- Original Message -
> - Original Message -
> (snip)
> > Please take a look at this
> > again and figure out what the problematic cycle of events is, and then
> > work out how to avoid that happening in the first place. There is no
> > point in replacing one problem with another one
- Original Message -
(snip)
> Please take a look at this
> again and figure out what the problematic cycle of events is, and then
> work out how to avoid that happening in the first place. There is no
> point in replacing one problem with another one, particularly one which
> would likely b
HI,
On 01/12/15 15:42, Bob Peterson wrote:
- Original Message -
Hi,
On 25/11/15 14:22, Bob Peterson wrote:
- Original Message -
Hi,
On 19/11/15 18:42, Bob Peterson wrote:
This patch changes function gfs2_clear_inode() so that instead
of calling gfs2_glock_put directly() mos
- Original Message -
> Hi,
>
> On 25/11/15 14:22, Bob Peterson wrote:
> > - Original Message -
> >> Hi,
> >>
> >> On 19/11/15 18:42, Bob Peterson wrote:
> >>> This patch changes function gfs2_clear_inode() so that instead
> >>> of calling gfs2_glock_put directly() most of the time,
Hi,
On 25/11/15 14:22, Bob Peterson wrote:
- Original Message -
Hi,
On 19/11/15 18:42, Bob Peterson wrote:
This patch changes function gfs2_clear_inode() so that instead
of calling gfs2_glock_put directly() most of the time, it queues
the glock to the delayed work queue. That avoids a
- Original Message -
> Hi,
>
> On 19/11/15 18:42, Bob Peterson wrote:
> > This patch changes function gfs2_clear_inode() so that instead
> > of calling gfs2_glock_put directly() most of the time, it queues
> > the glock to the delayed work queue. That avoids a possible
> > deadlock where i
Hi,
On 19/11/15 18:42, Bob Peterson wrote:
This patch changes function gfs2_clear_inode() so that instead
of calling gfs2_glock_put directly() most of the time, it queues
the glock to the delayed work queue. That avoids a possible
deadlock where it calls dlm during a fence operation:
dlm waits f
This patch changes function gfs2_clear_inode() so that instead
of calling gfs2_glock_put directly() most of the time, it queues
the glock to the delayed work queue. That avoids a possible
deadlock where it calls dlm during a fence operation:
dlm waits for a fence operation, the fence operation wait
14 matches
Mail list logo
