(no subject)

(no subject)

[Ozy Ali]

hi,
   ive got a system running on redhat 6.2.  i am attempting to get another 2 
pcs connected up top it as a network.  i am currently trying to install via 
nfs as i only have 1 cd in the main pc.  i have trawled through many HOWTO's 
and tried their ideas. (ie. change the file etc\exports)  my problem is no 
matter wot i try i always get the same message wen i boot up the netboot.img 
floppy in the 2nd pc. the error reads " i could not mount that directory 
from the server, mount: RPC: port mapper failure - RPC:timed out.

im going out of my minds with this as ive been at it for about 2 weeks.  any 
help would be greatly appreciated.

Ozy.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

>>>>> " " == Ozy Ali <ozzeee@hotmail.com> writes:

     > hi,
     >    ive got a system running on redhat 6.2.  i am attempting to
     >    get another 2 pcs connected up top it as a network.  i am
     >    currently trying to install via nfs as i only have 1 cd in
     >    the main pc.  i have trawled through many HOWTO's and tried
     >    their ideas. (ie. change the file etc\exports) my problem is
     >    no matter wot i try i always get the same message wen i boot
     >    up the netboot.img floppy in the 2nd pc. the error reads " i
     >    could not mount that directory from the server, mount: RPC:
     >    port mapper failure - RPC:timed out.


     > im going out of my minds with this as ive been at it for about
     > 2 weeks.  any help would be greatly appreciated.


The error message is fairly explicit: the portmapper program
(a.k.a. "/sbin/portmap") on your server appears not to be accessible
to this client.

Is portmap not running on the server, or is there anything in
/etc/hosts.deny or in /etc/sysconfig/ipchains for instance that might
be blocking access to that client?

Cheers,
  Trond

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Ozy Ali]

my host.deny file is empty, and i cant locate ipchain file that u talk of.  
the ip that i am attempting to install from is in the host.allow file, as i 
read it should be in a HOWTO on NFS installation.  furthermore, when i 
execute the rpcinfo -p command, it says portmapper is running on both tcp 
and udp protocols.  what am i doing wrong?  by the way...i am a linux 
newbie, so be patient with me :-)


>From: Trond Myklebust <trond.myklebust@fys.uio.no>
>To: "Ozy Ali" <ozzeee@hotmail.com>
>CC: nfs@lists.sourceforge.net
>Subject: Re: [NFS] (no subject)
>Date: 22 Mar 2002 15:45:46 +0100
>
> >>>>> " " == Ozy Ali <ozzeee@hotmail.com> writes:
>
>      > hi,
>      >    ive got a system running on redhat 6.2.  i am attempting to
>      >    get another 2 pcs connected up top it as a network.  i am
>      >    currently trying to install via nfs as i only have 1 cd in
>      >    the main pc.  i have trawled through many HOWTO's and tried
>      >    their ideas. (ie. change the file etc\exports) my problem is
>      >    no matter wot i try i always get the same message wen i boot
>      >    up the netboot.img floppy in the 2nd pc. the error reads " i
>      >    could not mount that directory from the server, mount: RPC:
>      >    port mapper failure - RPC:timed out.
>
>
>      > im going out of my minds with this as ive been at it for about
>      > 2 weeks.  any help would be greatly appreciated.
>
>
>The error message is fairly explicit: the portmapper program
>(a.k.a. "/sbin/portmap") on your server appears not to be accessible
>to this client.
>
>Is portmap not running on the server, or is there anything in
>/etc/hosts.deny or in /etc/sysconfig/ipchains for instance that might
>be blocking access to that client?
>
>Cheers,
>   Trond
>
>_______________________________________________
>NFS maillist  -  NFS@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/nfs


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[shalini jain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 763 bytes --]

hi list!

i am implementing NFS protocol on Windows,i.e,
Windows98 would be the server. i read the RFC for
version 3 and have a question regarding how XDR would
be implemented on Windows98? or should i say, what IDE
should we program in ? VC++, typical Win32
programming? 

this question is with regard to the project i am
currently working on, but as an aside, i would also
like to know where XDR could be emploed even in OS
like Unix or Linux ?

please reply asap.

Shalini


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Ozy Ali]

hi,
   in an attempt to try and get around the port mapper failure error i was 
having earlier (already posted about it), i changed the network card and now 
have a 3com card that gets auto detected from the nfs installation floppy.  
it takes me str8 to the ip address prompt, followed by the nfs server 
details.  the problem now is, that when i enter the information for the 
server, it goes t ocheck and then comes back with rpc: unable to send.  the 
nfs server is ,as far as i know, setup correctly.  the ip adress has been 
allowed in exportfs and also host.allow. nfs services are started up 
succesfully using the command "/etc/rc.d/init.d/nfs start " .wot is the 
problem here? can anyone shed some light ont he situation please?

O.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Tina Arora]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]


thanx so much for helping ..
after running nfsd manually i.e rpc.nfsd 8 ( in /usr/sbin) and after that rpcinfo -p , I am getting the following output.
PROGRAM            VERS PROTO                              PORT                           

100000                     2         tcp                                   111                       portmapper
100000                     2         udp                                  111                      portmapper
100024                     1         udp                                   32768                  status
100024                     1         tcp                                   32768                  status
100003                     2         udp                                   2049                      nfs
100003                     3         udp                                   2049                      nfs
100021                     1         udp                                   32770              nlockmgr
100021                     3         udp                                   32770                   ,,
100021                     4         udp                                  32770                     ,,


but without manually running rpc.nfsd 8 i get only the portmapper and status lines( total 4) .......
what is the problem..CUD it be that  my rpc.nfsd is in /usr/sbin and I have installed the binaries in /sbin.........
Do reply 
Also here is what my  /proc/fs/nfs   shows (actually nothing)
# version 1.0
# Path Client (Flags) # IPs

Bye 
Tina


