Changing Startup Scripts

Re: questions about rpc and locks

>>>>> " " == Patrice DUMAS <dumas <at> centre-cired.fr> writes:

     > Hi, I have 2 questions about the kernel rpc implementation.

     > 1. What are the return codes (from rpc_call) and their meanings
     >    (or where could I find that, I found that looking at the
     >    code itself was really hard).

For an ordinary synchronous call, rpc_call() returns the value of
task->tk_status upon exit.

If the call could not be made, then that value will reflect an error
code, usually EINTR (although for 'soft' RPC calls, the error EIO will
be returned if a major timeout occurred).

If the call was made, then the value is set by the XDR decode entry
(see the macro rpcproc_decode(clnt, task->tk_msg.rpc_proc)) if it
exists in the 'struct rpc_procinfo' table.

If the server is not expected to return a value, then the
corresponding XDR decode entry should be NULL, and task->tk_status
should normally be zero upon rpc_call exit.

     > 2. Is it possible to know at what point the rpc call failed ? 
     >    (from within the rpc_task struct, to determine whether the
     >    caller couldn't send or it didn't get a response).

Only makes sense for 'soft' RPC calls, and in that case you get an EIO.

     > 3. When the client think it has a lock on a nfs file, but the
     >    server thinks the client hasn't, what happens ?

File corruption is possible, and the server will return
'NLM_LCK_DENIED_NOLOCKS' when the client tries to unlock.

Cheers,
  Trond

Re: Changing Startup Scripts

On Wednesday 01 May 2002 07:29, Tina Arora wrote:
> hello ,
> Now My NFS is working sound and I am also able to mount directories on the
> client perfectly but I am facing 1 other problem n here it follows. I have
> to explicitly start nfsd using command rpc.nfsd 8 , also disable the
> firewall using the command service ipchains stop ...bcoz of  these two
> problems my automount is also not working .. How to change the startup
> scripts so that all these daemons start at boot time .. thanx n reply soon
> tina

I think you will find the answer to that problem, and many more that you may 
encounter in the future, in a good book on Linux system administration.

Alex

Re: questions about rpc and locks

Hi,

Thanks for your reply.

> If the call could not be made, then that value will reflect an error
> code, usually EINTR (although for 'soft' RPC calls, the error EIO will
> be returned if a major timeout occurred).
....
> Only makes sense for 'soft' RPC calls, and in that case you get an EIO.

In case of an asynchronous call, is there such a difference between 'soft' and
'hard' rpc calls too ?

I haven't seen anywhere what was the kind of rpc call of the server side lockd.
Is it hard by default ?

Pat

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RPC: TCP connect error 104!

I am experiencing a problem on a number of different clients mounting NFS mounts over TCP. The error message
showing up is

RPC: TCP connect error 104!

I searched through Google Groups and found following message

=========================================

http://www.geocrawler.com/mail/msg.php3?msg_id=8215374&list=789

You may need more threads to service the clients?  See Neil's notes
that accompanied the patches (in the archives) w.r.t the number of threads and the number of RPC receive buffers.

==========================================

I was wondering what is the easiest way to increase the number of threads. Most clients run RedHat's
2.4.9-31 kernel installed from an RPM. I also have a Rawhide kernel 2.4.18-0.12 that seems to exhibit same
kind of behavior.

Thanks,
Vladimir

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Promote your group and strengthen ties to your members with email <at> yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPC: TCP connect error 104!

On Thursday May 2, croatia <at> firstlinux.net wrote:
> I am experiencing a problem on a number of different clients mounting NFS mounts over TCP. The error
message showing up is
> 
> RPC: TCP connect error 104!
> 
> I searched through Google Groups and found following message
> 
> =========================================
> 
> http://www.geocrawler.com/mail/msg.php3?msg_id=8215374&list=789
> 
> You may need more threads to service the clients?  See Neil's notes
> that accompanied the patches (in the archives) w.r.t the number of threads and the number of RPC receive buffers.
> 
> ==========================================
> 
> I was wondering what is the easiest way to increase the number of
> threads. Most clients run RedHat's 2.4.9-31 kernel installed from an
> RPM. I also have a Rawhide kernel 2.4.18-0.12 that seems to exhibit
> same kind of behavior. 
>   

Just run rpc.nfsd and give it the number that you want.

  rpc.nfsd 32

will increase the number of threads to 32

  rpc.nfsd 128

will then increase it to 128.

If you find that has fixed the problem, the find the init.d script
that starts rpc.nfsd and change the number to whatever you want.

NeilBrown

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: questions about rpc and locks

>>>>> " " == Patrice DUMAS <dumas <at> centre-cired.fr> writes:

     > In case of an asynchronous call, is there such a difference
     > between 'soft' and 'hard' rpc calls too ?

Yes. 'hard' RPC calls will retry forever, and soft calls, will set
task->tk_status to EIO on a major timeout. This goes for both
synchronous and asynchronous calls.

     > I haven't seen anywhere what was the kind of rpc call of the
     > server side lockd.  Is it hard by default ?

You need to set the flag clnt->cl_soft in order to enable 'soft' RPC
calls. As you can see from the code, rpc.statd does this. The NLM
client code does so if and only if the NFS mount was soft. The lockd
server does not...

Note: for those RPC calls that don't expect the server to acknowledge
the call and return a value (e.g. NLM_*_MSG, NLM_*_RES) the 'hard'
call unfortunately does not offer any extra guarantees that the server
will *receive* the message. All it guarantees is that the message will
eventually get put on the wire...

Cheers,
  Trond

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

completely unimportant bug in fs/nfs/inode.c

Hi Trond et al,

Here is a completely unimportant bug in the latest (2.5.12)
fs/nfs/inode.c.  In nfs_get_sb(), a couple of error paths have
memory leaks.  I believe the block
   if (root->size > sizeof(root->data)) {
      printk("nfs_get_sb: invalid root filehandle\n");
      return ERR_PTR(-EINVAL);
   }
should also contain
      kfree(server);
The same comment also applies to the check on the return value
of nfs_fill_super() near the bottom of the routine.

Cheers,
 Kendrick

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: completely unimportant bug in fs/nfs/inode.c

>>>>> " " == Kendrick M Smith <kmsmith <at> umich.edu> writes:

     > Hi Trond et al,

     > Here is a completely unimportant bug in the latest (2.5.12)
     > fs/nfs/inode.c.  In nfs_get_sb(), a couple of error paths have
     > memory leaks.  I believe the block
     >    if (root->size > sizeof(root->data)) {
     >       printk("nfs_get_sb: invalid root filehandle\n"); return
     >       ERR_PTR(-EINVAL);
     >    }
     > should also contain
     >       kfree(server);
     > The same comment also applies to the check on the return value
     > of nfs_fill_super() near the bottom of the routine.

Thanks Kendrick. I appear to have missed those when I OKed Al's
patch. I'll try to get round to fixing it up soon...

Cheers,
  Trond

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Linux NFS Implementation

Hello All

Are all NFSv3 Fuctions Implemented in Linux (like readdirplus) ?

What C Funtions should be best used to open / read a file on a NFS
Server ? Or doesn't it make a difference ?

--

Kind regards

NetZone AG
Gavin Woodhatch

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
_______________________________________________
NFS maillist  -  NFS <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs