From: Jeff Layton <jlayton@redhat.com>
To: Neil Brown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH 0/2] mountd: clean up rmtab handling
Date: Wed, 13 Dec 2006 08:17:43 -0500 [thread overview]
Message-ID: <457FFD77.6070507@redhat.com> (raw)
In-Reply-To: <17790.229.867008.833159@cse.unsw.edu.au>
Neil Brown wrote:
>
> Does that make sense?
Yes. Thanks for explaining that -- it makes total sense now. I was focusing
on auth_authenticate, which I don't think would behave differently, but you're
clearly correct that we'd need to ensure the same for the kernel caches.
>> As you said, neither the rmtab or the kernel cache is an ideal place to pull
>> this info. So, my inclincation is to stick with the rmtab, and simply have it
>> track what we know is trackable -- mount and unmount calls into mountd. I
>> think having false positives is preferable to possibly having some mounts
>> that are not reflected at all because they have gone idle.
>
> Ok, how about this as a way forward.
>
> 1/ remove that 'my_client' caching.
> 2/ Remove the updates of rmtab on client upcalls and simply do rmtab
> updates with hostname (from get_reliable_hostbyaddr) and path name
> from MOUNT or UMOUNT requests
> 3/ Add -I flag which:
> passes IP address rather than client_compose name to kernel and
> adds rmtab entries on kernel upcalls. It also hard-removes
> rmtab entries on 'UMOUNT' and flush the kernel cache so that the
> next access for that host/path causes an upcall.
> 4/ Add a -? flag (haven't chosen a letter yet) which:
> implies -I, but when asked for a 'DUMP', it calls gethosytbyname
> on each IP address to ge a hostname.
>
> Then the default would be vaguely usable, and more precise information
> would be available (at a cost).
>
At first glance, that sounds reasonable. I'll have a closer look at the code
and your idea and see if I can come up with a patch.
>> Either way, a manpage update is probably also in order to outline the folly
>> of depending on showmount -a :-).
>
> Yes, I would happily accept a patch making such a change.
>
Once we come to consensus on a code patch, I'll have a look at what manpage
changes need to be made.
Thanks,
Jeff
-------------------------------------------------------------------------
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
prev parent reply other threads:[~2006-12-13 13:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 13:07 [PATCH 0/2] mountd: clean up rmtab handling Jeff Layton
2006-12-01 15:29 ` Jeff Layton
2006-12-04 4:38 ` Neil Brown
2006-12-04 6:33 ` Neil Brown
2006-12-05 2:28 ` Jeff Layton
2006-12-05 2:51 ` Jeff Layton
2006-12-09 12:27 ` Jeff Layton
2006-12-04 15:05 ` Jeff Layton
2006-12-11 1:00 ` Neil Brown
2006-12-11 3:40 ` Jeff Layton
2006-12-12 1:07 ` Neil Brown
2006-12-12 7:52 ` Warren Beldad
2006-12-13 13:17 ` Jeff Layton [this message]
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=457FFD77.6070507@redhat.com \
--to=jlayton@redhat.com \
--cc=neilb@suse.de \
--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 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.