[-- Attachment #2: Type: text/html, Size: 5925 bytes --]

(no subject)

[Nir Cohen]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

unsubscribe

[-- Attachment #2: Type: text/html, Size: 326 bytes --]

(no subject)

[Nir Cohen]

[-- Attachment #1: Type: text/plain, Size: 17 bytes --]

unsubscribe nfs

[-- Attachment #2: Type: text/html, Size: 330 bytes --]

(no subject)

[Adam.Szabo]

hi im using a SuSE Linux distribution (newest firewall CD 2)

i want to install NFS, but i cannot find mountd - where can i get the 
nfs-utils ??

thx 

adam




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Emanuel.Quass]

[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]

Hello,

Can anyone give me some hints please.
I'm having a Linux-Box (in-cat26/PIII 2.4.18-4GB/SuSE 8.0 ) as a CATIA 
Fileserver and a IBM/RS6000 ( in-kom8/aix 4.3.3 ML 9) as a Client both 
connected with 100MB/Full Duplex(e100 driver)!

/etc/exports /etc/filesystems
mountpoint      in-kom8(root_squash,insecure,rw,async) 
in-cat26:/mountpoint    /mountpoint 
(bg,hard,intr,vers=3,proto=udp,rsize=8192,wsize=8192)

During a "ls" I get the following errors: (tcpdump host in-kom8  and  udp 
-s 1024)

14:27:05.316761 arp who-has in-kom5. tell in-cat26.
14:27:05.316892 arp reply in-kom5. is-at 8:0:69:e:ec:f3
14:27:12.977233 in-kom8.781891772 > in-cat26.nfs: 128 getattr fh Unknown/1
14:27:12.977281 in-cat26.nfs > in-kom8.781891772: reply ok 112 getattr REG 
100600 ids 4732/200 sz 0x000000aec  (DF)
14:27:12.977645 in-kom8.781891773 > in-cat26.nfs: 124 lookup fh Unknown/1 
"ls"
14:27:12.977674 in-cat26.nfs > in-kom8.781891773: reply ok 116 lookup 
ERROR: No such file or directory (DF)
14:27:12.981685 in-kom8.781891774 > in-cat26.nfs: 124 lookup fh Unknown/1 
"ls"
14:27:12.981703 in-cat26.nfs > in-kom8.781891774: reply ok 116 lookup 
ERROR: No such file or directory (DF)
14:27:12.986623 in-kom8.781891775 > in-cat26.nfs: 116 getattr fh Unknown/1
14:27:12.986638 in-cat26.nfs > in-kom8.781891775: reply ok 112 getattr DIR 
40755 ids 4732/200 sz 0x0000008b8  (DF)
14:27:51.426006 in-kom8.781891776 > in-cat26.nfs: 1472 write fh Unknown/1 
2800 bytes @ 0x000000000 (frag 8477:1480@0+)
14:27:51.426008 in-kom8.> in-cat26.: (frag 8477:1476@1480)
14:27:51.426312 in-cat26.nfs > in-kom8.781891776: reply ok 136 write 
[|nfs] (DF)
14:27:51.428035 in-kom8.781891777 > in-cat26.nfs: 140 commit fh Unknown/1 
4096 bytes @ 0x000000000
14:27:51.428058 in-cat26.nfs > in-kom8.781891777: reply ok 128 commit (DF)


During a login I get the following errors:
4:34:21.916125 in-kom8.781897917 > in-cat26.nfs: 124 lookup fh Unknown/1 
"df"
14:34:21.916145 in-cat26.nfs > in-kom8.781897917: reply ok 116 lookup 
ERROR: No such file or directory (DF)
14:34:21.916366 in-kom8.781897918 > in-cat26.nfs: 124 lookup fh Unknown/1 
"df"
14:34:21.916385 in-cat26.nfs > in-kom8.781897918: reply ok 116 lookup 
ERROR: No such file or directory (DF)
14:34:21.917741 in-kom8.781897919 > in-cat26.nfs: 124 lookup fh Unknown/1 
"df"
14:34:21.917757 in-cat26.nfs > in-kom8.781897919: reply ok 116 lookup 
ERROR: No such file or directory (DF)
14:34:21.921693 in-kom8.781897920 > in-cat26.nfs: 124 lookup fh Unknown/1 
"df"
14:34:21.921707 in-cat26.nfs > in-kom8.781897920: reply ok 116 lookup 
ERROR: No such file or directory (DF)
14:34:21.928997 in-kom8.781897924 > in-cat26.nfs: 116 fsstat fh Unknown/1
14:34:21.929013 in-cat26.nfs > in-kom8.781897924: reply ok 84 fsstat 
[|nfs] (DF)

Can anyone explain to me why the Client is looking for a file "df" and 
what does "Unknown/1" mean?

Thanks for any help or hints (If you need additional information please 
ask)

        Emanuel

[-- Attachment #2: Type: text/html, Size: 4942 bytes --]

Re: (no subject)

[Trond Myklebust]

>>>>> " " =3D=3D Emanuel Quass <Emanuel.Quass@temic.com> writes:

     > (DF) Can anyone explain to me why the Client is looking for a
     > file "df" and what does "Unknown/1" mean?  Thanks for any help
     > or hints (If you need additional information please ask) =A0 =A0 =A0
     > =A0 Emanuel

Trivial reply: someone is running 'df' and PATH references some
directory on the NFS server perhaps? 'Unknown' means just what is
says: 'df' was not found in the directories referenced by the PATH.

Cheers,
  Trond


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Steve Salazar]

I have been reading the nfs documentation and mailing lists and it is not 
clear to me whether the current nfs implementation supports kerberos 
authentication or not.  There is nothing about that in the howto but in the 
mailing list I see repeated references to "NFS using RPCSEC_GSS".  However, 
I haven't found any documentation on this either.

This issue mentioned in the howto:

"But the root user on the client can still use su to become any other user 
and access and change that users files!" say you. To which the answer is: 
Yes, and that's the way it is, and has to be with Unix and NFS. This has one 
important implication: All important binaries and files should be owned by 
root, and not bin or other non-root account, since the only account the 
clients root user cannot access is the servers root account.

will not work for for our setup.  We have kerberos in place for logins on 
our linux/solaris/windows network and a kerberized samba but so far we have 
no good solution for nfs since we will definitely need to allow local root 
on the linux workstations on our network.

Could anyone point me at some good documentation on how to deploy nfs using 
kerberos?  Thanks in advance for any info.



_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: (no subject)

[Lever, Charles]

hi steve-

the limitation you point out below is real, and would be
addressed by Kerberos authentication.  however...

Linux NFS does not support RPCSEC mechanisms in the stable
kernel at the moment.  that support is going into the
development kernel (2.5) over the next few months, and
will be available in a stable kernel when 2.6 appears, at
least for NFSv4.  if we're all very very good, RPCSEC may
also be supported for the older versions of NFS too.

> -----Original Message-----
> From: Steve Salazar [mailto:eagsalazar@hotmail.com]
> Sent: Sunday, March 09, 2003 2:58 PM
> To: nfs@lists.sourceforge.net
> Subject: [NFS] (no subject)
>=20
>=20
> I have been reading the nfs documentation and mailing lists=20
> and it is not=20
> clear to me whether the current nfs implementation supports kerberos=20
> authentication or not.  There is nothing about that in the=20
> howto but in the=20
> mailing list I see repeated references to "NFS using=20
> RPCSEC_GSS".  However,=20
> I haven't found any documentation on this either.
>=20
> This issue mentioned in the howto:
>=20
> "But the root user on the client can still use su to become=20
> any other user=20
> and access and change that users files!" say you. To which=20
> the answer is:=20
> Yes, and that's the way it is, and has to be with Unix and=20
> NFS. This has one=20
> important implication: All important binaries and files=20
> should be owned by=20
> root, and not bin or other non-root account, since the only=20
> account the=20
> clients root user cannot access is the servers root account.
>=20
> will not work for for our setup.  We have kerberos in place=20
> for logins on=20
> our linux/solaris/windows network and a kerberized samba but=20
> so far we have=20
> no good solution for nfs since we will definitely need to=20
> allow local root=20
> on the linux workstations on our network.
>=20
> Could anyone point me at some good documentation on how to=20
> deploy nfs using=20
> kerberos?  Thanks in advance for any info.
>=20
>=20
>=20
> _________________________________________________________________
> The new MSN 8: advanced junk mail protection and 2 months FREE* =20
> http://join.msn.com/?page=3Dfeatures/junkmail
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger=20
> for complex code. Debugging C/C++ programs can leave you=20
> feeling lost and=20
> disoriented. TotalView can help you find your way. Available=20
> on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[gb]

...an analysis that I recently undertook is attached
below.  any comments this group would have would be
extremely beneficial.  please include
(XXXbakerg3@yahoo.com.XXX) in the reply in addition to
(XXXnfs@lists.sourceforge.net.XXX)

SUMMARY

During periods of heavy tcp-nfs traffic to a remote
nfs mounted directory on a Network Appliance filer,
linux systems will "freeze" causing processes
accessing that directory to enter an non-interruptible
deadlocked state.  Using udp-nfs mounts these problems
do not manifest themselves.

ANALYSIS and CONCLUSION

Linux tcp-nfs is not ready for production in our large
scale distributed environment with the current set of
NetApp filers.

While the root of the problem may be with the tcp-nfs
implementation on Linux, it is interesting to note
until a certain load level is generated
via tcp-nfs accessing a directory on a filer, no
problems manifest themselves.

The latest kernel available (2.4.21pre7 + patches via
Chuck Lever of NetApp) do not appear to fix the
problem.

Until this critical problem is resolved, it is a moot
point to argue the advantages of tcp-nfs vs. udp-nfs
regarding network traffic or CPU usage.

RECOMMENDATION

Force automount to use udp via the localoptions line
in 
etc/init.d/autofs.

Contact netapp with the deatils of our testing and ask
why a certain load level of tcp-nfs traffic causes
other tcp-nfs clients to go into the weeds.


Any suggestions welcome, please include me (the
poster) in your replies.

Thanks,

--Greg

(Charles, if you've read this far, please contact me
so that I can reference our NetApp case id #).

GORY DETAILS (go get something to drink first):

* Tools:

traffic generator: iozone (http://www.iozone.org)
analysis equipment: lump of meat and bone located
above the shoulders.

* Testing Procedure:

Three 'control hosts' managed a pool of linux clients
via iozone to generate traffic to target directories
stored on the netapp filers below.

1 NetApp Release 6.2.2D21: Fri Feb 28 18:39:39 PST
2003 (sphere)
    exported directory ( /u/admin-test1 quota)
1 NetApp Release 6.2.2: Wed Oct 16 01:12:25 PDT 2002
(vger)
    exported directory ( /u/admin-test2 qtree)
1 NetApp Release 6.2.2: Wed Oct 16 01:12:25 PDT 2002
(wopr)
    exported directory ( /u/admin-test3 qtree)

Each control host ran a single instance of iozone as
shown below:

ch1: iozone -t 25 -r 64 -s 10000 -+m
iozone.test1.hosts
ch2: iozone -t 25 -r 64 -s 10000 -+m
iozone.test2.hosts
ch3: iozone -t 25 -r 64 -s 10000 -+m
iozone.test3.hosts

# -t 25 25 concurrent test
# -r read in 64kb chunks
# -s size of file in kb
# -+m extended commands enabled

Where the extended command control file contains a
repetitive series of lines, one per test population
host.  Each extended command file referenced a
different nfs-mounted directory from a netapp filer.

valk004 /u/admin-test1 /tool/pandora/sbin/iozone
valk074 /u/admin-test1 /tool/pandora/sbin/iozone
go064 /u/admin-test1 /tool/pandora/sbin/iozone
	.
	.
	.

All filers are connected via fiber gig; all linux
hosts 100baseTX-FD switched.  Network backbone is
catalyst 6509 (netapp filers) and catalyst 4000/6506
(linux clients).

* Test Population A:

10 redhat 7.3 running kernel 2.4.18 using tcp-nfs
7  redhat 7.3 running kernel 2.4.21pre7 using tcp-nfs
6  redhat 7.3 running kernel 2.4.18 using udp-nfs
2  redhat 7.1 running kernel 2.4.16 using udp-nfs

* Test Results A

All clients using tcp-nfs (17/17) fail after a short
amount of time with the following errors:

"nfs server XXX not responding"
"nfs task XXX can't get a request slot"

At which point the remote directories mounted from the
NetApp filers were unavailable.  An examination of the
/proc file system shows that the iozone process
attempting to access the remote file system believes
it 
to be sleeping.

Some of the clients using udp-nfs saw the "nfs server
XXX not responding", but was typically followed with
"nfs server XXX ok".  At no point did the
remote directories mounted from the NetApp filers
become unavailable.

Stopping the traffic simulation did not allow the
clients using tcp-nfs to regain access to the remote
directories.

* Test Population B:

5 redhat 7.3 running kernel 2.4.18 using tcp-nfs
7  redhat 7.3 running kernel 2.4.21pre7 using udp-nfs
11  redhat 7.3 running kernel 2.4.18 using udp-nfs
2  redhat 7.1 running kernel 2.4.16 using udp-nfs

* Test Results B:

After a test period of 12 hours, no problems were seen
with access to remote directories for either tcp-nfs
or udp-nfs clients.

* Test Population C:

7  redhat 7.3 running kernel 2.4.21pre7 using udp-nfs
16  redhat 7.3 running kernel 2.4.18 using udp-nfs
2  redhat 7.1 running kernel 2.4.16 using udp-nfs

* Test Results C:

After a test period of 3 hours, no problems were seen
with access to remote directories for udp-nfs clients.

* Test Population D:

10 redhat 7.3 running kernel 2.4.18 using tcp-nfs
7  redhat 7.3 running kernel 2.4.21pre7 using udp-nfs
6  redhat 7.3 running kernel 2.4.18 using udp-nfs
2  redhat 7.1 running kernel 2.4.16 using udp-nfs

* Test Results D:

All clients using tcp-nfs (10/10) fail after
approximately one hour of time with the following
errors:

"nfs server XXX not responding"
"nfs task XXX can't get a request slot"

At which point the remote directories mounted from the
NetApp filers were unavailable.  An examination of the
/proc file system shows that the iozone process
attempting to access the remote file system believes
it 
to be sleeping.

# cat status 
Name:   df
State:  D (disk sleep)

Some of the clients using udp-nfs saw the "nfs server
XXX not responding", but was typically followed with
"nfs server XXX ok".  At no point did the
remote directories mounted from the NetApp filers
become unavailable.

Stopping the traffic simulation did not allow the
clients using tcp-nfs to regain access to the remote
directories.

ANALYSIS / CONCLUSION

Linux tcp-nfs is not ready for production in our large
scale distributed environment with the current set of
NetApp filers.

While the root of the problem may be with the tcp-nfs
implementation on Linux, it is interesting to note
until a certain load level is generated
via tcp-nfs accessing a directory on a filer, no
problems manifest themselves.

The latest kernel available (2.4.21pre7 + patches via
Chuck Lever of NetApp) does not appear to fix the
problem.

Until this critical problem is resolved, it is a moot
point to argue the advantages of tcp-nfs vs. udp-nfs
regarding network traffic or CPU usage.




__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Spencer Shepler]

Sorry to step in on the middle of this but I wanted to
comment on a couple of things:

After reading your analysis and results, I would assume
that there is a bug in the Linux NFS/TCP client code.


On Wed, gb wrote:

> ANALYSIS and CONCLUSION
> 
> Linux tcp-nfs is not ready for production in our large
> scale distributed environment with the current set of
> NetApp filers.
> 
> While the root of the problem may be with the tcp-nfs
> implementation on Linux, it is interesting to note
> until a certain load level is generated
> via tcp-nfs accessing a directory on a filer, no
> problems manifest themselves.

I would take this to mean that the Linux NFS/TCP bug
is related to particular traffic patterns either at
a specific client or the client combined with the
server's responsiveness under a particular load point.

> The latest kernel available (2.4.21pre7 + patches via
> Chuck Lever of NetApp) do not appear to fix the
> problem.
> 
> Until this critical problem is resolved, it is a moot
> point to argue the advantages of tcp-nfs vs. udp-nfs
> regarding network traffic or CPU usage.

I hope this is meant to say that it is moot to discuss
the Linux NFS/TCP advantages until the bug is found and
corrected.  It is an implementation problem and not a
protocol problem.  Other clients and server are known
to work quite well under a full range of load.

The Linux NFS client and server have come a long way but
unfortunately, there appears to be a couple more bugs to 
get rid of...

Spencer


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

>>>>> " " == bakerg3  <gb> writes:

     > Until this critical problem is resolved, it is a moot point to
     > argue the advantages of tcp-nfs vs. udp-nfs regarding network
     > traffic or CPU usage.

That one data point should imply such a drastic conclusion...

...and not a single tcpdump to demonstrate the problem. Sigh...

Cheers,
  Trond


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[xiyu]

[-- Attachment #1: Type: text/html, Size: 2335 bytes --]

(no subject)

[Ralph Churchill]

I am experiencing a strange problem wherein a file
placed on an exported directory accessible by multiple
clients is occassionally only visible to SOME clients.
However, if I "force" some fake activity on the shared
directory (e.g. touching, then deleting a file in an
infinite loop), then ALL clients see the file at ALL
times. This leads me to belive the problem is related
to some buffering or caching... but where?

Relevant information:

Clients
-------
RedHat 9
kernel 2.6.0-test7
mounted
'rsize=8192,wsize=8192,noatime,nodiratime,noac'

Server
------
RedHat 9
kernel 2.4.20-8
nfs-utils-1.0.1-2.9
exported "*(rw)"
dir is 'ext3' mounted with 'noatime, nodiratime'

Any and all help is appreciated.

RMC

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Ralph Churchill]

--- Ralph Churchill <mrchucho@yahoo.com> wrote:
> I am experiencing a strange problem wherein a file
> placed on an exported directory accessible by
> multiple
> clients is occassionally only visible to SOME
> clients.
> However, if I "force" some fake activity on the
> shared
> directory (e.g. touching, then deleting a file in an
> infinite loop), then ALL clients see the file at ALL
> times. This leads me to belive the problem is
> related
> to some buffering or caching... but where?
> 
> Relevant information:
> 
> Clients
> -------
> RedHat 9
> kernel 2.6.0-test7
> mounted
> 'rsize=8192,wsize=8192,noatime,nodiratime,noac'
> 
> Server
> ------
> RedHat 9
> kernel 2.4.20-8
> nfs-utils-1.0.1-2.9
> exported "*(rw)"
> dir is 'ext3' mounted with 'noatime, nodiratime'

I have a feeling that this inconsistent behavior may
be due to the way our application, matlab, is opening
and closing files. The fact that generating nfs
activity, in the form of a trival read and write in
the shell, causes the problem to disappear leads me to
this conclusion. It seems like it may be buffer
related. Is there anyway I can verify this?

Also, I've tried the 'noac' and 'nocto' options, and
while the 'noac' option seems to decrease response
times, the problems persist. Thank you.

RMC 

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Kyle Perkins]

[-- Attachment #1: Type: text/plain, Size: 11 bytes --]

subscribe

[-- Attachment #2: Type: text/html, Size: 11 bytes --]

(no subject)

[Jonas Lihnell]

Hi there fellow nfs'ers (or whatever I'm supposed to call you :)

I got some issues with my root-on-nfs installation and after an hour of 
googling, reading forums and mailinglist (none in particular, just 
whatever google turned up) and trying a bunch of stuff I thought it was 
time to resort to this mailing list.

I am capable of booting and mounting the rootfs, as well as any other 
nfs shares but it goes slow and from time to time becomes unresponsive 
for some moments. When measuring speed of downloading files to nfs 
share I get decent speed and every few minutes it halts for some 
seconds, sometime just a few, sometimes many.

According to what I've come to know I should set a few options to get 
rid of this situation, namely tcp, rsync, wsync and nfsvers3. 
Unfortunately the booting kernel refuses to use the options I specify 
with append as stated in nfsroot.txt in the documentation folder from 
my kernel.

I can mount the share with the specified options when booted from a 
live-cd (ubuntu 5.10) so as far as I can see it's just a stubborn 
kernel which don't listen to what I say. :D

Some information about my setup and config files:
pxelinux.cfg/default:
"DEFAULT /bzImage
APPEND ip=dhcp root=/dev/nfs 
nfsroot=192.168.0.64:/mnt/storage/network-nodes/default,sync,hard,intr,rw,nolock,rsize=8192,wsize=8192,nfsvers=3,tcp"

Some information I am supposed to give when mailing this list:
nfs-utils version: net-fs/nfs-utils-1.0.6-r6
kernel version: sys-kernel/gentoo-sources-2.6.14-r5
operating system: Gentoo Linux

network layout:
Servers "eth1: DGE-530T Gigabit Ethernet Adapter" connected to a dlink 
gigabit switch which in turn is connected to the clients "eth0: VIA 
Rhine II"

Good to know: "eth0: link up, 100Mbps, full-duplex"

/etc/exports snippet:
"# Netboot
/mnt/storage/network-nodes/     192.168.0.0/24(rw,sync,no_root_squash)"

rcpinfo -p localhost run on the server:
"   100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  33543  status
    100024    1   tcp  47866  status
    100011    1   udp   4002  rquotad
    100011    2   udp   4002  rquotad
    100011    1   tcp   4002  rquotad
    100011    2   tcp   4002  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp  33544  nlockmgr
    100021    3   udp  33544  nlockmgr
    100021    4   udp  33544  nlockmgr
    100021    1   tcp  47867  nlockmgr
    100021    3   tcp  47867  nlockmgr
    100021    4   tcp  47867  nlockmgr
    100005    1   udp    834  mountd
    100005    1   tcp    837  mountd
    100005    2   udp    834  mountd
    100005    2   tcp    837  mountd
    100005    3   udp    834  mountd
    100005    3   tcp    837  mountd"

rpcinfo -p 192.168.0.64 run on the client:
"    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  33543  status
    100024    1   tcp  47866  status
    100011    1   udp   4002  rquotad
    100011    2   udp   4002  rquotad
    100011    1   tcp   4002  rquotad
    100011    2   tcp   4002  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp  33544  nlockmgr
    100021    3   udp  33544  nlockmgr
    100021    4   udp  33544  nlockmgr
    100021    1   tcp  47867  nlockmgr
    100021    3   tcp  47867  nlockmgr
    100021    4   tcp  47867  nlockmgr
    100005    1   udp    834  mountd
    100005    1   tcp    837  mountd
    100005    2   udp    834  mountd
    100005    2   tcp    837  mountd
    100005    3   udp    834  mountd
    100005    3   tcp    837  mountd"



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

On Tue, 2006-01-17 at 22:37 +0100, Jonas Lihnell wrote:

> Some information about my setup and config files:
> pxelinux.cfg/default:
> "DEFAULT /bzImage
> APPEND ip=dhcp root=/dev/nfs 
> nfsroot=192.168.0.64:/mnt/storage/network-nodes/default,sync,hard,intr,rw,nolock,rsize=8192,wsize=8192,nfsvers=3,tcp"

Hmm... "sync" and "rw" are not listed in the nfsroot options (though I
agree that they probably should be).

What happens if you take those two out of the list?

Cheers,
  Trond



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Jonas Lihnell]

Thanks, that did the trick!
Have a nice day trond, and thanks for not only a quick, but also 
accurate reply :)

-- Jonas Lihnell

Quoting Trond Myklebust <trond.myklebust@fys.uio.no>:

> On Tue, 2006-01-17 at 22:37 +0100, Jonas Lihnell wrote:
>
>> Some information about my setup and config files:
>> pxelinux.cfg/default:
>> "DEFAULT /bzImage
>> APPEND ip=dhcp root=/dev/nfs
>> nfsroot=192.168.0.64:/mnt/storage/network-nodes/default,sync,hard,intr,rw,nolock,rsize=8192,wsize=8192,nfsvers=3,tcp"
>
> Hmm... "sync" and "rw" are not listed in the nfsroot options (though I
> agree that they probably should be).
>
> What happens if you take those two out of the list?
>
> Cheers,
>  Trond
>
>





-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[潘思广]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

贵公司领导、财务：
    
        我公司是深圳市宏溢诚贸易有限公司（注册号：4403012161790）。
    成立于2002年6月，经过几年的发展我公司不断壮大，在国内多处大中
    城市设有分公司，是一家集机电设备、电子产品、化工原料、建材、办
    公设备，国内商业、物资供销业等于一体的大型企业。 并与国内上百家  
    公司有着密切的联系。我公司业务量大、进项大、业务范围广，信誉好。
    现我公司特开设代理代开发票业务，代开范围：全国各地运输发票、商
    品销售票、建筑安装票、广告票、其他服务、餐饮、增值票、海关代征
    票等……本公司郑重承诺所有票据均为各单位在税务部门申领，可在网
    上查询或到税务部门抵扣验证。贵厂家、贵公司若有需要请向我公司人
    员联系！
    

    联系电话：0755-21006449或13728960698  范先生
    

    顺祝：生意兴隆，合作愉快！

                                   宏溢诚贸易有限公司财务部


[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Bernd Schubert]

Hi,

I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 =

and the client is 2.6.16. I need some help regarding the nfs protocol.

Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I als=
o =

guess the inode was recycled.

A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
A 'cat /etc/mozilla/mozillarc' gave i/o errors.

Ethereal shows that the getattr gives the correct results, but the read cal=
l =

gives an NFS3ERR_STALE. =

Should the client in this case drop its filehandle cache and entirely =

re-request the file from the server, or is the given i/o error ok?

>From the point of the server, I guess, it already should return the =

NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the =

sources to see why it didn't. (unfs3 was compiled with inode generation =

number support).

After an 'echo 3 > /proc/sys/vm/drop_caches' the problem was solved for now=
, =

of course.


Thanks in advance,
	Bernd



-- =

Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
> Hi,
> 
> I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 
> and the client is 2.6.16. I need some help regarding the nfs protocol.
> 
> Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I also 
> guess the inode was recycled.
> 
> A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
> A 'cat /etc/mozilla/mozillarc' gave i/o errors.
> 
> Ethereal shows that the getattr gives the correct results, but the read call 
> gives an NFS3ERR_STALE. 
> Should the client in this case drop its filehandle cache and entirely 
> re-request the file from the server, or is the given i/o error ok?

The ESTALE error is usually correct. The client should not be reopening
the file unless it can guarantee that the file is the same as the one
that was originally open()ed.

> From the point of the server, I guess, it already should return the 
> NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the 
> sources to see why it didn't. (unfs3 was compiled with inode generation 
> number support).

