[PATCH 50/50] xfs: use reference counts to free clean buffer items
Mark Tinguely
tinguely at sgi.com
Wed Aug 14 12:49:17 CDT 2013
On 08/14/13 08:26, Mark Tinguely wrote:
> On 08/13/13 22:57, Dave Chinner wrote:
>> On Tue, Aug 13, 2013 at 05:00:25PM -0500, Mark Tinguely wrote:
>>> On 08/13/13 16:46, Dave Chinner wrote:
>>>> On Tue, Aug 13, 2013 at 10:03:19AM -0500, Mark Tinguely wrote:
>>>>> On 08/12/13 05:50, Dave Chinner wrote:
>>>>>> From: Dave Chinner<dchinner at redhat.com>
>>>>>>
>>>>>> When a transaction is cancelled and the buffer log item is clean in
>>>
>>> ...
>>>
>>>>>
>>>>> why is a clean buffer on the AIL? Racing with a completion handler?
>>>>
>>>> "clean" means that it wasn't dirtied in the transaction - it can be
>>>> in the AIL and holding a reference count that way.
>>>
>>> I am wondering because it should not have made it into the CIL if it
>>> was not dirtied in a transaction - at least according to the the log
>>> item descriptor flag at least.
>>
>> CIL != AIL. IOWs, the bli_refcount going to zero doesn't always
>> mean the bli should be freed. All a zero value means is that it is
>> not tracked by any transaction. If the item is not going to be
>> placed in the AIL (or not already in the AIL) then it can be
>> released (freed). Clean or aborted items are not going into the AIL,
>> so they can be freed immeidately. Everything else needs to avoid
>> freeing the item until the correct state is reached, even if the ref
>> count goes to zero.
>>
>
> yep.
>
> You are saying that the problem is releasing a buffer that is clean and
> also in the AIL, I am just trying to figure out if you are fixing a
> symptom or the problem.
>
> --Mark.
Sorry for the noise - I was thinking wrong - the clean check is on the
current transaction format map for some reason I had buffer maps on my
mind - so I get to wear the pointy hat *again* today!
Reviewed-by: Mark Tinguely <tinguely at sgi.com>
More information about the xfs
mailing list