[Linux-cluster] Asking information about NFS /CS4 Cookbook

[Wendy Cheng]

Wendy Cheng wrote:

> Fajar A. Nugraha wrote:
>
>> Lon Hohberger wrote:
>>  
>>
>>> On Wed, May 16, 2007 at 11:04:41AM +0200, Alain Moulle wrote:
>>>  
>>>   
>>>
>>>> how could it
>>>> be "without detecting  when a failure occurs" ?
>>>> Sure I miss something somewhere ?
>>>>        
>>>
>>> A 'managed NFS service' needs to include a 'managed virtual IP'.
>>> Clients always access using the same IP.
>>>
>>>  
>>>   
>>
>> Hi Lon,
>> How do nfs clients behave during this failover/server change?
>> To be more specific, :
>> - does the choice UDP vs TCP and nfs v3 vs v4 make a difference in how
>> much time it takes for clients to be serviced by the new server?
>

More specifically, TCP has ~30 minutes TIME_WAIT issue (see the bugzilla 
comment mentioned in previous post).

>> - can the client handle the change gracefully so that
>> there will be no "stale nfs handle"?
>

This is a tough problem to solve. Hopefully the bugzilla entry explains 
well.

>>
>> On the server side :
>> - When the exported filesystem is non-cluster (e.g. ext3), how does the
>> server handle locking issues? If an nfs-client is locking a file, can
>> the server (in Managed NFS service) forcefully unmount the file system,
>> considering that the nfs daemon is kernel-space, so that it can't be 
>> killed?
>

We have a tentative patch set for this. It is usable but still under 
revised.

>> - Can the client gracefully handle new, failover,  nfs clients, since
>> some nfs information is stored on /var/lib/nfs, which is on a local file
>> system?
>>
>>  
>

This would need to be moved into the shared storage area (and done by 
RHCS).

-- Wendy

>
> These issues are documented in Red Hat bugzilla 132823 Comment #47
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132823).
>
> A draft write-up is placed in:
> http://people.redhat.com/wcheng/Project/nfs (see section 4.3 and 4.4).
>
> -- Wendy
>