From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/3] gfs2_edit: Fix find_mtype and support gfs1 structures
Date: Fri, 25 May 2012 11:27:59 +0100 [thread overview]
Message-ID: <4FBF5EAF.1070309@redhat.com> (raw)
In-Reply-To: <1337940424-20662-2-git-send-email-anprice@redhat.com>
On 25/05/12 11:07, Andrew Price wrote:
> Fixes up find_mtype to really iterate over the metadata array and to
> choose between gfs2 and gfs1 structures.
>
> Signed-off-by: Andrew Price<anprice@redhat.com>
> ---
> gfs2/edit/hexedit.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/gfs2/edit/hexedit.c b/gfs2/edit/hexedit.c
> index 69d1940..8311534 100644
> --- a/gfs2/edit/hexedit.c
> +++ b/gfs2/edit/hexedit.c
> @@ -813,14 +813,15 @@ int display_block_type(int from_restore)
> return ret_type;
> }
>
> -static const struct lgfs2_metadata *find_mtype(uint32_t mtype)
> +static const struct lgfs2_metadata *find_mtype(uint32_t mtype, int gfs1)
> {
> const struct lgfs2_metadata *m = lgfs2_metadata;
> unsigned n = 0;
>
> do {
> - if (m->gfs2&& m->mh_type == mtype)
> - return m;
> + if (((gfs1&& m[n].gfs1) || (!gfs1&& m[n].gfs2))
I'm wondering if we should represent the version metadata as flags
instead of separate gfs1 and gfs2 fields and define some constants so we
can do the comparison in one go, e.g.
if ((m[n].versions & versions) ...
Where versions is some combination of defined constants passed into the
function like LGFS2_VER_1 | LGFS2_VER_2
But that has its own drawbacks I guess so I'm probably just splitting
hairs. What do you think?
Andy
> + && m[n].mh_type == mtype)
> + return&m[n];
> n++;
> } while (n< lgfs2_metadata_size);
>
> @@ -934,7 +935,7 @@ static int hexdump(uint64_t startaddr, int len)
> }
> print_gfs2("] ");
> if (print_field>= 0) {
> - const struct lgfs2_metadata *m = find_mtype(get_block_type(bh));
> + const struct lgfs2_metadata *m = find_mtype(get_block_type(bh), sbd.gfs1);
> if (m) {
> const struct lgfs2_metafield *f;
> unsigned n;
next prev parent reply other threads:[~2012-05-25 10:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 10:07 [Cluster-devel] [PATCH 1/3] gfs2-utils: Remove references to unlinked file tag Andrew Price
2012-05-25 10:07 ` [Cluster-devel] [PATCH 2/3] gfs2_edit: Fix find_mtype and support gfs1 structures Andrew Price
2012-05-25 10:27 ` Andrew Price [this message]
2012-05-25 10:40 ` Steven Whitehouse
2012-05-25 10:07 ` [Cluster-devel] [PATCH 3/3] gfs2_edit: Clean up some magic offsets Andrew Price
2012-05-25 10:19 ` Steven Whitehouse
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=4FBF5EAF.1070309@redhat.com \
--to=anprice@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 NNTP newsgroup(s).