rpc.mountd + rpc.nfsd

rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

Hi,
Why is there 2 daemons for NFS progs? Is it a necessity or just to
separate things?
Would it be possible to have only one nfsd daemon that is rpc.mounts +
rpc.nfsd + ... ?

Thanks.
-jec




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Neil Brown]

On Monday September 2, Jean-Eric.Cuendet@linkvest.com wrote:
> Hi,
> Why is there 2 daemons for NFS progs? Is it a necessity or just to
> separate things?
> Would it be possible to have only one nfsd daemon that is rpc.mounts +
> rpc.nfsd + ... ?

The serve different protocols (MOUNTD and NFS).  Also mountd runs
entirely in user space, nfsd runs entirely in kernel space.  It really
makes sense for them to be separate.

NeilBrown


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

> The serve different protocols (MOUNTD and NFS).  Also mountd runs
OK.

> entirely in user space, nfsd runs entirely in kernel space.  It really
> makes sense for them to be separate.

In fact, I thought of a completely userspace daemon. I took 
nfs-server-userspace-2.2b47 from the net and wondered why there was 2 
daemons while one is IMHO enough.
So, separating things between things that relates is sometimes good, but 
sometimes, it add complexity.
Any comment? Why 2 daemons in userspace. And the 2 run as root (I think...)

-jec



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Neil Brown]

On Tuesday September 3, Jean-Eric.Cuendet@linkvest.com wrote:
> 
> In fact, I thought of a completely userspace daemon. I took 
> nfs-server-userspace-2.2b47 from the net and wondered why there was 2 
> daemons while one is IMHO enough.
> So, separating things between things that relates is sometimes good, but 
> sometimes, it add complexity.
> Any comment? Why 2 daemons in userspace. And the 2 run as root (I think...)

Probably conceptually simpler.... but you are getting into ancient
history here.  The user-space NFS server has it's origins well over a
decade ago (about 15 years I think) and has passed through many hands
on the way.  Finding a definitive answer would be hard.

NeilBrown


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

I'm developing (beginning...) an SMB to NFS bridge.
That means an NFS server that gets its data, files, ACLs, etc... to SMB 
servers (Samba or Windows).
To begin, I'll take the sources of nfs-server userspace. But there is 2 
daemons while (I think) only one is necessary.
Would it be OK (In terms of kernel and RPC interactivity) to have only 
one daemon that do mountd+nfsd?

The goal of this project is to have a fully browseable /smb directory.
That will be:
/smb --|-- DOMAIN --|-- SERVER --|-- Share --|-- file
And all that authenticate in a per user way. That means that all 
connected users would be able to access /smb while seeing only what 
their credentials allow them. Even root in the machine won't be able to 
see every connected user data (root could always dump memory and find 
credentials..., but it's a lot harder to do than just su - user and go 
to the NFS mounted dir...)

What do you think of that?

-jec

PS: There is a similar commercial product called sharity 
(http://www.obdev.at/products/sharity/)

Neil Brown wrote:

>On Tuesday September 3, Jean-Eric.Cuendet@linkvest.com wrote:
>  
>
>>In fact, I thought of a completely userspace daemon. I took 
>>nfs-server-userspace-2.2b47 from the net and wondered why there was 2 
>>daemons while one is IMHO enough.
>>So, separating things between things that relates is sometimes good, but 
>>sometimes, it add complexity.
>>Any comment? Why 2 daemons in userspace. And the 2 run as root (I think...)
>>    
>>
>
>Probably conceptually simpler.... but you are getting into ancient
>history here.  The user-space NFS server has it's origins well over a
>decade ago (about 15 years I think) and has passed through many hands
>on the way.  Finding a definitive answer would be hard.
>
>NeilBrown
>  
>

-- 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
E-mail: jean-eric.cuendet@linkvest.com
http://www.linkvest.com
--------------------------------------------------------






-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Neil Brown]

On Tuesday September 3, jean-eric.cuendet@linkvest.com wrote:
> I'm developing (beginning...) an SMB to NFS bridge.
> That means an NFS server that gets its data, files, ACLs, etc... to SMB 
> servers (Samba or Windows).
> To begin, I'll take the sources of nfs-server userspace. But there is 2 
> daemons while (I think) only one is necessary.
> Would it be OK (In terms of kernel and RPC interactivity) to have only 
> one daemon that do mountd+nfsd?

I suspect you would be better off starting with am-utils than
nfs-server. (am-utils is a sophisticated auto-mount daemon).

If I understand you correctly, the nfs server will be on the same
machine as the nfs client that accesses that server. And then the
server reaches out over the network with SMB.
In that case you don't need mountd at all.  When the server starts, it
mounts itself and then starts responding to NFS requests.

