On Mon, Feb 20, 2017 at 08:29:45AM +0100, Christoph Hellwig wrote:
> Hi Darrick,
>
> I got a bug report about running out of log reservations when deleting
> heavily reflinked files.
>
> We're hitting the ASSERT(tp->t_ticket->t_curr_res >= len) in
> xlog_cil_insert_items and it seems we are way above the reservation.
>
> I started auditing the issue and it seems like we don't account for
> the refcountbt adjustments at all in tr_itruncate. Do you have any
> back of the napking math around for what amount of log reservations
> we should need for them? Otherwise I'll need to wade through the
> code and recreate that math.
Hmmmm. refcountbt updates should all be processed as deferred ops,
which means that each logical update ("increase refcount of blocks
3-300") should be getting its own transaction.
The function xfs_refcount_still_have_space tries to guess when we're
getting close to using up all the log reservation by assuming that each
refcount update will eventually use 32 bytes of the transaction
reservation, though it's hard to know precisely what the results of
formatting the log items will be.
When it thinks we're out of transaction space it'll signal a partial
completion, which (should) cause the defer_ops mechanism to log an RUD
and a new RUI, then roll the transaction and start again. I speculate
that my guess of 32 bytes per refcountbt update is not correct. :(
Can you reproduce it easily? IIRC xfs/140 should exercise some of this
mechanism.
--D
--
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
