public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 9/9] xfs: log ticket reservation underestimates the number of iclogs
Date: Tue, 16 Mar 2010 12:51:07 +1100	[thread overview]
Message-ID: <20100316015107.GE12369@dastard> (raw)
In-Reply-To: <20100315154435.GA29024@infradead.org>

On Mon, Mar 15, 2010 at 11:44:35AM -0400, Christoph Hellwig wrote:
> > > +	iclog_space = log->l_iclog_size - log->l_iclog_hsize;
> > > +	num_headers = (unit_bytes + iclog_space - 1) / iclog_space;
> > > +
> > > +	/* for split-recs - ophdrs added when data split over LRs */
> > > +	unit_bytes += sizeof(xlog_op_header_t) * num_headers;
> > > +
> > > +	/* add extra header reservations if we overrun */
> > > +	while (!num_headers ||
> > > +	       ((unit_bytes + iclog_space - 1) / iclog_space) > num_headers) {
> > > +		unit_bytes += sizeof(xlog_op_header_t);
> > > +		num_headers++;
> > > +	}
> > 
> > Looks good, but why do you check for a zero num_headers here?  The only way
> > this could happen after the roundup above is if unit_bytes is zero, which
> > can't ever happen - one caller has it hardcoded to 1, and the the other
> > has a conditional for it beeing bigger than 0 around the call.

Mainly because I want to be able to pass a length of zero in for the
checkpoint transaction and have it do the right thing. That is,
reserve space for the first header which, in this case, will
definitely be used. Indeed, once I made this change, i forgot to
change the CIL ticket allocation back to zero - it is still:

	tic = xlog_ticket_alloc(log, 1 /* to get a LR header */,
				1, XFS_TRANSACTION, 0);

Other than that I can't find any caller that uses unit_bytes = 1.
Maybe I missed something - can you point it out to me?

FWIW, there's more missing from the transaction reservations
themselves - none of them take into account the space used by the
log item format descriptor that describe the changed regions of an
object written to the log. They take into account the regions
themselves, but not the descriptor. Some of the hard coded
transaction reservations do - see all the single sector transactions
that reserve "<something> + 128" e.g:

	error = xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0,
				XFS_DEFAULT_LOG_COUNT);

That 128 bytes is for the log item format descriptor, and in some
cases I'm not sure that 128 bytes is enough. Anyway, that's a
problem for a rainy day...

> BTW: use of the howmany macro might make some of the above easier
> to read.

Good point. I'll look into using that.

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2010-03-16  1:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15  2:34 [PATCH 0/9] Log and transaction cleanups, factoring and bug fixes V2 Dave Chinner
2010-03-15  2:34 ` [PATCH 1/9] xfs: factor log item initialisation Dave Chinner
2010-03-15  2:34 ` [PATCH 2/9] xfs: Add inode pin counts to traces Dave Chinner
2010-03-15  2:35 ` [PATCH 3/9] xfs: remove stale parameter from ->iop_unpin method Dave Chinner
2010-03-15  2:35 ` [PATCH 4/9] xfs: fix reservation release commit flag in xfs_bmap_add_attrfork() Dave Chinner
2010-03-15  2:35 ` [PATCH 5/9] xfs: split out iclog writing from xfs_trans_commit() Dave Chinner
2010-03-15  2:35 ` [PATCH 6/9] xfs: clean up xfs_trans_commit logic even more Dave Chinner
2010-03-15  2:35 ` [PATCH 7/9] xfs: update and factor xfs_trans_committed() Dave Chinner
2010-03-15  2:35 ` [PATCH 8/9] xfs: Clean up xfs_trans_committed code after factoring Dave Chinner
2010-03-15 15:20   ` Christoph Hellwig
2010-03-15  2:35 ` [PATCH 9/9] xfs: log ticket reservation underestimates the number of iclogs Dave Chinner
2010-03-15 15:41   ` Christoph Hellwig
2010-03-15 15:44     ` Christoph Hellwig
2010-03-16  1:51       ` Dave Chinner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100316015107.GE12369@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox