[Cluster-devel] [GFS2 PATCH 2/3] Obtaining no_formal_ino from directory entry
Steven Whitehouse
swhiteho at redhat.com
Wed Jun 27 13:13:37 UTC 2007
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
>
>
>
More information about the Cluster-devel
mailing list