cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 Patch] pass formal ino in do_filldir_main
Date: Fri, 23 Feb 2007 22:56:41 -0500	[thread overview]
Message-ID: <45DFB779.9000100@redhat.com> (raw)
In-Reply-To: <1170927758.11001.467.camel@quoit.chygwyn.com>

Steve,

I gave this issue some more thoughts - would like to suggest we take 
this patch (at least for now) since it aligns with current code base.

The no_formal_ino is apparently intented to get returned back to user 
space due to its unique-ness (and we have to trust pick_formal_ino() 
does its job right). With normal readdir system call, after the inode 
number is sent to user space, there is no route (I've checked) for it to 
come back to kernel. So the only user that would use these filldir ino 
inside the kernel is NFSD. NFSD calls gfs2_ilookup() that requires 
no_formal_ino.

If you look further... The current lookup code actually uses 
no_formal_ino, not no_addr. The two main "gate" routines that controls 
ino-to-inode conversion are:

* gfs2_ilookup() (used by NFS route)
* gfs2_inode_lookup() (used by VFS that calls gfs2_lookup()).

Both use no_formal_ino - gfs2_inode_lookup() logic hides this behind the 
little wrapper "gfs2_iget()". Since current VFS side's lookup has been 
working fine, this no_formal_ino idea apparently is working. So let's 
make NFSD side work the *same* way. I'm convinced this patch does a 
right thing.

I don't dispute using generation number may not be a bad idea and may 
perform better. However, if we really look into the details, it is not 
easy for current code structure. Since we have something already 
working, it is not wise to mess this code layout at this moment.

Make sense ?

-- Wendy




  reply	other threads:[~2007-02-24  3:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07  4:51 [Cluster-devel] [GFS2 Patch] pass formal ino in do_filldir_main Wendy Cheng
2007-02-07 10:49 ` Steven Whitehouse
2007-02-07 22:35   ` Wendy Cheng
2007-02-07 23:37     ` Wendy Cheng
2007-02-08  9:42     ` Steven Whitehouse
2007-02-24  3:56       ` Wendy Cheng [this message]
2007-02-26 15:45         ` Steven Whitehouse
2007-02-26 16:11           ` Jonathan E Brassow
2007-02-26 17:16             ` Steven Whitehouse
2007-02-27 20:04               ` Wendy Cheng
2007-02-28  9:03                 ` Steven Whitehouse
2007-02-28 16:24                   ` Wendy Cheng
2007-02-28 16:26                     ` Wendy Cheng
2007-02-28 16:46                     ` Steven Whitehouse

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=45DFB779.9000100@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).