All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2] Fix problems relating to execution of files	on GFS2
Date: Tue, 08 Jan 2008 08:40:56 +0000	[thread overview]
Message-ID: <1199781656.22038.94.camel@quoit> (raw)
In-Reply-To: <47826B48.5070109@redhat.com>

Hi,

On Mon, 2008-01-07 at 13:11 -0500, Wendy Cheng wrote:
> Steven Whitehouse wrote:
> > --- a/fs/gfs2/ops_inode.c
> > +++ b/fs/gfs2/ops_inode.c
> > @@ -113,8 +113,18 @@ static struct dentry *gfs2_lookup(struct inode *dir, struct dentry *dentry,
> >  	if (inode && IS_ERR(inode))
> >  		return ERR_PTR(PTR_ERR(inode));
> >  
> > -	if (inode)
> > +	if (inode) {
> > +		struct gfs2_glock *gl = GFS2_I(inode)->i_gl;
> > +		struct gfs2_holder gh;
> > +		int error;
> > +		error = gfs2_glock_nq_init(gl, LM_ST_SHARED, LM_FLAG_ANY, &gh);
> >   
> 
> ok, so this shared glock is now added *back*.  As I recall, its removal 
> about one year ago had caused great grief in NFS portion of logic - had 
> to do a tedious work to make NFS work due to this change. Now, the logic 
> is reverted - has performance impact been measured (since it is a disk 
> read) ?
> 
> -- Wendy

Well yes and no. Its not in the same place as before, its only in the
VFS lookup code and not in the GFS2 internal lookup code, and I really
didn't want to have to add it back here if it could at all be avoided,
but since there is no dcache revalidate in the initial lookup case it
seems we have no choice now :(

Some tests with postmark show no measurable difference in performance so
far, so maybe its not so bad. We still need to get to the point where we
can use lookup intents and solve the problem properly,

Steve.




      reply	other threads:[~2008-01-08  8:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-07 17:27 [Cluster-devel] [GFS2] Fix problems relating to execution of files on GFS2 Steven Whitehouse
2008-01-07 18:11 ` Wendy Cheng
2008-01-08  8:40   ` 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=1199781656.22038.94.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.