It is much easier not to re-invent the wheel. For the actual file
access, don't do that via NFS, simply mount the SMB share using smbfs
somewhere and direct the client to that. Only use NFS for the browsing.

I suspect that you could possibly just use am-utils as it is and write
some back-end that provided a mount-map that am-utils used.  I suggest
you talk to Erez Zadok <ezk@cs.sunysb.edu>.  He could probably point
you in the right direction.

I'm not sure about the 'different-users-see-different-things' bit, but
there are elements of that in Erez' hlfsd (Home Link File System) so I
suspect he could help there too.


> 
> The goal of this project is to have a fully browseable /smb directory.
> That will be:
> /smb --|-- DOMAIN --|-- SERVER --|-- Share --|-- file
> And all that authenticate in a per user way. That means that all 
> connected users would be able to access /smb while seeing only what 
> their credentials allow them. Even root in the machine won't be able to 
> see every connected user data (root could always dump memory and find 
> credentials..., but it's a lot harder to do than just su - user and go 
> to the NFS mounted dir...)
> 
> What do you think of that?
> 
> -jec
> 
> PS: There is a similar commercial product called sharity 
> (http://www.obdev.at/products/sharity/)


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

>
>
>I suspect you would be better off starting with am-utils than
>nfs-server. (am-utils is a sophisticated auto-mount daemon).
>
Everyone that I ask about that tell me the same: use amd...
But (except if I miss something), it's absolutely NOT suitable for that!

Explainations:
amd mounts a smb share in the filesystem (say, mounting //server/share 
=> /smb). To mount, you must provide a user/pwd. Then there is some 
mount time fixed uid/gid used to "own" the files on the machine.
If the authentication is done by user1 and then user2 is accessing 
files, the permissions will be checked on user1 on the SMB server, and 
with uid/gid on the client. If user2 has access to files that user1 
haven't, user2 will be denied access...
If user2 have access that user1 don't , access will be granted anyway 
(if uid/gid on the client is OK).

The goal is to check the perms on a per access basis. When user1 access 
files, we use its auth token to check if access is granted. Client 
doesn't anything, only the SMB server makes checks.
Then, if user2 access other files, we use its auth token, which let him 
access different files.
It's the same as network neighborood in Windows. Only files that the 
USER (not the machine) have access are acessible.

Am I missing something with amd?

>If I understand you correctly, the nfs server will be on the same
>machine as the nfs client that accesses that server. And then the
>server reaches out over the network with SMB.
>
Yes, that's it! The nfs-server is only a bridge. Access is only provided 
for 127.0.0.1

>In that case you don't need mountd at all.  When the server starts, it
>mounts itself and then starts responding to NFS requests.
>
Cooool. It's simpler! So, server mounting itself doesn't need mountd. 
How do I do that?
- Implementing NFSD RPC calls.
- Starting NFSD
- Mounting the server (mount -t nfs localhost:/ /smb)
Why isn't mountd  needed? What does it provide that is not needed?

>It is much easier not to re-invent the wheel. For the actual file
>access, don't do that via NFS, simply mount the SMB share using smbfs
>somewhere and direct the client to that. Only use NFS for the browsing.
>
The same problem as explained before...

>I'm not sure about the 'different-users-see-different-things' bit, but
>
That's just the point that don't work and that's very important in this 
thing.

>there are elements of that in Erez' hlfsd (Home Link File System) so I
>suspect he could help there too.
>
I'll have a look at that. But I suspect that it won't change things.

Thanks anyway for everything.
-jec

PS: Are you a RedHat employee or not?




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[David Dougall]

Have you looked at sharity?  I have not used it much, but from what I
understand, it does exactly what you are asking.
--David Dougall


On Tue, 3 Sep 2002, Jean-Eric Cuendet wrote:

> >
> >
> >I suspect you would be better off starting with am-utils than
> >nfs-server. (am-utils is a sophisticated auto-mount daemon).
> >
> Everyone that I ask about that tell me the same: use amd...
> But (except if I miss something), it's absolutely NOT suitable for that!
>
> Explainations:
> amd mounts a smb share in the filesystem (say, mounting //server/share
> => /smb). To mount, you must provide a user/pwd. Then there is some
> mount time fixed uid/gid used to "own" the files on the machine.
> If the authentication is done by user1 and then user2 is accessing
> files, the permissions will be checked on user1 on the SMB server, and
> with uid/gid on the client. If user2 has access to files that user1
> haven't, user2 will be denied access...
> If user2 have access that user1 don't , access will be granted anyway
> (if uid/gid on the client is OK).
>
> The goal is to check the perms on a per access basis. When user1 access
> files, we use its auth token to check if access is granted. Client
> doesn't anything, only the SMB server makes checks.
> Then, if user2 access other files, we use its auth token, which let him
> access different files.
> It's the same as network neighborood in Windows. Only files that the
> USER (not the machine) have access are acessible.
>
> Am I missing something with amd?
>
> >If I understand you correctly, the nfs server will be on the same
> >machine as the nfs client that accesses that server. And then the
> >server reaches out over the network with SMB.
> >
> Yes, that's it! The nfs-server is only a bridge. Access is only provided
> for 127.0.0.1
>
> >In that case you don't need mountd at all.  When the server starts, it
> >mounts itself and then starts responding to NFS requests.
> >
> Cooool. It's simpler! So, server mounting itself doesn't need mountd.
> How do I do that?
> - Implementing NFSD RPC calls.
> - Starting NFSD
> - Mounting the server (mount -t nfs localhost:/ /smb)
> Why isn't mountd  needed? What does it provide that is not needed?
>
> >It is much easier not to re-invent the wheel. For the actual file
> >access, don't do that via NFS, simply mount the SMB share using smbfs
> >somewhere and direct the client to that. Only use NFS for the browsing.
> >
> The same problem as explained before...
>
> >I'm not sure about the 'different-users-see-different-things' bit, but
> >
> That's just the point that don't work and that's very important in this
> thing.
>
> >there are elements of that in Erez' hlfsd (Home Link File System) so I
> >suspect he could help there too.
> >
> I'll have a look at that. But I suspect that it won't change things.
>
> Thanks anyway for everything.
> -jec
>
> PS: Are you a RedHat employee or not?
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
>


______________________________________
Inflex Virus Scanner - installed on mailserver for domain @et.byu.edu
Queries to: postmaster@et.byu.edu


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

>
>
>Have you looked at sharity?  I have not used it much, but from what I
>understand, it does exactly what you are asking.
>--David Dougall
>
Yes, but it's not free...
Except that, it's exactly what I'd like to do.
-jec




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Neil Brown]

