From: Reuti <reuti@staff.uni-marburg.de>
Subject: Re: [CIRCUMVENTED] NFS client got stale NFS handle after server
 reboot
Date: Thu, 22 Sep 2005 16:52:31 +0200
Message-ID: <4332C52F.5000908@staff.uni-marburg.de>
References: <433027F7.1030702@staff.uni-marburg.de> <43318F26.2030001@staff.uni-marburg.de> <4332784C.8040503@staff.uni-marburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
To: nfs@lists.sourceforge.net
In-Reply-To: <4332784C.8040503@staff.uni-marburg.de>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

Finally I could track down the odd behavior (this time in top posting):

If you have this combination:

+ Linux kernel 2.6 nfsd on server
+ 64 bit i386, i.e. x86_64 server
+ using netgroups in /etc/exports
+ operate mountd/exportfs in new mode

you will face the problem of stale NFS handle after a stop/start of of 
the NFS service. As we want to use 64 bit of course, and enjoy netgroups 
for easier administration, I got a working setup by *not* mounting 
/proc/fs/nfsd and forcing this way mountd/exportfs into legacy mode also 
on a 2.6 kernel.

Cheers - Reuti


Reuti wrote:
> Okay, here the result:
> 
> Reuti wrote:
> 
>> Hi again,
>>
>> Reuti wrote:
>>
>>> Hi all,
>>>
>>> I set up a NFS server using kernel NFS in kernel 2.6.11.4-21.9 from
>>> SuSE. I defined three directories to be exported using netgroups and all
>>> is working fine, as they can be mounted as intended by all the nodes in
>>> the cluster.
>>>
>>> Up to now I was used to have the NFS feature, that a "hard" mount on the
>>> nodes will survive a reboot of the NFS server. This is now no longer the
>>> case. If I reboot the server, all the nodes get a stale NFS handle. I
>>> can achieve the same effect by simple stopping and starting the nfsd -
>>> same result.
>>>
>>> As we use a RAID card for the disks in the server, I got the idea of
>>> changed major-minor numbers and also tried to give in the "exports"
>>> file a chosen "fsid=" for each of the three exports. (Although
>>> starting/stopping the nfsd won't change the major-minor numbers I
>>> think.) No change.
>>>
>>> Now the funny part: login to a node. Choose any of the three imported
>>> directories. Make an "umount" and "mount" on this dir - and also the
>>> other two dirs reappear and are accessible again.
>>>
>>> Does anyone has an explanation and/or solution for this setup, to get
>>> the surviving feature back?
>>>
>>> CU - Reuti
>>>
>>> (BTW: all partitions are ext2 on Linux x86 machines, mounted with NFSv3)
>>
>>
>>
>> as a followup to my own posting:
>>
>> I did some more testing: downloaded the latest stable kernel 
>> (2.6.13.2) and compiled for server and client, no success.
>>
>> Then I installed a conventional IDE harddisk - same result. So it's 
>> not AACRAID to blame for.
>>
>> Then I tried with another server, but a 32 bit machine. And with this 
>> it was working.
>>
>> So my conclusion:
>>
>> Server 64 bit and client 32 bit will not survive a stop/start of the 
>> NFS server. But if you unmount/mount one of the imported dirs, all 
>> will reappear as already stated.
>>
>> Is this a known issue, and/or any solution to this?
>>
>> Tomorrow I'll try to get another 64 bit machine as client, to check 
>> whether this would behave the same with the 64 bit server.
> 
> 
> 64 bit server and 64 bit client has the same issue of a stale NFS handle 
> after stop/start of the nfs daemon. To me it looks like a bug, as it was 
> working within a pure 32 bit setup. Where exactly shall I report this as 
> a bug? - Reuti
> 


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs