Linux NFS development
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: chuck.lever@oracle.com
Cc: nfs@lists.sourceforge.net, Jeff Layton <jlayton@redhat.com>
Subject: Re: [PATCH] nfs-utils: make auth_reload respect	sub-second timestamps on etab
Date: Thu, 26 Apr 2007 14:56:42 +1000	[thread overview]
Message-ID: <17968.12554.934818.359167@notabene.brown> (raw)
In-Reply-To: message from Chuck Lever on Wednesday April 25

On Wednesday April 25, chuck.lever@oracle.com wrote:
> 
> Hi Jeff-
> 
> I don't know much about the export logic, but why not use inode change 
> notification instead of time stamps?

inotify is 2.6 only I think.  I'm not sure I want to exclude 2.4
people just yet (or do I ??).

Given that exportfs replaces the file with a new one, would we need to
get notification on the directory, or just on the file?  Does it make
it more complicated, or easier?

Actually, mountd could open etab and hold it open. auth_reload could
stat "/var/lib/nfs/etab" and if it is a different file, then the
content is presumably different, while if it is the same file, we can
be certain the content is unchanged.

Further, we would be certain only to read each version once - zero
risk of re-parsing data when there is no change.

That might be an even better option .... anyone want to code it up??

Or is it wrong to depend on current exportfs behaviour?

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-04-26  4:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-25 17:39 [PATCH] nfs-utils: make auth_reload respect sub-second timestamps on etab Jeff Layton
2007-04-25 18:09 ` Jeff Layton
2007-04-25 20:13   ` Jeff Layton
2007-04-25 21:29     ` Chuck Lever
2007-04-26  4:56       ` Neil Brown [this message]
2007-04-26 12:05         ` Jeff Layton
2007-04-26 16:23           ` Jeff Layton
2007-04-26 16:58             ` J. Bruce Fields
2007-04-26 17:00               ` Jeff Layton
2007-04-26 17:24                 ` J. Bruce Fields
2007-04-26 18:29                   ` Jeff Layton
2007-05-03  0:55                     ` Neil Brown
2007-05-03 11:58                       ` Jeff Layton
2007-05-03 12:11                         ` Jeff Layton
2007-04-26 17:33                 ` Jeff Layton
2007-04-26 12:35         ` J. Bruce Fields
2007-04-26  4:50 ` Neil Brown
2007-04-26 11:50   ` Jeff Layton

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=17968.12554.934818.359167@notabene.brown \
    --to=neilb@suse.de \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    /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