On Tuesday September 3, Jean-Eric.Cuendet@linkvest.com wrote:
> >
> >
> >I suspect you would be better off starting with am-utils than
> >nfs-server. (am-utils is a sophisticated auto-mount daemon).
> >
> Everyone that I ask about that tell me the same: use amd...
> But (except if I miss something), it's absolutely NOT suitable for that!
> 
> Explainations:
> amd mounts a smb share in the filesystem (say, mounting //server/share 
> => /smb). To mount, you must provide a user/pwd. Then there is some 
> mount time fixed uid/gid used to "own" the files on the machine.
> If the authentication is done by user1 and then user2 is accessing 
> files, the permissions will be checked on user1 on the SMB server, and 
> with uid/gid on the client. If user2 has access to files that user1 
> haven't, user2 will be denied access...
> If user2 have access that user1 don't , access will be granted anyway 
> (if uid/gid on the client is OK).
> 
> The goal is to check the perms on a per access basis. When user1 access 
> files, we use its auth token to check if access is granted. Client 
> doesn't anything, only the SMB server makes checks.
> Then, if user2 access other files, we use its auth token, which let him 
> access different files.
> It's the same as network neighborood in Windows. Only files that the 
> USER (not the machine) have access are acessible.
> 
> Am I missing something with amd?

What you could do is arrange that amd mounts a completely separate
filesystem tree for each user, using something similar to hlfsd to
automatically direct each user to a different tree.  Then each tree
has smb shares mounted with the user's username and password, and only
accessable to that user.

Alternately, you could modify smbfs to open multiple connections to
the server, one for each user, and direct different user's requests
down different connections.

Alternately you could do the whole thing in an NFS server.

I suspect the last would be the hardest, but maybe that's just me.

Have fun.

NeilBrown

> 
> PS: Are you a RedHat employee or not?
> 

not.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

>
>
>If I understand you correctly, the nfs server will be on the same
>machine as the nfs client that accesses that server. And then the
>server reaches out over the network with SMB.
>In that case you don't need mountd at all.  When the server starts, it
>mounts itself and then starts responding to NFS requests.
>
I REALLY need to know how to mount myself in a directory.
I have nfs3_prot.x implemented but not mountd at all.
How to do that? When in my program? What to call?

Thanks a lot.
-jec



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

Isn't there someone to answer this guy question?... :-)

>> If I understand you correctly, the nfs server will be on the same
>> machine as the nfs client that accesses that server. And then the
>> <..>
>> mounts itself and then starts responding to NFS requests.
>
> I REALLY need to know how to mount myself in a directory.
> I have nfs3_prot.x implemented but not mountd at all.
> How to do that? When in my program? What to call?


;-)
-jec





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Paul Cunningham]

>> If I understand you correctly, the nfs server will be on the same
>> machine as the nfs client that accesses that server. And then the
>> <..>
>> mounts itself and then starts responding to NFS requests.
>
> I REALLY need to know how to mount myself in a directory.
> I have nfs3_prot.x implemented but not mountd at all.
> How to do that? When in my program? What to call?

