From: Neil Brown <neilb@suse.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@infradead.org>,
nfs@lists.sourceforge.net, "Talpey,
Thomas" <Thomas.Talpey@netapp.com>,
Simon Peter <simon.peter@gmx.de>
Subject: Re: Delays on "first" access to a NFS mount
Date: Thu, 8 Mar 2007 10:39:23 +1100 [thread overview]
Message-ID: <17903.19755.146916.321440@notabene.brown> (raw)
In-Reply-To: message from J. Bruce Fields on Wednesday March 7
On Wednesday March 7, bfields@fieldses.org wrote:
>
> So could you remind me what the uses cases are here? Who is it that
> requires demand loading, and why?
Partly it is the principle that demand-based configuration is more
flexible. Witness the various efforts to replace rc.d scripts with
something event/demand based.
The IP->clientname table must be demand loaded because you obviously
cannot know all needed IP addresses in advance. (The rmtab experience
proves that)
The clientname+path->export-options table must be demand loaded
because - depending a bit of how you choose client names and how
complicated /etc/exports is - you either don't know all client names
in advance, or computing them all is complex and wasteful.
The fsid->path table could possible be made 'static', but I think
demand-loading is still best. There are multiple possible fsids for
some filesystems, and telling the kernel about all of them when only
one will be used seems wasteful. And the filesystems may not all be
available when you try to create the static table. You could update
the table at every mount, but with demand-loading, you don't have to.
Imagine having hundreds of filesystems on some sort of library (a CD
library?) where each can be identified by a UUID which gets stored in
the fsid in the filehandle.
Imagine a simple extension to mountd so that a call-out were made when
an unknown filehandle arrived. This callout could mount the required
filesystem and export it. Maybe the library only allows 3 filesystems
to be mounted at a time, so it would unmount the lease-recently-used
one.
How are you going to handle that system except with demand-loading of
the fsid->path table?
>
> I'll promise to write it all down someplace and then hopefully we won't
> have to re-ask the same questions too many times....
Sounds like a fine idea.
I have often wanted to write a 'Linux commentary' that explains all
the hows and whys of things. I even started some bits once (to help
me understand the VFS layer). But Linux changes so fast that any
entry in such a commentary would be out-of-date before it was
written....
NeilBrown
-------------------------------------------------------------------------
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 23:39 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
2007-03-07 22:37 ` Neil Brown
2007-03-07 23:06 ` J. Bruce Fields
2007-03-07 23:39 ` Neil Brown [this message]
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=17903.19755.146916.321440@notabene.brown \
--to=neilb@suse.de \
--cc=Thomas.Talpey@netapp.com \
--cc=bfields@fieldses.org \
--cc=hch@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox