All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas McClendon <dmc.fedora@filteredperception.org>
To: dm-devel@redhat.com
Subject: Snapshot handover working, yippee!, was Re:  semop failed for cookie?
Date: Wed, 05 May 2010 00:18:03 -0500	[thread overview]
Message-ID: <4BE0FF8B.2070800@filteredperception.org> (raw)
In-Reply-To: <20100429162338.GA14077@agk-dp.fab.redhat.com>

Ok, so my complaining about code-progress should now be complete.  I 
think I'm back in action.  But the "BUG: lock held when returning to 
user space" still seems like a message you folks wanted yourselves to hear.

After grumbling to myself that fedora doesn't provide a package with 
dmsetup.static, I went ahead and copied all relocatable deps 
(/lib/ld-linux.so.2??) to tmpfs along with dmsetup, using 
LD_LIBRARY_PATH.  I also used --noudevrules and --noudevsync.  Then I 
followed the documentation I found which, for use cases as esoteric as 
mine, might be desirable in snapshot.txt

https://patchwork.kernel.org/patch/59806/

I.e. rules for snapshot handover in the general case.  (who knows, maybe 
I'll be the only user of non-snapshot-merge snapshot handover for all 
time) (though technically I guess you can call what I've been doing for 
the last several years to be an alternate form of snapshot merging. 
I.e. where your snapshot base is readonly and you are merging both the 
readonly base and cow to a third writable device)

Anyway, I finally got my stuffs working again, or at least, I have a 
virtual snapshot-as-rootfs being dm-mirror migrated right now.  I assume 
that my loading of a new table, is sufficiently equivalent to the 
dmsetup remove of the old snapshot as described in the above link.

But finally, and the real reason for this message- during this I noticed 
that the aforementioned "BUG:" was not in fact what was killing my 
system.  I.e. I still get that message, though everything else appears 
to work and it appears to be harmless (I hope).

BUG: lock held when returning to user space!

dmsetup/865 is leaving the kernel with locks still held!
1 lock held by dmsetup/865:
  #0:   (&journal->j_barrier){+.+...+}, at: [<c056b84d>] jbd2_journal_lock_\
updates+0xbd/0xc5

Thanks again for putting up with my corner case complaints.

Cheers,

-dmc

  parent reply	other threads:[~2010-05-05  5:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-27 20:56 semop failed for cookie? Douglas McClendon
2010-04-27 22:33 ` Alasdair G Kergon
2010-04-28  3:52   ` Douglas McClendon
2010-04-28 23:11   ` Douglas McClendon
2010-04-29  0:00     ` Alasdair G Kergon
2010-04-29  3:32       ` Douglas McClendon
2010-04-29 16:23         ` Alasdair G Kergon
2010-05-03  1:36           ` Douglas McClendon
2010-05-05  5:18           ` Douglas McClendon [this message]
2010-05-05 15:22             ` Snapshot handover working, yippee!, was " Mike Snitzer
2010-04-28  9:38 ` Peter Rajnoha

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=4BE0FF8B.2070800@filteredperception.org \
    --to=dmc.fedora@filteredperception.org \
    --cc=dm-devel@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.