[nfs] linux client - solaris server

[Verwijderd]

[probleem]
Ik probeer vanuit een Redhat 7.3 bak een nfs-share te mounten. (Deze share is aangemaakt op een SunOS 5.8 server (solaris)).
Het mounten gaat op zich prima. Maar het kopieeren van een grote file lukt niet!
Het kopieer-commando kan niet meer onderbroken worden met ^C. Ik moet echt op een tweede shell het kopieeren killen.

[setup solaris]
Deze shared een directory op haar lokale schijf (/RAID1/testfolder):

Ik heb het bestand /etc/dfs/dfstab alsvolgt ge-edit:

code:

#       Place share(1M) commands here for automatic execution
#       on entering init state 3.
#
#       Issue the command '/etc/init.d/nfs.server start' to run the NFS
#       daemon processes and the share commands, after adding the very
#       first entry to this file.
#
#       share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
#       .e.g,
#       share  -F nfs  -o rw=engineering  -d "home dirs"  /export/home2
#share -F nfs /var/dax/xfs
share -F nfs -o rw /RAID1/testfolder

Daarna heb ik daar het commando

code:

shareall

gegeven.

[setup linux-bak]
Ik maakte een directory '/mnt/solaris'.

Daarna geef ik het commando:

code:

mount -t nfs solarisbak:/RAID1/testfolder /mnt/solaris

Vervolgens maak ik een file'tje aan van 10 mb met het commando:

code:

dd if=/dev/zero of=/tmp/10mb count=20480

Wanneer ik deze file kopieer met het commando:

code:

cp /tmp/10mb /mnt/solaris

gaat het mis! Het kopieer-commando is niet meer (op een normale manier) te stoppen. Ook de rest van het netwerk wordt plots een stuk trager.

Heeft iemand een idee wat hier mis kan gaan?

Er zitten overigens geen firewalls tussen de twee computers!

[Verwijderd]

probeer is te mounten met sync of async.

[Verwijderd]

Heb je de laatste patches geinstalled op die solaris box? Welke linux kernel draai je? Staat er nog wat relevants in de logfiles?

[ Voor 25% gewijzigd door Verwijderd op 10-02-2003 17:16 ]

[Verwijderd]

code:

Mount options for nfs
       Instead  of a textual option string, parsed by the kernel, the nfs file
       system expects a binary argument of type  struct  nfs_mount_data.   The
       program   mount  itself  parses  the  following  options  of  the  form
       `tag=value',  and  puts  them  in  the  structure  mentioned:  rsize=n,
       wsize=n,   timeo=n,   retrans=n,  acregmin=n,  acregmax=n,  acdirmin=n,
       acdirmax=n, actimeo=n, retry=n,  port=n,  mountport=n,  mounthost=name,
       mountprog=n,  mountvers=n,  nfsprog=n, nfsvers=n, namlen=n.  The option
       addr=n is accepted but ignored.  Also the  following  Boolean  options,
       possibly  preceded  by  no  are  recognized:  bg, fg, soft, hard, intr,
       posix, cto, ac, tcp, udp, lock.  For details, see nfs(5).

       Especially useful options include

       rsize=8192,wsize=8192
              This will make your nfs connection much  faster  than  with  the
              default  buffer  size  of 1024. (NFSv2 does not work with larger
              values of rsize and wsize.)

       hard   The program accessing a file on a NFS mounted file  system  will
              hang  when the server crashes. The process cannot be interrupted
              or killed unless you also specify intr.  When the NFS server  is
              back  online the program will continue undisturbed from where it
              was. This is probably what you want.

       soft   This option allows the kernel to time out if the nfs  server  is
              not  responding  for  some  time. The time can be specified with
              timeo=time.  This option might be  useful  if  your  nfs  server
              sometimes doesn't respond or will be rebooted while some process
              tries to get a file from the server.   Usually  it  just  causes
              lots of trouble.

       nolock Do not use locking. Do not start lockd.

probeer de nfsvers=2 optie is.

[BIM]

Wij hebben op het werk een vergelijkbaar probleem gehad. Mounten ging op zich prima maar, de performance was beslist niet OK. Integendeel de default kernel van redhat 7.3 is namelijk nogal dodgy wat betreft NFS.
In ons geval had deze bug als gevolg dat we onze Solaris fileservers, die bepaald geen kleine jongens zijn, volledig over de zeik (lees: crash) kregen. In principe was er sprake van een DOS attack van de RH 7.3 clients naar de solaris machines.

Het volledige verhaal over deze bug:

Why is NFS slow?

This past weekend, the Graphics lab stumbled onto an apparent nfs bug in Redhat 7.3's new 2.4.18 kernel. This is standard on all RedHat 7.3 systems. Apparently, an experimental patch (for 2.4.17) was applied providing NFS v3 over TCP. In that mode, a 32K buffer is a maximum. The default for UDP or TCP should be 4096K. Regardless, the kernel is attempting 32K packets over UDP (not TCP) and a lot of fragments cause the client to go to 100% of its network utilization, and the NetApp becomes unresponsive to other hosts.

Solutions to date are to either force NFS v2 (option "v2" on mounts) and to mount affected file servers with "rsize=8192,wsize=8192". Just specifying 'v2' is not enough.

Another solution that also seems to work wonders (I've tested it with compiles, etc) is to specify "tcp" as the only necessary option. Even at 32K packets, the NetApps work fine without performance issues when v3/tcp/32K is the applied combination.

I'd advise all users to use tcp or enforce some w/rsize limits for NFS connections from RH 7.3 clients until a patch is posted. This is equivalent to a DoS attack.

Ik hoop date bovenstaande helpt .................
Makkelijkste oplossing is dus om de mount te testen met mount -t nfs -o rsize=8192,wsize=8192. Indien dit goed werkt is het zeer aan te bevelen de kernel te upgraden.