Yes. Under the close-to-open caching model, the expectation is that the
filehandle will remain valid from the moment the successful GETATTR call
is sent in the first open() request until the last call to close(). If
unfs3 is caching filehandles, then it needs to use something like
inotify in order to figure out when to invalidate its cache.

Cheers,
  Trond


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[qinping]

[-- Attachment #1: Type: text/plain, Size: 4 bytes --]






[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Fabio Olive Leite]

Hi nfs@,

This patch solves an issue found on 32bit architectures, where jiffies
wrap every 50 days. Since many NFS structures are very long lived and
the code uses jiffies everywhere for timestamp comparisons, there are
many places where old data can be considered newer than something
fresh from the server. This one deals with negative dentries, and I'd
like to have it discussed in the list for sanity checking.

    In 32bit architectures the NFS code uses 32bit jiffies for structures
    that can very easily remain allocated for several u32 jiffy wraps,
    fooling tests made only with time_after[_eq]. One such case is for
    negative dentries, that given the correct timing can be considered valid
    even after changing their parent dir's attributes.
    =

    This patch addresses that by using another unused struct dentry field to
    store the higher part of the u64 jiffies. It has more comments than code
    because the issue is subtle, and is made conditional on long being a
    32bit quantity (64bit arches won't exhibit this behavior).

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index cd34697..a21fb87 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -644,11 +644,26 @@ static int nfs_check_verifier(struct inode *dir, stru=
ct dentry *dentry)
 	if ((NFS_I(dir)->cache_validity & NFS_INO_INVALID_ATTR) !=3D 0
 			|| nfs_attribute_timeout(dir))
 		return 0;
+#if (BITS_PER_LONG < 64)
+	/* In 32bit architectures, also check the cached higher bits of
+	 * jiffies64. NFS dentries can sit idle across two sign flips of
+	 * 32bit jiffies and fool time_after[_eq].
+	 */
+	if ((u32)(dentry->d_cookie) !=3D (u32)(get_jiffies_64() >> 32))
+		return 0;
+#endif
 	return nfs_verify_change_attribute(dir, (unsigned long)dentry->d_fsdata);
 }
 =

 static inline void nfs_set_verifier(struct dentry * dentry, unsigned long =
verf)
 {
+#if (BITS_PER_LONG < 64)
+	/* In 32bit architectures we can have problems with dentries that sit
+	 * idle during two flips of the MSB of the u32 jiffies, so we keep
+	 * track of the higher bits in d_cookie.
+	 */
+	(u32)(dentry->d_cookie) =3D (u32)(get_jiffies_64() >> 32);
+#endif
 	dentry->d_fsdata =3D (void *)verf;
 }
 =

@@ -755,8 +770,17 @@ static int nfs_lookup_revalidate(struct dentry * dentr=
y, struct nameidata *nd)
 	inode =3D dentry->d_inode;
 =

 	if (!inode) {
-		if (nfs_neg_need_reval(dir, dentry, nd))
+		if (nfs_neg_need_reval(dir, dentry, nd)) {
+#if (BITS_PER_LONG < 64)
+			dfprintk(VFS, "nfs_lookup_revalidate: expiring neg dentry for %s\n",
+				dentry->d_name.name);
+			dfprintk(VFS, "  d_cookie %08x high_jiffies %08x\n",
+				dentry->d_cookie, (u32)(get_jiffies_64() >> 32));
+			dfprintk(VFS, "  d_fsdata %08x cache_change_attribute %08x\n",
+				dentry->d_fsdata, NFS_I(dir)->cache_change_attribute);
+#endif
 			goto out_bad;
+		}
 		goto out_valid;
 	}
 =


Cheers,
F=E1bio
-- =

ex sed lex awk yacc, e pluribus unix, amem

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[J. Bruce Fields]

J. Bruce Fields <bfields@fieldses.org> wrote:
> OK, good.  I'll revise and post a new series.  (Do people prefer
> another mailbomb or a git url?)

