All of lore.kernel.org
 help / color / mirror / Atom feed
From: S. Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH 0/3] NFS fixes from SPECsfs test runs
Date: Mon, 25 Jun 2007 21:14:17 -0400	[thread overview]
Message-ID: <46806869.4030708@redhat.com> (raw)

Red Hat bugzilla 243136 - bug fixes found during SPECsfs test runs:

[Patch 1-3] EIO error from gfs2_block_truncate_page
Code segment inside gfs2_block_truncate_page() doesn't set the return 
code correctly. This causes NFSD erroneously returns EIO back to client 
with setattr procedure call (truncate error),

[Patch 3-2] Obtaining no_formal_ino from directory entry
GFS2 lookup code doesn't ask for inode shared glock. This implies during 
in-memory inode creation for existing file, GFS2 will not disk-read in 
the inode contents. This leaves no_formal_ino un-initialized during 
lookup time. The un-initialized no_formal_ino is subsequently encoded 
into file handle. Clients will get ESTALE error whenever it tries to 
access these files.

[Patch 3-3] Remove i_mode passing from NFS File Handle
GFS2 passes i_mode within NFS File Handle. Other than the wrong 
assumption that there is always room for this extra 16 bit value, the 
current gfs2_get_dentry doesn't really need the i_mode to work 
correctly. Note that GFS2 NFS code does go thru the same lookup code 
path as direct file access route (where the mode is obtained from name 
lookup) but gfs2_get_dentry() is coded for different purpose. It is not 
used during lookup time. It is part of the file access procedure call.  
When the call is invoked, if on-disk inode is not in-memory, it has to 
be read-in. This makes i_mode passing a useless overhead.

-- Wendy




                 reply	other threads:[~2007-06-26  1:14 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=46806869.4030708@redhat.com \
    --to=wcheng@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.