All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com, Alasdair G Kergon <agk@redhat.com>
Subject: Re: clustered snapshots
Date: Mon, 5 Oct 2009 12:24:09 -0400	[thread overview]
Message-ID: <20091005162409.GA4391@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0910050948540.11735@hs20-bc2-1.build.redhat.com>

On Mon, Oct 05 2009 at 11:57am -0400,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> 
> 
> On Mon, 5 Oct 2009, Mike Snitzer wrote:
...
> > Lesson I learned is that the in-core dm_snap_exception's consecutive
> > chunk accounting is _really_ subtle.  And while I agree there should be
> > no relation between the proper cleanup of on-disk and in-core
> > exceptions; doing the cleanup of each in lock-step appears to be the
> > only way forward (that I found).
> 
> Looking closer at it, all that the patch changes is that before the patch, 
> exceptions were cleaned last-to-first and after the patch they are cleaned 
> first-to-last. This is likely a reason that the patch works around a real 
> bug somewhere else. Not the callback.

Callback aside; the code didn't change the processing order.  You're
reading the code wrong.  persistent_commit_merge() processes the on-disk
exceptions in reverse with the following loop:

	   for (i = 0; i < n; i++)
	       clear_exception(ps, ps->current_committed - 1 - i);

The in-core exception cleanup in merge_callback() also cleans up in
reverse:

	  /*
	   * Must process chunks (and associated exceptions) in reverse
	   * so that dm_consecutive_chunk_count_dec() accounting works
	   */
	   for (i = s->merge_write_interlock_n - 1; i >= 0; i--) {
	   ...

So the fact that I added a callback from persistent_commit_merge()
did _not_ change the last-to-first exception cleanup ordering (for
either on-disk or in-core).

Regardless, I'm not using the callback.. I have simpler code to handle
back-merges within the merge_callback() for-loop.  I emailed that patch
in my previous reply to this thread...

> > > I think this patch just hides other bug that you have made. Do you set and 
> > > test the interlock correctly? If yes, it will block any I/Os to the chunks 
> > > being merged.
> > 
> > What bug have I made?  Pretty bold assertion only to back it up with
> > hand-waving and bravado.  I've worked hard to preserve your original work
> > as closely as possible; yet add the ability to support insertion of
> > chunks before existing chunks.
> 
> If it worked before without this patch and stopped working after you've 
> made some changes, than you have likely made a bug. So find it.

I'm not going to go round and round on this.  Backmerges never worked
with your snapshot-merge because you never took them into account (you
disabled them!).

In the interest of moving forward please test that the following code
works on your sparc64 system:
http://people.redhat.com/msnitzer/patches/snapshot-merge/kernel/2.6.31/

You'll also need to update LVM2 2.02-54-cvs to use these patches:
http://people.redhat.com/msnitzer/patches/snapshot-merge/lvm2/LVM2-2.02.54/

Mike

  reply	other threads:[~2009-10-05 16:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-28 23:16 clustered snapshots Mikulas Patocka
2009-09-29 21:39 ` Mikulas Patocka
2009-09-30 16:17   ` Jonathan Brassow
2009-10-01  5:43     ` Mikulas Patocka
2009-10-02 17:26   ` Mike Snitzer
2009-10-02 17:55     ` Mikulas Patocka
2009-10-04  3:48     ` Mike Snitzer
2009-10-05  2:25       ` Mikulas Patocka
2009-10-05  4:33         ` Mike Snitzer
2009-10-05 13:38           ` Mike Snitzer
2009-10-05 15:57           ` Mikulas Patocka
2009-10-05 16:24             ` Mike Snitzer [this message]
2011-04-26  9:18 Christian Motschke

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=20091005162409.GA4391@redhat.com \
    --to=snitzer@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=mpatocka@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.