OK, I went for the former; if you'd rather get this out of git, you can

	git clone http://www.linux-nfs.org/~bfields/linux.git
	git checkout server-cluster-lease-api

The changes from the last version seem pretty trivial, but I've
compile-tested this only for now.

I'm ignoring the problem of breaking leases on unlink and rename.  I
think we should go ahead and do this part now--it's adequate for the
current lease semantics, and even more so for our current application
(just turning off leases selectively on some filesystems)--but I'd
really like to solve that problem eventually.

That's probably not going to happen until we get a cluster filesystem
with real lease support into the kernel....

Changes:
	- do away with the break_lease method.
	- rename __setlease to setlease, setlease to vfs_setlease, and
	  make sure it's setlease (the one that doesn't call into the
	  filesystem) that's exported.
	- rename ->set_lease to ->setlease.  (I don't really care which
	  we go with, it just seemed confusing when everything else was
	  already named without the underscore.)
	- Add a trivial patch that disables leases on nfs (as suggested
	  by a patch elsewhere from Peter Staubach)

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[sun lu]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

I am a Chinese linux developer and now working on the ARM9 board EP9315 
development based on linux system. I have downloaded the 
nfs-utils-1.0.6-ptx4 package and attempted to build the nfs service module 
into the ARM linux system so that the ARM board can funtion as a nfs server 
which can be mounted by other boards.
However, some problems confused me :in the package, I have modified the 
file "configure.sh" aiming to let the package's compiling directory link to 
the cross-compiling enviroment 2.95.3( it exists in /usr/local/arm) ,but it 
doesn't work. The package cannot install the nfs modules which work in the 
ARM linux system.
So,I hope if you can give me some advices or offer me some help, I'll be 
appreciated for that very much!!

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com  



