From: James Pearson <james-p@moving-picture.com>
Subject: Re: file :"/var/lib/nfs/rmtab"
Date: Thu, 03 Feb 2005 11:29:25 +0000
Message-ID: <42020B15.4030602@moving-picture.com>
References: <20050203060844.3898.qmail@web51603.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Cc: nfs@lists.sourceforge.net
To: mehta kiran <kiranmehta1981@yahoo.com>
In-Reply-To: <20050203060844.3898.qmail@web51603.mail.yahoo.com>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

mehta kiran wrote:
> Hi , 
>        In mountd man page , it written that
>        rmtab is ornamental and client can contiune
>        to use filesystem even after calling umount
>        for that filesystem.
> 
>        Is there any real use of this rmtab file ?
>        Does mountd use this file to know the
>        clients having access to filesystem ?
>        If yes , isn,t filehandle supplied by 
>        client enough to prove that client has access
>        to filesystem. ?

On 2.4 kernels it is not 'ornamental' - if the server reboots without an 
entry for a client mount in /var/lib/nfs/rmtab, then the client will get 
a stale NFS file handle when the server reboots. This can happen if 
umount fails e.g. the mount point is busy - rpc.mountd on the server 
removes the entry from /var/lib/nfs/rmtab, but umount fails, so the file 
system remains mounted.

I believe the situation has changed with 2.6.

James Pearson


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs