cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH 2/2 v2] gfs2: change gfs2 readdir cookie
Date: Wed, 26 Aug 2015 11:02:29 -0500	[thread overview]
Message-ID: <20150826160229.GQ18219@octiron.msp.redhat.com> (raw)
In-Reply-To: <55DD9BD0.1030606@redhat.com>

On Wed, Aug 26, 2015 at 11:58:24AM +0100, Steven Whitehouse wrote:
> Hi,
> >@@ -1218,10 +1220,10 @@ static int compare_dents(const void *a, const void *b)
> >  	int ret = 0;
> >  	dent_a = *(const struct gfs2_dirent **)a;
> >-	hash_a = be32_to_cpu(dent_a->de_hash);
> >+	hash_a = dent_a->de_cookie;
> Does the cookie need endianess conversion? I'd suggest using sparse to check
> that you've not missed any of these.
> 
Since we don't trust the on disk value for this, and recompute it every time, we
can get by without worrying about the endianness. If we did do endian
conversion, we could skip the recomputing step, but only on filesystems
that were never used by gfs2 versions older than this patch, or some of
the cookies would be garbage.  I tested how long computing these take,
and it's not a noticeable amount, so there's really no push for saving
them.

> >  	dent_b = *(const struct gfs2_dirent **)b;
> >-	hash_b = be32_to_cpu(dent_b->de_hash);
> >+	hash_b = dent_b->de_cookie;
> >  	if (hash_a > hash_b)
> >  		ret = 1;


> >@@ -278,6 +282,12 @@ int gfs2_mount_args(struct gfs2_args *args, char
> >*options) case Opt_norgrplvb: args->ar_rgrplvb = 0; break; +
> >case Opt_loccookie: +			args->ar_loccookie = 1;
> >+			break; +		case Opt_noloccookie: +
> >args->ar_loccookie = 0; +			break;
> Hmm. Is there some way we can make it the default, without needing to
> do this? The on-disk format should still be backwards compatible I
> think? Do we need any fsck/gfs2-utils updates too?
> 
The problem is that every node in the cluster must be running this code
(well, actually, they need to be using at least by previous patch), or
things will go wrong. The location based cookies depend on my previous
patch, that copies the dirents to the same offset, when directory leaf
blocks are split. If any node creates a directory entry that splits a
leaf block, and isn't running that code, the location based cookies for
all the copied dirents get changed.  Because of this, we can't make
location cookies the default right away.

On a related note, I do think there might be a way of using the
superblock lvb or possibly a new file pointed to by the superblock for
the nodes to share this sort of compatibility data, so that we could
know if it was safe to enable certain features.
> >  		case Opt_error:
> >  		default:
> >  			pr_warn("invalid mount option: %s\n", o);



> >@@ -304,11 +306,12 @@ struct gfs2_dirent {
> >  	__be16 de_rec_len;
> >  	__be16 de_name_len;
> >  	__be16 de_type;
> >+	__be16 de_rahead;
> >  	union {
> >-		__u8 __pad[14];
> >+		__u8 __pad[12];
> >  		struct {
> >-			__be16 de_rahead;
> >-			__u8 pad2[12];
> >+			__u32 de_cookie; /* ondisk value not used */
> This is an ondisk structure so it should be __be32 to match the rest of the
> structure.

I can do that for consistency, but since we never read the value off disk, it
isn't necessary.

> 
> >+			__u8 pad3[8];
> >  		};
> >  	};
> >  };
> 
> Otherwise looks good. It will need plenty of testing though with lots of
> corner cases to ensure that nothing has been missed,
> 
> Steve.



      reply	other threads:[~2015-08-26 16:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-25 21:10 [Cluster-devel] [GFS2 PATCH 0/2 v2] readdir cookie patches Benjamin Marzinski
2015-08-25 21:10 ` [Cluster-devel] [GFS2 PATCH 1/2 v2] gfs2: keep offset when splitting dir leaf blocks Benjamin Marzinski
2015-08-25 21:10 ` [Cluster-devel] [GFS2 PATCH 2/2 v2] gfs2: change gfs2 readdir cookie Benjamin Marzinski
2015-08-26 10:58   ` Steven Whitehouse
2015-08-26 16:02     ` Benjamin Marzinski [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=20150826160229.GQ18219@octiron.msp.redhat.com \
    --to=bmarzins@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).