Re: Occassional "permission denied" in the middle of a large transfer over NFS

Vincent Hoffman:
> On 08/07/2012 00:26, Rick Macklem wrote:
> > Vincent Hoffman wrote:
> >>
> >> Hi Rick,
> >>
> >> I'm afraid this didnt make any real difference for me.
> >> Since I couldnt test it on the live system I tried it on a test vm.
> >> on the vm (nfs server) I set a looping mount/umount
> >> while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp
> >> ;
> >> done
> >>
> >> and on the client I set a loop of tars of large directorys to the
> >> nfs
> >> mount running under time to see how well it survived. Then
> >> replicated
> >> the test with the patch and without.
> >>
> > Just to confirm, you patched both the kernel and mountd and replaced
> > both
> > on the server?
> >
> > Also, I'm not sure how ZFS handles it's exports. I can't remember if
> > you've
> > tried an exported UFS volume. It might be something ZFS specific?
> >
> > rick
> 
> Hi Rick,
> 
> yes I patched both the kernel and mountd, rebuilt kernel and world (to
> be sure), added the -S flag to mountd in rc.conf and rebooted.
> This is a test VM running -CURRENT and is only exporting a ufs2
> filesystem.
> (11:43:05 <~>) 0 $ cat /etc/exports
> /usr/local/export -maproot=root -alldirs XX.XX.XX.XX
> 
> Client is a 8.3-RELEASE box but I see the same with linux clients.
> (I can confirm that it works fine when I am not running the
> mount/umount
> loop)
> 
Oops, the patch I sent you worked for NFSv4 only. If you also apply the
attached patch, it seems to work for NFSv3 as well.
The patch is also at:
  http://people.freebsd.org/~rmacklem/atomic-export2.patch

You must also run the new/experimental server. (I can't remember if I
mentioned that before.)

rick

> 
> The production system has been fine since I removed the SIGHUP call in
> mount.c so thanks for that suggestion.
> 
> 
> Vince
> >
> >> [root_at_seaurchin ~]# ministat nopatch.txt atomicpatch.txt
> >> x nopatch.txt
> >> + atomicpatch.txt
> >> +--------------------------------------------------------------------------------------------------+
> >> |
> >> *
> >> |
> >> |
> >> *
> >> |
> >> |
> >> x*
> >> |
> >> |   xx*
> >> x
> >> |
> >> |  +x**
> >> xx
> >> |
> >> |  **** xxx
> >> x
> >> |
> >> |  **** xxx +x+
> >> +
> >> |
> >> |  ****+*xx +x+ x
> >> +
> >> |
> >> |  ****+*x****++++x + +
> >> x |
> >> |  *************+*xx+ +++x * x
> >> x |
> >> |  ****************x**++*x+***x+ x*+ x ++*+ + x+ +x +
> >> + +|
> >> |||_______M_M_A__A_______|______|
> >> |
> >> +--------------------------------------------------------------------------------------------------+
> >> N Min Max Median Avg Stddev
> >> x 101 1.25 106.8 14.08 21.892178 22.196005
> >> + 101 1.21 186.93 18.46 27.995842 30.523218
> >> No difference proven at 95.0% confidence
> >>
> >>
> >> (excuse wrapped ascii art)
> >>
> >> I think I'll have a look at the nfse patch set and see how that
> >> performs.
> >>
> >> Thanks for all your work on NFS on FreeBSD.
> >>
> >> Vince
> >>
> >>>>> Also, you could easily hack mount.c so that it doesn't send a
> >>>>> SIGHUP
> >>>>> to mountd (which causes the exports to be reloaded) every time a
> >>>>> local
> >>>>> fs is mounted.
> >>>> True and I may have to do that for the production NAS for the
> >>>> time
> >>>> being.
> >>>> Thanks for looking at this.
> >>>>
> >>>> Vince
> >>>>> rick
> >>>>>
> >>>>>>> thanks, Vince
> >>
> >> _______________________________________________
> >> freebsd-current_at_freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to
> >> "freebsd-current-unsubscribe_at_freebsd.org"
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"