Short answer:  
You do not mount yourself in a directory.  mountd is used to retrieve 
the opaque file handle of the directory you wish to mount on the client.  
Once you have the initial opaque filehandle, you may then call an nfs 
procedure (ie. LOOKUP, READ, WRITE, READDIR, etc) with the
filehandle as one of the arguments.

Better answer:
As suggested by a previous reply, get yourself a copy of "NFS Illustrated"
by Brent Callaghan.





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Neil Brown]

On Thursday September 5, jean-eric.cuendet@linkvest.com wrote:
> Isn't there someone to answer this guy question?... :-)
> 
> >> If I understand you correctly, the nfs server will be on the same
> >> machine as the nfs client that accesses that server. And then the
> >> <..>
> >> mounts itself and then starts responding to NFS requests.
> >
> > I REALLY need to know how to mount myself in a directory.
> > I have nfs3_prot.x implemented but not mountd at all.
> > How to do that? When in my program? What to call?
> 
 
   man 2 mount

This explains everything  except for the 'void * data' which is nfs
specific.

   cat /usr/include/linux/nfs_mount.h

If some of the fields aren't obvious, get the source for the mount
program and read it, or look at the nfs filesystem code in the kernel
to see what it does with those fields.

NeilBrown


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Trond Myklebust]

>>>>> " " == Neil Brown <neilb@cse.unsw.edu.au> writes:

     > This explains everything except for the 'void * data' which is
     > nfs specific.

     >    cat /usr/include/linux/nfs_mount.h

     > If some of the fields aren't obvious, get the source for the
     > mount program and read it, or look at the nfs filesystem code
     > in the kernel to see what it does with those fields.

In particular it is worth looking at the NFSroot code
(fs/nfs/nfsroot.c). The latter contains basic code for filling in a
struct nfs_mount.

Cheers,
  Trond


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Trond Myklebust]

>>>>> " " == Jean-Eric Cuendet <Jean-Eric.Cuendet@linkvest.com> writes:

    >> The serve different protocols (MOUNTD and NFS).  Also mountd
    >> runs
     > OK.

    >> entirely in user space, nfsd runs entirely in kernel space.  It
    >> really makes sense for them to be separate.

     > In fact, I thought of a completely userspace daemon. I took
     > nfs-server-userspace-2.2b47 from the net and wondered why there
     > was 2 daemons while one is IMHO enough.

IIRC, this was done in order to allow people to do wierd and wonderful
things. For instance, you could supposedly run the mountd daemon on
one machine, and nfsd on another. We actually have support for this in
the client by way of the option "mounthost=" in the standard mount
program.

I've never heard of anybody actually using that particular feature
though.

Cheers,
  Trond


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[jbe]

On Tue, Sep 03, 2002 at 07:01:52PM +0200, Trond Myklebust wrote:
> >>>>> " " == Jean-Eric Cuendet <Jean-Eric.Cuendet@linkvest.com> writes:
> 
>     >> The serve different protocols (MOUNTD and NFS).  Also mountd
>     >> runs
>      > OK.
> 
>     >> entirely in user space, nfsd runs entirely in kernel space.  It
>     >> really makes sense for them to be separate.
> 
>      > In fact, I thought of a completely userspace daemon. I took
>      > nfs-server-userspace-2.2b47 from the net and wondered why there
>      > was 2 daemons while one is IMHO enough.
> 
> IIRC, this was done in order to allow people to do wierd and wonderful
> things. For instance, you could supposedly run the mountd daemon on
> one machine, and nfsd on another. We actually have support for this in
> the client by way of the option "mounthost=" in the standard mount
> program.
> 

What would be the benefit of running nfsd and mountd on different hosts ?

Jens

-- 
Jens Beyer
System Administrator                                   mailto:jbe@web.de
WEB.DE AG                                             http://webde-ag.de


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.mountd + rpc.nfsd

[Kedar Sovani]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Hi,
    i think, the nfsd is a kernel mode daemon, while the mountd is a userspace daemon.
    The mountd does the initial processing of the mount request, gets the file handle from the server and then sends it into the kernel by the nfsservctl interface.
     As to, why the mountd is not in kernel space, IMHO, it might not have beeen qualified to be there in the kernel. 
 

rgds,
Kedar.

[-- Attachment #2: Type: text/html, Size: 1077 bytes --]

rpc.mountd + rpc.nfsd

[Jean-Eric Cuendet]

Hi,
Why is there 2 daemons for NFS progs? Is it a necessity or just to 
separate things?
Would it be possible to have only one nfsd daemon that is rpc.mounts + 
rpc.nfsd + ... ?

Thanks.
-jec



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs