Hi ,=20
I have observed the following.
RHEL4 GA and U1=20
client accesses filesystem exported
by server using nfsv4 .
It takes lock on a file.
Other clients on "different" systems
get NFSERR_DENIED and they retry to acquire
lock.
When first client release lock , other client
gets the lock.
But when i see in /var/lib/nfs/statd/sm=20
directory , i cannot see any file with
name =3D server's name.
=20
Has anybody observed this.
thanks,
kiran
=20
=20
=09
__________________________________=20
Yahoo! Mail=20
Stay connected, organized, and protected. Take the tour:=20
http://tour.mail.yahoo.com/mailtour.html=20
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by H=
P,=20
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
to den 14.07.2005 Klokka 05:55 (-0700) skreiv mehta kiran:
> Hi ,
> I have observed the following.
> RHEL4 GA and U1
> client accesses filesystem exported
> by server using nfsv4 .
>
> It takes lock on a file.
> Other clients on "different" systems
> get NFSERR_DENIED and they retry to acquire
> lock.
>
> When first client release lock , other client
> gets the lock.
> But when i see in /var/lib/nfs/statd/sm
> directory , i cannot see any file with
> name = server's name.
An NFSv4 client has no use for statd. The NFSv4 protocol has its own
methods for tracking client and server reboots.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi Trond ,=20
Lock recovery worked with nfsv3 even if
nfs server fail over to some other system
This was possible because sm directory was shared
across systems.
Will this work with nfsv4 though there are
no files in sm directory.=20
thanks,
kiran
--- Trond Myklebust <[email protected]>
wrote:
> to den 14.07.2005 Klokka 05:55 (-0700) skreiv mehta
> kiran:
> > Hi ,=20
> > I have observed the following.
> > RHEL4 GA and U1=20
> > client accesses filesystem exported
> > by server using nfsv4 .
> >=20
> > It takes lock on a file.
> > Other clients on "different" systems
> > get NFSERR_DENIED and they retry to
> acquire
> > lock.
> >=20
> > When first client release lock , other
> client
> > gets the lock.
> > But when i see in /var/lib/nfs/statd/sm=20
> > directory , i cannot see any file with
> > name =3D server's name.
>=20
> An NFSv4 client has no use for statd. The NFSv4
> protocol has its own
> methods for tracking client and server reboots.
>=20
> Cheers,
> Trond
>=20
>=20
>=20
>
-------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With
> Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to
> explore the latest in dual
> core and dual graphics technology at this free one
> hour event hosted by HP,=20
> AMD, and NVIDIA. To register visit
> http://www.hp.com/go/dualwebinar
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by H=
P,=20
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
mehta kiran wrote:
>Hi Trond ,
> Lock recovery worked with nfsv3 even if
> nfs server fail over to some other system
> This was possible because sm directory was shared
> across systems.
> Will this work with nfsv4 though there are
> no files in sm directory.
>
Yes, this should work. NFSv4 will discover that the server has
"rebooted" using
its mechanism and recover its locks. The NFSv2 and NVFSv3 clients will
discover
that the server has "rebooted" using the statd support and recover locks
as well.
NFSv4 uses a different mechanism than NFSv2 and NFSv3, but if the failover
support was architected correctly, then things should continue to work. You
may need to look at failover times perhaps.
ps
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
to den 14.07.2005 Klokka 06:30 (-0700) skreiv mehta kiran:
> Hi Trond ,
> Lock recovery worked with nfsv3 even if
> nfs server fail over to some other system
> This was possible because sm directory was shared
> across systems.
> Will this work with nfsv4 though there are
> no files in sm directory.
Servers that don't store anything to disk will usually support reboot
recovery, but will offer a more limited recovery model (i.e. one client
may find that another has stolen its locks due to races).
An server that supports the full NFSv4 state recovery model will usually
store some client information on permanent disk (recent Linux servers
store a list of all the "clientid"s in /var/lib/nfs/v4recovery).
Strictly speaking, though, this is really only necessary in order to
resolve some very obscure state recovery corner cases. For instance in
one case, a double reboot of the server combined with a network
partition may lead to 2 clients believing they have locked the same file
unless the server has stored information about which client lost its
state during the period between the 2 reboots (see the discussion in
RFC3530).
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2005-07-14 at 09:21 -0400, Trond Myklebust wrote:
> to den 14.07.2005 Klokka 05:55 (-0700) skreiv mehta kiran:
> > Hi ,
> > I have observed the following.
> > RHEL4 GA and U1
> > client accesses filesystem exported
> > by server using nfsv4 .
> >
> > It takes lock on a file.
> > Other clients on "different" systems
> > get NFSERR_DENIED and they retry to acquire
> > lock.
> >
> > When first client release lock , other client
> > gets the lock.
> > But when i see in /var/lib/nfs/statd/sm
> > directory , i cannot see any file with
> > name = server's name.
>
> An NFSv4 client has no use for statd. The NFSv4 protocol has its own
> methods for tracking client and server reboots.
lockd too, I hope?
Thanks!
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Dan Stromberg wrote:
>On Thu, 2005-07-14 at 09:21 -0400, Trond Myklebust wrote:
>
>
>>to den 14.07.2005 Klokka 05:55 (-0700) skreiv mehta kiran:
>>
>>
>>>Hi ,
>>> I have observed the following.
>>> RHEL4 GA and U1
>>> client accesses filesystem exported
>>> by server using nfsv4 .
>>>
>>> It takes lock on a file.
>>> Other clients on "different" systems
>>> get NFSERR_DENIED and they retry to acquire
>>> lock.
>>>
>>> When first client release lock , other client
>>> gets the lock.
>>> But when i see in /var/lib/nfs/statd/sm
>>> directory , i cannot see any file with
>>> name = server's name.
>>>
>>>
>>An NFSv4 client has no use for statd. The NFSv4 protocol has its own
>>methods for tracking client and server reboots.
>>
>>
>
>lockd too, I hope?
>
Right!
ps
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
to den 14.07.2005 Klokka 12:17 (-0700) skreiv Dan Stromberg:
> > An NFSv4 client has no use for statd. The NFSv4 protocol has its own
> > methods for tracking client and server reboots.
>
> lockd too, I hope?
Yes. Lockd is gone too.
The only daemons you need to run on a client in order to get NFSv4
working are
- idmapd (for translating names/groups <-> uid/gid)
- rpc.gssd (only if you are using RPCSEC_GSS)
On the server you have to be running
- idmapd (for translating names/groups <-> uid/gid)
- portmap (this requirement will hopefully go away soon)
- rpc.svcgssd (only if you are exporting RPCSEC_GSS)
- rpc.mountd (not used by clients, only by nfsd itself - feel free to
firewall away the ports it sets up)
.... and the nfsd processes.
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
to den 14.07.2005 Klokka 15:37 (-0400) skreiv Trond Myklebust:
> to den 14.07.2005 Klokka 12:17 (-0700) skreiv Dan Stromberg:
> > > An NFSv4 client has no use for statd. The NFSv4 protocol has its own
> > > methods for tracking client and server reboots.
> >
> > lockd too, I hope?
>
> Yes. Lockd is gone too.
>
> The only daemons you need to run on a client in order to get NFSv4
> working are
>
> - idmapd (for translating names/groups <-> uid/gid)
> - rpc.gssd (only if you are using RPCSEC_GSS)
Oops. I forgot... You need to run the portmapper on the client too. The
reason is that the v4 delegation code needs to set up a server for the
callback channel, and the sunrpc code is still under the illusion that
we want it to register every server with portmap.
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs