public inbox for cluster-cvs@sourceware.org
help / color / mirror / Atom feed
From: Bob Peterson <rpeterso@fedoraproject.org>
To: cluster-cvs-relay@redhat.com
Subject: cluster: STABLE2 - gfs2_edit savemeta needs to save freemeta blocks
Date: Thu, 21 May 2009 19:06:00 -0000	[thread overview]
Message-ID: <20090521190540.AA7891201FA@lists.fedorahosted.org> (raw)

Gitweb:        http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=a9010ac82a760ea0bf4506050e456745daf963b9
Commit:        a9010ac82a760ea0bf4506050e456745daf963b9
Parent:        649d744d31616d67c8179f7e4f2a0774010d9965
Author:        Bob Peterson <rpeterso@redhat.com>
AuthorDate:    Thu May 21 13:37:29 2009 -0500
Committer:     Bob Peterson <rpeterso@redhat.com>
CommitterDate: Thu May 21 14:04:14 2009 -0500

gfs2_edit savemeta needs to save freemeta blocks

bz 502056

The gfs2_edit savemeta function was not saving off
blocks of type 2, which correspond to "free metadata" in
gfs and "unlinked dinodes" in gfs2.  This turned out to be
a problem because if that metadata is restored and gfs is
tested against it, it resulted in metadata allocation
problems.  For example, gfs_grow may make the decision to
allocate a metadata block, and try to re-use a block that's
marked as "free metadata" in the gfs bitmap.  But since the
block hadn't been saved at "savemeta" time, the block was
never restored as metadata and therefore the metadata
header may be missing, so gfs-kernel withdrew with a file
system error.
---
 gfs2/edit/savemeta.c |   46 ++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/gfs2/edit/savemeta.c b/gfs2/edit/savemeta.c
index 0e2aaff..70b7262 100644
--- a/gfs2/edit/savemeta.c
+++ b/gfs2/edit/savemeta.c
@@ -411,6 +411,40 @@ void get_journal_inode_blocks(void)
 	}
 }
 
+int next_rg_freemeta(struct rgrp_list *rgd, uint64_t *block, int first)
+{
+	struct gfs2_bitmap *bits = NULL;
+	uint32_t length = rgd->ri.ri_length;
+	uint32_t blk = (first)? 0: (uint32_t)((*block+1)-rgd->ri.ri_data0);
+	int i;
+
+	if(!first && (*block < rgd->ri.ri_data0)) {
+		log_err("next_rg_freemeta:  Start block is outside rgrp "
+			"bounds.\n");
+		exit(1);
+	}
+	for(i=0; i < length; i++){
+		bits = &rgd->bits[i];
+		if(blk < bits->bi_len*GFS2_NBBY)
+			break;
+		blk -= bits->bi_len*GFS2_NBBY;
+	}
+	for(; i < length; i++){
+		bits = &rgd->bits[i];
+		blk = gfs2_bitfit((unsigned char *)rgd->bh[i]->b_data +
+				  bits->bi_offset, bits->bi_len, blk,
+				  GFS2_BLKST_UNLINKED);
+		if(blk != BFITNOENT){
+			*block = blk + (bits->bi_start * GFS2_NBBY) + rgd->ri.ri_data0;
+			break;
+		}
+		blk=0;
+	}
+	if(i == length)
+		return -1;
+	return 0;
+}
+
 void savemeta(char *out_fn, int saveoption)
 {
 	int out_fd;
@@ -564,9 +598,9 @@ void savemeta(char *out_fn, int saveoption)
 			}
 			/* Save off the other metadata: inodes, etc. */
 			if (saveoption != 2) {
-				while (!gfs2_next_rg_meta(rgd, &block, first)) {
-					int blktype;
+				int blktype;
 
+				while (!gfs2_next_rg_meta(rgd, &block, first)) {
 					warm_fuzzy_stuff(block, FALSE, TRUE);
 					blktype = save_block(sbd.device_fd,
 							     out_fd, block);
@@ -574,6 +608,14 @@ void savemeta(char *out_fn, int saveoption)
 						save_inode_data(out_fd);
 					first = 0;
 				}
+				/* Save off the free/unlinked meta blocks too.
+				   If we don't, we may run into metadata
+				   allocation issues. */
+				while (!next_rg_freemeta(rgd, &block, first)) {
+					blktype = save_block(sbd.device_fd,
+							     out_fd, block);
+					first = 0;
+				}
 			}
 			gfs2_rgrp_relse(rgd, not_updated);
 		}


                 reply	other threads:[~2009-05-21 19:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20090521190540.AA7891201FA@lists.fedorahosted.org \
    --to=rpeterso@fedoraproject.org \
    --cc=cluster-cvs-relay@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).