[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Cummings]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Check.pdf --]
[-- Type: application/pdf, Size: 13263 bytes --]

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Riccardo Bini]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Bella]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: message.pdf --]
[-- Type: application/pdf, Size: 8159 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Dennis]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: message.pdf --]
[-- Type: application/pdf, Size: 8159 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Eldridge]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Text.pdf --]
[-- Type: application/pdf, Size: 25637 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Olive Crosby]

Penis Enlarge Patch - the formula is proven.

http://www.pafrac.com/

Going on a date - than improve your shape with Penis Enlarge Patch.














------------------------
   Where should he go? He was dazed by the unlimited possibilities before him. To Boston first, as the nearest seaport. He had taken the trip in his mind so many times that he knew the exact minute when the train would cross the state line and he would be really escaped from the net which had bound him all his life. From Boston to Jamaica as the nearest place that was quite, quite different from Vermont. He had no desire to see Europe or England. Life there was too much like what he had known. He wanted to be in a country where nothing should remind him of his past. From Jamaica where? His stiff old fingers painfully traced out a steamship line to the Isthmus and thence to Colombia. He knew nothing about that country. All the better. It would be the more foreign. Only this he knew, that nobody in that tropical country farmed it, and that was where he wanted to go. From Colombia around th
 e Cape to Argentina. He was aghast at the cost, but instantly decided that he would go ste
 erage. There would be more 
