On Thu, Apr 27, 2017 at 12:35:19AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 26, 2017 at 02:37:31PM -0700, Darrick J. Wong wrote:
> > That's so shockingly obvious I don't know why it didn't occur to me.
> > Uh, I'll go give that a try with that horrid generic/931 testcase that
> > I sent to the list a couple of weeks ago. :)
...and now I've realized why I never thought of it -- it's unfortunately
racy. We want to constrain the number of blocks that we unmap from the
file based on the refcount, but because the transaction rolling unlocks
the AGF in between the unmap and decrement-refcount transactions,
another process can swoop in and make changes to the sharedness that
screw us over. Let's say files A and B both share the same 1000 blocks,
and threads A and B are modifying files A and B, respectively.
Thread A: Thread B:
1. punch blocks backed by (0-1000) 1. punch blocks backed by (500-600)
2. grab agf to read refcbt
3. unmap blocks 0-1000; no
refcount edges so we can
unmap everything at once
4. roll transaction, unlock agf
2. grab agf to read refcbt
3. unmap blocks 500-600; no refcount
edges so we can unmap everything in
a single operation
4. roll transaction, unlock agf
5. grab agf again. lucky!
6. split refcbt record because 500-600
is now only owned by file A.
7. complete transaction, unlock agf
5. grab agf to read refcbt
6. whoah! why are there two
edges in the refcount tree at
500 and 600???
So either we have to keep the AGF buffer locked and attached across
all the transaction rolls until we around to processing the refcount
decrement deferred op, or figure out something else clever...?
--D
> I like the idea too. But once thing to remember is that freeing
> blocks from two AG in the same transaction is deadlock prone as the
> other thread shows. I've been doing some work to mitigate that, but
> I guess I'll just wait for your new patch and will rebase on top of
> that.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
