[Cluster-devel] [GFS2 PATCH 2/3] Obtaining no_formal_ino from directory entry

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Wed, 2007-06-27 at 01:15 -0400, S. Wendy Cheng wrote:
> Steven Whitehouse wrote:
> 
> >Hi,
> >
> >On Mon, 2007-06-25 at 21:14 -0400, S. Wendy Cheng wrote:
> >  
> >
> >>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.
> >>
> >>-- Wendy
> >>
> >>    
> >>
> >
> >Generally this looks good. Please don't add back the _host structure
> >though - just add an extra no_formal_ino argument to the lookup function
> >which is a u64,
> >  
> >
> 
> The gfs2_inode_lookup() parameter set would be too long. How about this 
> ... we will never use DT_WHT (bit 14) anyway so let's define:
> 
> struct inode *gfs2_inode_lookup(struct super_block *sb,
>                                 unsigned type,   // if invoked from 
> gfs2_get_dentry by NFSD
>                                                           // type would 
> be DT_WHT.
>                                 u64 no_addr,
>                                 u64 no_formal_ino);
> 
> Then we would save one parameter in patch #3 that will use DT_WHT as 
> nfsbypass param ? Patch enclosed.
> 
Ugh! I'd rather not misuse the DT_ types. We can just use DT_UNKNOWN I
think as we can tell the difference between NFS and unlinked recovery
simply by looking to see if no_formal_ino is non-zero or not (since zero
can never be a valid no_formal_ino). Do you think thats ok?

Steve.

> -- Wendy
> 
> 
>