search

phdeniel / nfs-ganesha

NFS-Ganesha, a NFSv3/NFSv4.x/9P file server in User Space
http://nfs-ganesha.sf.net
60 stars 48 forks source link

MOUNTPROC3::DUMP does not work #23

Closed phdeniel closed 12 years ago

phdeniel commented 12 years ago

Apparently, MOUNTPROC3::DUMP is not working properly. This function of the mount protocol is rarely used. It makes it possible for a client to ask the server about the clients that mounted it. It is typically called as you run "showmount ".

For the moment, no entries are returned (this is confirmed by a wireshark capture)

ffilz commented 12 years ago

Philippe DENIEL <reply +i-2267054-d2245e1e489e6ae43b628e1a17935c210dd04b00-399443@reply.github.com> wrote on 11/17/2011 02:03:26 AM:

Apparently, MOUNTPROC3::DUMP is not working properly. This function of the mount protocol is rarely used. It makes it possible for a client to ask the server about the clients that mounted it. It is typically called as you run "showmount ".

For the moment, no entries are returned (this is confirmed by a wireshark capture)

Yes, I've had a look at that before. The mount code surrounding tracking clients that is present, but ifdefed out, seems very wrong.

Ultimately, my thought is to continue not supporting this. The notion of which clients are mounted has never been very reliable. Some clients never unmount (many years ago I was doing some NFS work involving diskless workstations, they would never bother to unmount...). Server and client recovery will result in the count and list not being accurate.

There may also be security concerns with any client being able to get a list of mounted clients.

So my thought in the end is, don't bother implementing these functions. What might be more useful to admins is a way to get various information such as a list of actively connected clients (obviously TCP only, but realistically, that's all we should care about - no one should really be using UDP clients...).

Frank

phdeniel commented 12 years ago

There is a fact: mountlist returned by MOUNTPROC3::DUMP is not reliable. If a client register to a server that crashes later, the client will be able to access the server (and will do it) without been in the mntlist (because it made no MOUNTPROC3::MNT to that server). Similarily, if a client died, it makes no MOUNTPROC3:UMNT to the server and stay inside the list. With large supercomputers, the client list may be quite long (thousands of records) and fully useless.

So, regarding this issue, it seems like it is urgent to do nothing: an empty list is not that bad. At least, sysadms won't be confused by an altered list. I close this issue, showmount -a will return an empty list.

PS: note that MOUNTPROC3::EXPORT (that returns the exported entries) works pretty well. It's correlated to showmount -e which is a command widely used by sysadms