[autofs] Re: [NFS] bug in linux mount? (says NetApp)
On 7/11/06, Gregory Baker [EMAIL PROTECTED] wrote: We have thousands of linux clients hitting netapp file servers (many 3500 series, clustered) on a local gigabit LAN. From time to time, applications return file not found when attempting to automount a directory and access a file. An example of this is a long running process, which reads in data, processes it for hours (in which time the filesystem is unmounted) then tries to read more data from that mount point (which causes a file not found error in the application). This occurs about 1/100th of the time. Researching at Netapp turns up this bit by Chuck Lever (Linux NFS contributer) Using the Linux NFS Client with Network Appliance Filers http://www.netapp.com/libr ary/tr/3183.pdf (February 2006) page 10 says... Due to a bug in the mount command, the default retransmission timeout value on Linux for NFS over TCP is quite small...To obtain standard behavior, we strongly recommend using timeo=600, retrans=2 explicitly when mounting via TCP. Our defaults (assuming man pages are correct, RedHat Enterprise Linux 3) would be timeo=7, retrans=3, which translates to 7+14+28+56 = 105 tenths of a second (10 seconds). It appears netapp is suggesting waiting 600+600 = 1200 tenths (120 seconds) before giving up on the mount command... It's important to distinguish two different types of timeouts. 1. The mount operation has timed out. 2. After the mount operation succeeds, an NFS RPC operation has timed out. TR-3183 discusses the proper settings for 2, but you are experiencing 1. The automounter attempts to mount one of the filer's exports, but the mount request times out causing the mounted-on directory to be exposed. Your filer is heavily loaded, and the filer's mountd is single-threaded. The filer may also be experiencing delays when requesting information from external servers (like DNS or NIS), in which case the mount request is held up at the filer. Both sides are at fault: the Linux mount command should retry (and I believe later releases of RHEL 3 were fixed to do this) and the filer configuration should be reviewed to make sure there are no avoidable delays while processing mount requests. * What bug in the mount command do you believe NetApp is talking about? The bug is that the mount command overrides the proper default RPC timeout value with a timeout value of 0.7 seconds. This is *not* the timeout for mount operations, it is the timeout for the in-kernel NFS client to retransmit RPC requests. * What do you think proper options for NFS auto/mounts would be for extremely busy centralized NFS filers? If you are using NFS over TCP, the proper timeout value is 60 seconds. * What is the reference standard behavior? Solaris, which is the NFSv3 reference implementation, uses effectively a 60 second timeout on TCP mounts. -- We who cut mere stones must always be envisioning cathedrals -- Quarry worker's creed ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Problem with mount.nfs4 on latest Fedora 10 updates
On Aug 13, 2009, at 12:50 PM, Howard Wilkinson wrote: I have just upgraded a couple of servers from FC9 to FC10 and I am seeing a major problem with mount.nfs4. This occurs when autofs calls the mount program. It then runs at 100% CPU and never terminates. I have VMs that are running similar configuration successfully, so this is something driven by being on bare metal. Kernel is 2.6.27.29-170.2.78.fc10.i686.PAE nfs-utils is nfs-utils-1.1.4-8.fc10.i386 autofs is autofs-5.0.3-41.i386 Command running is /sbin/mount.nfs4 battleaxe:/ /hosts/battleaxe -s -o rw,nosuid,nodev,tcp,rsize=32768,wsize=32768,hard,intr The autofs mount has worked and the directories under /hosts/ battleaxe have been successfully accessed prior to the problem occuring - I suspect this is a remount after and expire has occurred. Anybody seen this before? Anybody know what I can do to get round this? [I am on the way to FC11 but will have to live with FC10 for a while (a week or so)] Any extra information I can acquire to diagnose this? There is nothing in the log files to indicate anything going wrong, I could turn debug on if I knew what to set and which messages to strip once I do. You could start with sudo rpcdebug -m nfs -s mount and look in /var/ log/messages, or you can strace the running mount command. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [ANNOUNCE] fedfs-utils for Linux
Announcing public availability of fedfs-utils for Linux RFC 5716 introduces the Federated File System (FedFS, for short). FedFS is an extensible standardized mechanism by which system administrators construct a coherent namespace across multiple file servers using file system referrals. The fedfs-utils package is an implementation of the user space components that provide FedFS features on Linux. The package is released under GPL version 2. The current release is 0.6.1. This is a very early alpha release for technology preview. Administrative, programming, and command line interfaces will change as this package evolves, and must not be relied on. See http://oss.oracle.com/projects/fedfs-utils for more information and source code downloads. Two mailman mailing lists are also available: fedfs-utils-annou...@oss.oracle.com fedfs-utils-de...@oss.oracle.com Future release announcements will occur only on fedfs-utils-announce. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [ANNOUNCE] fedfs-utils for Linux
On Apr 12, 2011, at 11:54 AM, Christoph Hellwig wrote: On Thu, Apr 07, 2011 at 04:24:29PM -0400, Chuck Lever wrote: See http://oss.oracle.com/projects/fedfs-utils for more information and source code downloads. Two mailman mailing lists are also available: fedfs-utils-annou...@oss.oracle.com fedfs-utils-de...@oss.oracle.com Is it really a good idea to not just one but two separate mailinglist for something tightly integrated with nfs anyway? Why not just use linux-nfs for the small amount of additional traffic? FedFS is agnostic to the underlying file protocol. The current Linux FedFS prototype happens to be NFS-only, but we don't expect it to stay that way. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [PATCH] FedFS file system client support
Hi- The next release of fedfs-utils will provide all necessary components for a Linux NFS client to participate in a FedFS domain as a file system client. This new utility is intended to be a part of the upcoming release. I'm interested in comments on this approach. Ian had suggested a new lookup module, but a program map looked simpler to prototype and has the great advantage of no dependencies between fedfs-utils and autofs. If program maps have some nasty problem that require the use of a lookup module, we can take that next step. --- Chuck Lever (1): mount: Add automounter program map for FedFS .gitignore |1 INSTALL| 10 +- README | 14 ++- doc/man/Makefile.am|2 doc/man/fedfs-map-nfs4.8 | 154 doc/man/fedfs.7|4 + src/mount/Makefile.am |5 + src/mount/fedfs-map-nfs4.c | 242 8 files changed, 422 insertions(+), 10 deletions(-) create mode 100644 doc/man/fedfs-map-nfs4.8 create mode 100644 src/mount/fedfs-map-nfs4.c -- Chuck Lever ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] [PATCH] mount: Add automounter program map for FedFS
This new utility interprets the passed-in key as a FedFS domain, performs a DNS SRV lookup, and generates the mount.nfs parameters needed to mount the domain. It can handle multiple read-only and read-write domain root replicas using support already built into the automounter. The FedFS entry in the master map might look like this: /nfs4 /usr/sbin/fedfs-map-nfs4 To support other file system protocols, additional lines in the master map and another program map utility (or options for this one) would be needed. Benefits: o Simple to configure o The TLD can be placed anywhere on the client o No additional build or package dependencies on nfs-utils or autofs Signed-off-by: Chuck Lever chuck.le...@oracle.com --- .gitignore |1 INSTALL| 10 +- README | 14 ++- doc/man/Makefile.am|2 doc/man/fedfs-map-nfs4.8 | 154 doc/man/fedfs.7|4 + src/mount/Makefile.am |5 + src/mount/fedfs-map-nfs4.c | 242 8 files changed, 422 insertions(+), 10 deletions(-) create mode 100644 doc/man/fedfs-map-nfs4.8 create mode 100644 src/mount/fedfs-map-nfs4.c diff --git a/.gitignore b/.gitignore index ce06ff1..41daf0f 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ src/fedfsd/fedfsd src/resolve-junction/resolve-junction src/nsdbparams/nsdbparams src/mount/mount.fedfs +src/mount/fedfs-map-nfs4 libadmin.a libjunction.a libnsdb.a diff --git a/INSTALL b/INSTALL index 8cb8e9e..548381b 100644 --- a/INSTALL +++ b/INSTALL @@ -143,12 +143,14 @@ FedFS file server FedFS client - o Install mount.fedfs + o Install /usr/sbin/fedfs-map-nfs4 - o Create a local /nfs4 directory, and subdirectories for the FedFS -domains you want to mount + o Create a local /nfs4 directory - o Add lines to /etc/fstab to mount the domains + o Install and configure autofs + + o Add an entry to the master map (usually /etc/auto.master) for +the /nfs4 directory and restart autofs FedFS admin client diff --git a/README b/README index 0067ac2..78b9647 100644 --- a/README +++ b/README @@ -59,7 +59,10 @@ changed over time. Installable components include: - o A mount command to mount the top of a FedFS domain namespace + o An automounter program map to manage the FedFS domain namespace + on FedFS-enabled clients + + o A mount command to mount parts of a FedFS domain namespace o An ONC RPC service daemon that runs on file servers enabling the management by remote FedFS ADMIN clients of FedFS junctions @@ -81,9 +84,14 @@ Installable components include: o HTML Doxygen style documentation with built-in source browser +The automounter program map is a subcommand invoked by the automounter +to locate FedFS domains and construct appropriate mount options for +mounting domain roots. It is used in conjunction with the Linux +autofs facility. + The mount command is a subcommand invoked by mount(8) to handle the -housekeeping needed to find and mount FedFS domains at the top of the -client's FedFS namespace (usually /nfs4 for NFSv4 servers). +housekeeping needed to find and mount part or all of FedFS domain +name spaces. The fedfsd program is an RPC server that allows remote administrators to create FedFS junctions in local file systems. FedFS ADMIN requests that diff --git a/doc/man/Makefile.am b/doc/man/Makefile.am index 7f92ebf..83c6d03 100644 --- a/doc/man/Makefile.am +++ b/doc/man/Makefile.am @@ -24,6 +24,6 @@ ## dist_man7_MANS = fedfs.7 -dist_man8_MANS = rpc.fedfsd.8 mount.fedfs.8 +dist_man8_MANS = rpc.fedfsd.8 mount.fedfs.8 fedfs-map-nfs4.8 CLEANFILES = cscope.in.out cscope.out cscope.po.out DISTCLEANFILES = Makefile.in diff --git a/doc/man/fedfs-map-nfs4.8 b/doc/man/fedfs-map-nfs4.8 new file mode 100644 index 000..ffc5b6a --- /dev/null +++ b/doc/man/fedfs-map-nfs4.8 @@ -0,0 +1,154 @@ +.\@(#)fedfs-map-nfs4.8 +.\ +.\ @file doc/man/fedfs-map-nfs4.8 +.\ @brief man page for fedfs-map-nfs4 command +.\ + +.\ +.\ Copyright 2011 Oracle. All rights reserved. +.\ +.\ This file is part of fedfs-utils. +.\ +.\ fedfs-utils is free software; you can redistribute it and/or modify +.\ it under the terms of the GNU General Public License version 2.0 as +.\ published by the Free Software Foundation. +.\ +.\ fedfs-utils is distributed in the hope that it will be useful, but +.\ WITHOUT ANY WARRANTY; without even the implied warranty of +.\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +.\ GNU General Public License version 2.0 for more details. +.\ +.\ You should have received a copy of the GNU General Public License +.\ version 2.0 along with fedfs-utils. If not, see: +.\ +.\http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt +.\ +.TH FEDFS-MAP-NFS4 8 30 Apr 2011 +.SH NAME +fedfs-map-nfs4 \- generate automounter program
[autofs] Thoughts on dynamic networking with AutoFS/NFS
From: Ian Kent ra...@themaw.net On Thu, 2011-06-16 at 20:20 +0100, Colin Simpson wrote: Hi I was just wondering what the thoughts (maybe plans) are for making autofs/nfs more dynamic in the new world of dynamic networking with the likes of Network Manager now being the default. I've read this a couple of times now and I'm still not sure what to say because the mail is so open ended. But here are a few comments anyway. That might mean dbus integration which I've tried to avoid because, to me, that looks really painful and AFAICT the documentation is lousy so working out what the hell to do is difficult and frustrating. But that's not really the largest part of the work either, which I won't try and go into now, because of the main difficulty described below. We now have quite a few users with linux laptops and they want to see the standard automounts on these. But being laptops they frequently switch subnet, jump on WiFi and VPN etc. Most subsystems seem to play pretty well with this dynamic network environment and are hooked into NM (with SSSD doing a good job with off net credentials and directory services caching) Now I know that autofs/nfs is a much harder nut to crack given its heavy in kernel component, but I'd have thought the present non-dynamic behaviour is a bit of an anomaly. The issue is NFS. Dynamic fail-over for mounts has been on the NFS list of things to do for over five years and is not done yet. I'm not even sure anything is being done or has been done toward it. And that's just for the simpler case of read-only mounts. I'm not sure that is what your after either but the difficulty would be considerably more for read-write mounts. For example, although nfs mounts are stateless (nfs4 is another matter entirely), they rely on a file handle that is constructed based on server dependent information so moving from one network to another and expecting mounts to just continue to work is not going to be simple, if it is even possible. For more information on NFS plans in this area, Colin, you could post your questions to linux-...@vger.kernel.org. The NFS version 4 protocol provides lots of opportunities for client-side fail-over support, even for read/write mounts. We're working on some of these pieces now, but it will be a while. The question of NFSv3 client-side fail-over support is more sticky, as Ian has pointed out. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled
On Jul 26, 2011, at 10:02 PM, Ian Kent wrote: On Wed, 2011-07-27 at 09:23 +0800, Ian Kent wrote: On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote: On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote: On 07/26/2011 10:50 AM, Chuck Lever wrote: On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote: From: Ian Kent ra...@themaw.net The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and clnttcp6_create and the server functions svcudp6_bufcreate(), svctcp6_create() and svcudp6_create() are not included in the library whe libtirpc is built. Are these part of the libtirpc standard API? I'm not sure why we would need them if, say, Solaris does not support these. It appears they are not since they are not mentioned the man pages. But, at least in the autofs code, they are expected https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0 Ian, where else are these routines defined? Now that I look I can't find the original source tar that was used for libtirpc, thought I had it. Found what I had. AFAICT what I think was the original source doesn't have any IPv6 code that I can see. Worse, these functions were excluded with the #ifdef INET6_NOT_USED macro as far back as libtirpc version 0.1.5 so, my bad, sorry. The story is that long ago when I changed autofs to use libtirpc (to make it ready for IPv6) I found these functions in the source and they were (obviously) the IPv6 counterparts for the corresponding IPv4 functions which I was already using, so I used them. It took me quite a while to realize my code wasn't working and then I found that somewhere along the line they have been excluded, oops! If there are to be no IPv6 counterparts for the corresponding IPv4 functions which functions should I use then? So what can I use? It seems to me that these functions would be useful for people porting code that uses the corresponding IPv4 functions so could we define them please. At some point someone must have had that same idea Found one more thing that looks relevant, these functions were defined in glibc in 2000-01-23 so they may be used by others as well. I checked in glibc 2.7 (though not thoroughly) and did not find them. steved Signed-off-by: Steve Dickson ste...@redhat.com --- src/rpc_soc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rpc_soc.c b/src/rpc_soc.c index c678429..584ac71 100644 --- a/src/rpc_soc.c +++ b/src/rpc_soc.c @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz) /* IPv6 version of clnt*_*create */ -#ifdef INET6_NOT_USED +#ifdef INET6 CLIENT * clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz) @@ -392,7 +392,7 @@ svcraw_create() /* IPV6 version */ -#ifdef INET6_NOT_USED +#ifdef INET6 SVCXPRT * svcudp6_bufcreate(fd, sendsz, recvsz) int fd; -- 1.7.6 -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Libtirpc-devel mailing list libtirpc-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libtirpc-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Libtirpc-devel mailing list libtirpc-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libtirpc-devel -- To unsubscribe from this list: send the line unsubscribe linux-nfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled
On Jul 26, 2011, at 10:40 PM, Ian Kent wrote: On Tue, 2011-07-26 at 22:09 -0400, Chuck Lever wrote: On Jul 26, 2011, at 9:23 PM, Ian Kent wrote: On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote: On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote: On 07/26/2011 10:50 AM, Chuck Lever wrote: On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote: From: Ian Kent ra...@themaw.net The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and clnttcp6_create and the server functions svcudp6_bufcreate(), svctcp6_create() and svcudp6_create() are not included in the library whe libtirpc is built. Are these part of the libtirpc standard API? I'm not sure why we would need them if, say, Solaris does not support these. It appears they are not since they are not mentioned the man pages. But, at least in the autofs code, they are expected https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0 Ian, where else are these routines defined? Now that I look I can't find the original source tar that was used for libtirpc, thought I had it. Found what I had. AFAICT what I think was the original source doesn't have any IPv6 code that I can see. Worse, these functions were excluded with the #ifdef INET6_NOT_USED macro as far back as libtirpc version 0.1.5 so, my bad, sorry. The story is that long ago when I changed autofs to use libtirpc (to make it ready for IPv6) I found these functions in the source and they were (obviously) the IPv6 counterparts for the corresponding IPv4 functions which I was already using, so I used them. It took me quite a while to realize my code wasn't working and then I found that somewhere along the line they have been excluded, oops! If there are to be no IPv6 counterparts for the corresponding IPv4 functions which functions should I use then? So what can I use? It seems to me that these functions would be useful for people porting code that uses the corresponding IPv4 functions so could we define them please. At some point someone must have had that same idea It looks to me like these functions were part of an original attempt at IPv6 support that was abandoned long ago. They are not part of TI-RPC, but as you observed, they are merely IPv6 versions of the legacy RPC API. I don't see these implemented in glibc, for example. For IPv6 support, use functions that are part of the modern libtirpc API. This is described in Sun doc 816-1435. You probably will be most successful with the simplified interface which is described in Chapter 4. You might need somewhat more extensive surgery since I'm guessing you have separate code paths to invoke the IPv4 and IPv6 legacy RPC functions; generally speaking that should not be needed when using the libtirpc API. I doubt the simplified interface will be adequate since this code was written because of a need for greater control over timeouts. Perhaps that won't be the case, I don't know yet. If you want control over connection timeouts, use the expert-level or bottom-level interfaces. Otherwise you can set per-RPC timeouts when clnt_call(3t) is invoked. nfs-utils has some example code (support/nfs/rpc_socket.c is one place to look). Your suggestion amounts to saying I need to re-write all my RPC code. The substantial change with client-side TI-RPC is how CLIENTs are created. The other RPC operations are similar or the same as they were with the legacy API. Once you get over getnetconfigent(3t) it's really not as bad as it looks. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled
On Jul 27, 2011, at 10:26 PM, Ian Kent wrote: On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote: For IPv6 support, use functions that are part of the modern libtirpc API. This is described in Sun doc 816-1435. You probably will be most successful with the simplified interface which is described in Chapter 4. You might need somewhat more extensive surgery since I'm guessing you have separate code paths to invoke the IPv4 and IPv6 legacy RPC functions; generally speaking that should not be needed when using the libtirpc API. I doubt the simplified interface will be adequate since this code was written because of a need for greater control over timeouts. Perhaps that won't be the case, I don't know yet. If you want control over connection timeouts, use the expert-level or bottom-level interfaces. Otherwise you can set per-RPC timeouts when clnt_call(3t) is invoked. nfs-utils has some example code (support/nfs/rpc_socket.c is one place to look). Your suggestion amounts to saying I need to re-write all my RPC code. The substantial change with client-side TI-RPC is how CLIENTs are created. The other RPC operations are similar or the same as they were with the legacy API. Once you get over getnetconfigent(3t) it's really not as bad as it looks. Umm ... Why is __rpcb_findaddr() declared in the public header files but not defined anywhere is the source? Why is __rpcb_findaddr_timed() defined in the source but not defined in the public header files? This version of libtirpc was split from the Sun version over a decade ago when the code was immature. So you're going to find this kind of thing in many places. The TI-RPC API is defined in 816-1435. You really shouldn't consider using any of the interfaces defined in the headers but not in that doc, as those are internal interfaces and can change. On the other hand, we have at least two important RPC-based applications that can make use of this interface. I wonder if it makes sense to harden that API but leave it hidden, so apps external to the library can depend on it. Such apps would not be portable away from Linux nor to Linux distributions that don't have libtirpc yet. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled
On Thu, Jul 28, 2011 at 10:33 AM, Ian Kent ik...@redhat.com wrote: On Thu, 2011-07-28 at 07:20 -0400, Chuck Lever wrote: On Jul 27, 2011, at 10:26 PM, Ian Kent wrote: Umm ... Why is __rpcb_findaddr() declared in the public header files but not defined anywhere is the source? Why is __rpcb_findaddr_timed() defined in the source but not defined in the public header files? This version of libtirpc was split from the Sun version over a decade ago when the code was immature. So you're going to find this kind of thing in many places. Yes, I was aware of that, but haven't paid enough attention to the doc. The TI-RPC API is defined in 816-1435. You really shouldn't consider using any of the interfaces defined in the headers but not in that doc, as those are internal interfaces and can change. Ummm .. rpcb_getaddr() might be what I'm looking for, I'll look further. On the other hand, we have at least two important RPC-based applications that can make use of this interface. I wonder if it makes sense to harden that API but leave it hidden, so apps external to the library can depend on it. Yeah, but if I can achieve what I need without it that's the way I'll go. It looks like I might not be able to do what I want the way I want with ti-rpc but it is still too early to tell. It's also too early to tell if ti-rpc actually already does some or all of what I need already. Time will tell. One example of something I need is to control the timeout, not the timeout for interactions after the client is constructed but the timeout of the client construction itself, including any queries to rpcbind that may be needed (hence why I want to do that manually too). Yes, nfs-utils does this too. See support/nfs/rpc_socket.c. It looks a lot like what is done in autofs's lib/rpc_subs.c. -- Blast this Christmas music! It's joyful _and_ triumphant! -- The Grinch ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
