From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: nfs@lists.sourceforge.net, Simon Peter <simon.peter@gmx.de>
Subject: Re: Delays on "first" access to a NFS mount
Date: Wed, 7 Mar 2007 16:54:06 -0500 [thread overview]
Message-ID: <20070307215406.GR26553@fieldses.org> (raw)
In-Reply-To: <EXNANE0169aZbLAX3cf00000075@exnane01.hq.netapp.com>
On Wed, Mar 07, 2007 at 04:23:23PM -0500, Talpey, Thomas wrote:
> At 04:17 PM 3/7/2007, J. Bruce Fields wrote:
> >There's an expiry time that's passed down with each cache entry. In
> >this particular case it's 30 minutes. There's also a "flush" file you
> >can write to to ask that the whole cache be flushed. I don't remember
> >how this works in detail, though.
>
> Aha - so the time comes from mountd. There's some sort of refresh
> timer that the kernel triggers though. So it's not a deadline of this
> time (I think). Or is it.
The kernel sweeps through the cache every now and then and cleans out
expired entries. I think it also takes note of the earliest future
expiry it runs across in the process, and uses that to decide when to
check next. This is all in linux/net/sunrpc/cache.c:cache_clean().
> The "flush" file lives in /proc/net/rpc/nfsd.export, and you write an
> integer value to it. I *think* it then flushes any entries which are
> more than that many seconds old.
Right.
> The whole thing makes my head hurt and I try not to look at it.
Well, non-head-hurty ideas always welcomed. I've got two export-related
problems to fix:
- Our current NFSv4 pseudofs fsid=0 hack is a pain to administer
and results in inconsistent paths across different NFS
versions.
- The trick of using the pseudoflavor as a client name (so doing
/export gss/krb5(rw)
instead of
/export *(sec=krb5,rw)
), is inconsistent with what other os's do, and makes it
impossible to specify restrictions based both on flavor and on
ip network/dns name/netgroup.
While I'm at it Trond and Christoph and others seem to be asking whether
we can't make some more fundamental changes, such as:
- Maintaining a static in-kernel exports table instead of
loading it on demand from mountd, and
- divorcing the exports namespace completely from any local
process namespace, to the extent that you could even just say
"I want to export /dev/sda7 as /usr/local/bin" without first
mounting /dev/sda7 someplace.
But I really need a better idea of the requirements on the exports
system. And some other examples to look at wouldn't hurt either. (Take
pity on me, Linux is all I know....)
--b.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-03-07 21:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-07 10:23 Delays on "first" access to a NFS mount Simon Peter
2007-03-07 12:38 ` Talpey, Thomas
2007-03-07 13:22 ` Simon Peter
2007-03-07 15:06 ` Simon Peter
2007-03-07 15:10 ` Simon Peter
2007-03-07 15:42 ` J. Bruce Fields
2007-03-07 18:44 ` Simon Peter
2007-03-07 20:29 ` J. Bruce Fields
2007-03-07 21:46 ` Simon Peter
2007-03-07 22:05 ` J. Bruce Fields
2007-03-07 23:19 ` Simon Peter
2007-03-07 22:09 ` Neil Brown
2007-03-08 15:49 ` Simon Peter
2007-03-09 13:02 ` Simon Peter
2007-03-09 14:59 ` J. Bruce Fields
2007-03-07 20:31 ` Talpey, Thomas
2007-03-07 20:50 ` J. Bruce Fields
2007-03-07 21:07 ` Talpey, Thomas
2007-03-07 21:17 ` J. Bruce Fields
2007-03-07 21:23 ` Talpey, Thomas
2007-03-07 21:54 ` J. Bruce Fields [this message]
2007-03-07 22:37 ` Neil Brown
2007-03-07 23:06 ` J. Bruce Fields
2007-03-07 23:39 ` Neil Brown
2007-03-08 5:14 ` J. Bruce Fields
2007-03-08 5:42 ` Neil Brown
2007-03-08 13:43 ` Olaf Kirch
2007-03-08 21:27 ` J. Bruce Fields
2007-03-09 15:02 ` Olaf Kirch
2007-03-16 21:47 ` Christoph Hellwig
2007-03-16 21:54 ` J. Bruce Fields
2007-03-16 21:57 ` Christoph Hellwig
2007-03-07 23:24 ` J. Bruce Fields
2007-03-07 23:51 ` Neil Brown
2007-03-08 4:36 ` J. Bruce Fields
2007-03-08 13:27 ` Olaf Kirch
2007-03-08 21:46 ` J. Bruce Fields
2007-03-07 22:15 ` Neil Brown
2007-03-07 21:40 ` Simon Peter
2007-03-07 22:17 ` Neil Brown
2007-03-07 22:36 ` Talpey, Thomas
2007-03-07 22:48 ` Neil Brown
2007-03-07 22:56 ` Talpey, Thomas
2007-03-07 22:12 ` Neil Brown
2007-03-07 22:23 ` J. Bruce Fields
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=20070307215406.GR26553@fieldses.org \
--to=bfields@fieldses.org \
--cc=Thomas.Talpey@netapp.com \
--cc=nfs@lists.sourceforge.net \
--cc=simon.peter@gmx.de \
/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.