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

On 09/07/2012 02:08, Rick Macklem wrote:
> 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

You did mention that :) Thanks I'll give this one a go.

Vince
>
>> 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"