[Cluster-devel] GFS2: Make . and .. qstrs constant

Steven Whitehouse swhiteho at redhat.com
Thu Sep 9 08:32:55 UTC 2010


Hi,

On Wed, 2010-09-08 at 21:57 -0400, Christoph Hellwig wrote:
> On Wed, Sep 08, 2010 at 04:35:20PM +0100, Steven Whitehouse wrote:
> > >From bc9fb728211162a24afd341c9ffb85e7b459fb8d Mon Sep 17 00:00:00 2001
> > From: Steven Whitehouse <swhiteho at redhat.com>
> > Date: Wed, 8 Sep 2010 16:02:13 +0100
> > Subject: GFS2: Make . and .. qstrs constant
> > 
> > Rather than calculating the qstrs for . and .. each time
> > we need them, its better to keep a constant version of
> > these and just refer to them when required.
> > 
> > Signed-off-by: Steven Whitehouse <swhiteho at redhat.com>
> > 
> > +const struct qstr gfs2_qdot = { .name = ".", .len = 1, .hash = 0xed4e242};
> > +const struct qstr gfs2_qdotdot = { .name = "..", .len = 2, .hash = 0x9608161c};
> 
> I don't think hardcoding the values for the current dcache hash is a
> good idea.  We have already changed that hash in not too recent history
> and chances are we'll do again at some point.
> 
The hash is (or can be, and is in GFS2's case) fs specific. The values
won't change for GFS2 and if the dcache ends up not supporting fs
specific hash values, we'll have to change a fair amount of our code.

> Just calculate it once at startup time using the normal hash function.
> Extra points for doing it in core code and finding places in other
> filesystems that have the same issue.
> 
Yes, I did think about that, but being able to mark it const so that I
could be sure it wouldn't change seemed like a useful thing to do,

Steve.





More information about the Cluster-devel mailing list