I  went often to  look at the collection of curiosities  in  HeidelbergCastle, and one day  I surprised the  keeper of it with  my German. I  spokeentirely in that language. He was greatly interested; and after I had talked


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Mahoney O.Becky]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: facts.pdf --]
[-- Type: application/pdf, Size: 6345 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Piotr Kandziora]

Server NFS: 192.168.0.166
client 1: 192.168.0.169
client 2: 192.168.0.183

showmount output on server:
# showmount -a
All mount points on hostname:
*:/aa
*:/bb
192.168.0.169:*
192.168.0.183:*

# cat /var/lib/nfs/rmtab
192.168.0.183:*:0x00000001
*:/aa:0x00000002
192.168.0.169:*:0x00000002
*:/bb:0x00000002

client 1:
# mount|grep 166
192.168.0.166:/aa on /mnt/tmp0 type nfs (rw,addr=192.168.0.166)
192.168.0.166:/bb on /mnt/tmp1 type nfs (rw,addr=192.168.0.166)

client 2:
# mount|grep 166
192.168.0.166:/aa on /mnt/tmp0 type nfs
(rw,vers=3,rsize=32768,wsize=32768,hard,proto=udp,timeo=7,retrans=3,addr=192.168.0.166)

On client 1 there are mounted two shares (aa and bb), on client 2 only one share (aa).

