xfs
[Top] [All Lists]

Re: [PATCH v2] Use atomic_t and wait_event to track dquot pincount

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: [PATCH v2] Use atomic_t and wait_event to track dquot pincount
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 26 Sep 2008 07:30:41 -0400
Cc: Peter Leckie <pleckie@xxxxxxx>, xfs@xxxxxxxxxxx, xfs-dev@xxxxxxx
In-reply-to: <48DC3BBB.4080807@xxxxxxx>
References: <48D9C1DD.6030607@xxxxxxx> <48D9EB8F.1070104@xxxxxxx> <48D9EF6E.8010505@xxxxxxx> <20080924074604.GK5448@disturbed> <48D9F718.4010905@xxxxxxx> <20080925010318.GB27997@disturbed> <48DB4F3F.8040307@xxxxxxx> <20080926003401.GG27997@disturbed> <48DC3BBB.4080807@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Fri, Sep 26, 2008 at 11:32:43AM +1000, Lachlan McIlroy wrote:
>> but it doesn't fix the underlying problem that was causing the
>> spurious wakeups, which is the fact that xfs_qm_dqflush() is not
>> obeying non-blocking flush directions.
> The underlying problem has nothing to do with xfs_qm_dqflush() - the
> spurious wakeups are caused by calls to wake_up_process() that arbitrarily
> wake up a process that is in a state where it shouldn't be woken up.  If
> we don't fix the spurious wakeups then we could easily re-introduce this
> problem again.  If xfs_qm_dqflush() should be non-blocking then that's a
> separate change and it sounds like a good change too.

That sounds like there is one single underlying problem, but there
isn't.  The first problem was that we didn't re-check the condition
after sv_wait.  We must always do this, if only for robustness reasons.
The second problem we have here is that xfssyncd blocks when flushing
quotas.

<Prev in Thread] Current Thread [Next in Thread>