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@xxxxxxxxxx>
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@xxxxxxx>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