My questions are:

How to get information about mounted shares on concrete clients from showmount or other command?

What is meaning of asterisks in showmount output?




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Jeff Layton]

On Thu, 02 Aug 2007 09:24:28 +0200
Piotr Kandziora <raveen@tlen.pl> wrote:

> Server NFS: 192.168.0.166
> client 1: 192.168.0.169
> client 2: 192.168.0.183
> 
> showmount output on server:
> # showmount -a
> All mount points on hostname:
> *:/aa
> *:/bb
> 192.168.0.169:*
> 192.168.0.183:*
> 
> # cat /var/lib/nfs/rmtab
> 192.168.0.183:*:0x00000001
> *:/aa:0x00000002
> 192.168.0.169:*:0x00000002
> *:/bb:0x00000002
> 
> client 1:
> # mount|grep 166
> 192.168.0.166:/aa on /mnt/tmp0 type nfs (rw,addr=192.168.0.166)
> 192.168.0.166:/bb on /mnt/tmp1 type nfs (rw,addr=192.168.0.166)
> 
> client 2:
> # mount|grep 166
> 192.168.0.166:/aa on /mnt/tmp0 type nfs
> (rw,vers=3,rsize=32768,wsize=32768,hard,proto=udp,timeo=7,retrans=3,addr=192.168.0.166)
> 
> On client 1 there are mounted two shares (aa and bb), on client 2 only one share (aa).
> 
> My questions are:
> 
> How to get information about mounted shares on concrete clients from showmount or other command?
> 

This info will never be reliable -- see the notes on rmtab in
rpc.mountd(8).

> What is meaning of asterisks in showmount output?

The nfs-utils rmtab handling code was recently fixed a few months ago.
You're likely running older code that's inserting these bogus entries
into the rmtab for each mount.

-- 
Jeff Layton <jlayton@redhat.com>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Piotr Kandziora]

Dear All,

Hi, I have some issue with NFS exporting. I am using Debian with 2.6.17-13 kernel, NFS 1.0.9, portmap 5-9 and LVM2 as NFS server. I have also a share which is exported via NFS. When I extend Logical Volume where the share is located on my clients I have to re-mount the share, but not on all.
Debian and Gentoo distribution can handle with this, but on Mandriva, Ubuntu and Solaris systems I get "NFS file handle", when I tro to access to it.
According to my investigation it is not related to kernel or portmap versions of clients.

-work good(without remounting):
    -Debian with portmap 6-0 and 2.6.21 kernel
    -Gentoo with portmap 5-0 and 2.6.16 kernel
-did not work - remount was needed:
    -Mandriva with portmap 4-0 and 6-0 and 2.6.17 kernel
    -Ubuntu with portmap 5-0 2.6.20 kernel

Did I miss something? What is this related to? Please help - in my environment we have many Linux clients different distribution and it is not desired to remount. I must also mention that the same behaviour I get after restarting the server.

Best Regards

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[采购成本降低技巧及供应商管理]

