From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/8] xfs: make the log ticket transaction id random
Date: Tue, 6 Apr 2010 09:39:10 +1000 [thread overview]
Message-ID: <20100405233910.GA11036@dastard> (raw)
In-Reply-To: <20100403093156.GD20166@infradead.org>
On Sat, Apr 03, 2010 at 05:31:56AM -0400, Christoph Hellwig wrote:
> On Thu, Apr 01, 2010 at 11:41:26PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > The transaction ID that is written to the log for a transaction is
> > currently set by taking the lower 32 bits of the memory address of
> > the ticket structure. This is not guaranteed to be unique as
> > tickets comes from a slab and slots can be reallocated immediately
> > after being freed. As a result, there is no guarantee of uniqueness
> > in the ticket ID value.
> >
> > Fix this by assigning a random number to the ticket ID field so that
> > it is extremely unlikely that duplicates will occur and remove the
> > possibility of transactions being mixed up during recovery due to
> > duplicate IDs.
>
> I already noticed that you uses a random tid in your delayed logging
> patches. But even a random number means we can get duplicate tids.
Agreed. However, random duplicates are much more unlikely, IMO, than
memory addresses of slab objects. The existing code is giving quite
regular duplicates according to the tracing I added, but I didn't
find any from the sampling I did with this patch....
> If we assign tids from a wrapping counter instead we can guarantee
> that they are unique as long as we don't have more than UINT_MAX
> transactions in the log, which is a limitation we could easily enforce.
Ideally, yes. However, I didn't want to introduce a global
monatomically increasing counter into the transaction code. I'm
seeing upwards of 50-60k transactions/s on my test box - that's
getting into the range where reliable global counters become
scalability limitations. I know this can be solved, but it is
somewhat complex and I'm not sure at this point that the complexity
is necessary. What do you think?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-04-05 23:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-01 12:41 [PATCH 0/8] xfs: bug fixes, cleanups and tracing Dave Chinner
2010-04-01 12:41 ` [PATCH 2/8] xfs: don't warn on EAGAIN in inode reclaim Dave Chinner
2010-04-03 9:25 ` Christoph Hellwig
2010-04-01 12:41 ` [PATCH 3/8] xfs: make the log ticket transaction id random Dave Chinner
2010-04-03 9:31 ` Christoph Hellwig
2010-04-05 23:39 ` Dave Chinner [this message]
2010-04-13 18:12 ` Christoph Hellwig
2010-04-01 12:41 ` [PATCH 4/8] xfs: add log item recovery tracing Dave Chinner
2010-04-03 9:36 ` Christoph Hellwig
2010-04-05 23:40 ` Dave Chinner
2010-04-01 12:41 ` [PATCH 5/8] xfs: convert the per-mount dquot list to use list heads Dave Chinner
2010-04-03 9:59 ` Christoph Hellwig
2010-04-01 12:41 ` [PATCH 6/8] xfs: remove duplicate code from dquot reclaim Dave Chinner
2010-04-03 10:00 ` Christoph Hellwig
2010-04-01 12:41 ` [PATCH 7/8] xfs: convert the dquot hash list to use list heads Dave Chinner
2010-04-03 10:00 ` Christoph Hellwig
2010-04-01 12:41 ` [PATCH 8/8] xfs: convert the dquot free " Dave Chinner
2010-04-03 10:00 ` Christoph Hellwig
2010-04-03 10:02 ` [PATCH 9/8] xfs: remove xfs_dqmarker Christoph Hellwig
2010-04-05 23:20 ` Dave Chinner
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=20100405233910.GA11036@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