From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 0 of 5]Bz #248176: GFS2: invalid metadata block, gfs2_meta_indirect_buffer
Date: Tue, 24 Jul 2007 14:21:52 +0100 [thread overview]
Message-ID: <1185283312.8765.431.camel@quoit> (raw)
In-Reply-To: <1185253671.517.60.camel@technetium.msp.redhat.com>
Hi,
None of these patches apply due to whitespace breakage.
On Tue, 2007-07-24 at 00:07 -0500, Bob Peterson wrote:
> Here is a set of five patches designed to fix the "invalid metadata
> block" and hang problems encountered when running the revolver test.
>
> In order, the five patches are:
>
> 1. There were still some critical variables being manipulated outside
> the log_lock spinlock. That usually resulted in more hangs.
The BUG_ON(!buffer_mapped()) line in this patch can be removed as its
only debugging.
> 2. The list_move code previously concocted in log.c for bug #238162
> (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238162#c23)
> seems to be causing a problem. That section was reverted. HOWEVER,
> I need to rerun the test cases listed in that bug to make sure
> removing it doesn't cause anything to break. I haven't had time yet.
Moving the assignment head = &sdp->sd_ail1_list; doesn't give us
anything since head is a pointer and will be constant whether we have
the lock or not.
> 3. The try_rgrp_unlink code in rgrp.c had an infinite loop. This was
> caused because the bitmap function rgblk_search can return a block
> less than the "goal" block, in which case it was looping. The fix is
> to make it always march forward as needed.
Ok.
> 4. There was metadata corruption caused because the clone bitmaps weren't
> being kept in synch with the regular bitmaps in some cases.
> Code was added to keep them in synch.
I need to look at this in more detail. You might be right, but its worth
being rather careful in this part of the code.
> 5. Metadata corruption was occurring because page references weren't
> being removed in all cases. I previously added a function called
> detach_bufdata, but I discovered there already WAS a function out
> there to do the job. It's called gfs2_meta_cache_flush. So I added
> a call to that to remove the page references.
> Recently I had been thinking that this was entirely unnecessary, but
> when I removed the code, the metadata corruption problem returned
> immediately. It might be that there is a timing window where the
> pages can be referenced before gfs2_meta_cache_flush is called and
> my patch cleans them up sooner.
Yes, this looks good,
Steve.
prev parent reply other threads:[~2007-07-24 13:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-24 5:07 [Cluster-devel] [PATCH 0 of 5]Bz #248176: GFS2: invalid metadata block, gfs2_meta_indirect_buffer Bob Peterson
2007-07-24 13:21 ` Steven Whitehouse [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=1185283312.8765.431.camel@quoit \
--to=swhiteho@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.