[-- Attachment #1.1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.1.2: Type: text/html, Size: 483 bytes --]

[-- Attachment #1.2: "供应商001.gif" --]
[-- Type: image/gif, Size: 22189 bytes --]

[-- Attachment #1.3: "供应商002.gif" --]
[-- Type: image/gif, Size: 13326 bytes --]

[-- Attachment #1.4: "供应商003.gif" --]
[-- Type: image/gif, Size: 15047 bytes --]

[-- Attachment #1.5: "供应商004.gif" --]
[-- Type: image/gif, Size: 25558 bytes --]

[-- Attachment #1.6: "供应商005.gif" --]
[-- Type: image/gif, Size: 8659 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[grikxd]

[-- Attachment #1.1: Type: text/plain, Size: 23 bytes --]






grikxd
2007-08-10

[-- Attachment #1.2: Type: text/html, Size: 524 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Neil Brown]

Subject: ANNOUNCE nfs-utils-1.1.1
X-Mailer: VM 7.19 under Emacs 21.4.1
FCC: ~/.mail/nfs-utils
X-face:	[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD\ui5Fh?f
	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gldn~*FK9x
	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ
--text follows this line--

About 5 months since 1.1.0, nfs-utils-1.1.1 has just been released.

It can be found on sourceforge   http://download.sourceforge.net/nfs
or kernel.org                    http://www.kernel.org/pub/linux/utils/nfs/nfs-utils-1.1.1.tar.gz

It includes:

   Lots of fixes and improvements to mount.nfs and umount.nfs
    - The new "text based mount options" kernel interface is now
       supported, but is not yet the default
    - new mount option 'nosharecache'
    - shorter timeouts for TCP connections (not 75 seconds!)
   More efficient support for site with a large number of netgroups.
   "nfsstate --since" for easily reporting incremental statistics.
   Lots of compile warnings silenced.
   Clean up of the logging code.
   Fixed memory leaks in mountd.

I will be handing over maintenance of the nfs-utils package to 
    Steve Dickson <SteveD@redhat.com>

so please ensure that any patches you want included get sent to him.
(Thanks Steve!!)

We suspect that in the next release the use of text based mount
options will be the default (on kernels that support it).  In the mean
time, please consider testing this functionality by using "-i".
e.g
    /sbin/mount.nfs host:/path /my/directory -i -o options

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[『晴れたらいいね』]

月刊IP 2007年11月号（9/29発売）でも紹介された高機能フリーソフト
　　　【大人気フリーソフトのVista対応最新版】
何万件でもメール一括送信フリーソフト MailTrack2007 Windows Vista対応
登録など一切不要　ダウンロード後、即送信 今すぐ無料ダウンロード
               http://to-more-system.com/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
広告欄1　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
広告欄2　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
広告欄3　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　　↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
　　　【貴方の広告を何十万件も継続配信しませんか】

月刊 IP2007年11月号（9/29発売）で紹介されたMailTrack2007の
ユーザーが送信した送信文章に貴方の広告を掲載しませんか。
大人気のソフトだから毎日数万件の配信を誇っています。　　
　　　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　　　　　　　　　以上自動掲載広告欄
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━　


MailTrack2007 http://to-more-system.com/ で送信 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[immanuel lily]

5c3Bycwg0sXLzMHNwSAtINPUwdLUIPfB28XHzyDCydrOxdPBISDrwd7F09TXxc7OzyDP1CDQ0s/G
xdPTyc/OwczP1y4KQ8HN2cUg0M/MztnFINLFx9XM0dLOzyDPws7P18zRxc3ZxSDCwdrZICjtz9PL
18EsIPLP09PJ0Swg8+7nKSAKQ8HNz8Ug08/X0sXNxc7Oz8Ugz8LP0tXEz9fBzsnFIArz0MXbydTF
IC0gxdPU2CDF3cUg18/azc/Wzs/T1NggCu3P08vXwTogLSA2Nu8tMzXvNgoKCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBTcGx1bmsgSW5jLgpTdGls
bCBncmVwcGluZyB0aHJvdWdoIGxvZyBmaWxlcyB0byBmaW5kIHByb2JsZW1zPyAgU3RvcC4KTm93
IFNlYXJjaCBsb2cgZXZlbnRzIGFuZCBjb25maWd1cmF0aW9uIGZpbGVzIHVzaW5nIEFKQVggYW5k
IGEgYnJvd3Nlci4KRG93bmxvYWQgeW91ciBGUkVFIGNvcHkgb2YgU3BsdW5rIG5vdyA+PiBodHRw
Oi8vZ2V0LnNwbHVuay5jb20vCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCk5GUyBtYWlsbGlzdCAgLSAgTkZTQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRw
czovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9uZnMK

Re: (no subject)

[Willis]

/MzFy9TSz87OwdEg0sXLzMHNwSAgCu3Fx8Egy8HexdPU188gz9Qg0NLPxsXT08nPzsHMz9cuCkPB
zdnFINDPzM7ZxSDSxcfVzNHSzs8gz8LOz9fM0cXN2cUgwsHa2SAo7c/Ty9fBLCDyz9PTydEsIPPu
5ykgCufB0sHO1MnRIMvB3sXT1NfBIMkgz9TexdQgCtTFzMXGz84g1yBtc2s6IC0gNjQ4LTY3LTYx
CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNw
bHVuayBJbmMuClN0aWxsIGdyZXBwaW5nIHRocm91Z2ggbG9nIGZpbGVzIHRvIGZpbmQgcHJvYmxl
bXM/ICBTdG9wLgpOb3cgU2VhcmNoIGxvZyBldmVudHMgYW5kIGNvbmZpZ3VyYXRpb24gZmlsZXMg
dXNpbmcgQUpBWCBhbmQgYSBicm93c2VyLgpEb3dubG9hZCB5b3VyIEZSRUUgY29weSBvZiBTcGx1
bmsgbm93ID4+IGh0dHA6Ly9nZXQuc3BsdW5rLmNvbS8KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KTkZTIG1haWxsaXN0ICAtICBORlNAbGlzdHMuc291cmNl
Zm9yZ2UubmV0Cmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL25m
cwo=

(no subject)

[Mike Brodbelt]

subscribe

(no subject)

[Tom H]

(no subject)

[Russell Cattelan]

[-- Attachment #1: Type: text/plain, Size: 10 bytes --]

subscribe

[-- Attachment #2: cattelan.vcf --]
[-- Type: text/x-vcard, Size: 181 bytes --]

begin:vcard
fn:Russell Cattelan
n:Cattelan;Russell
email;internet:cattelan-fTMmaJvPcXhBDgjK7y7TUQ@public.gmane.org
tel;cell:612 805 3144
x-mozilla-html:FALSE
version:2.1
end:vcard