From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 01:09:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB2E106566C for ; Mon, 9 Jul 2012 01:09:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-scalar.mail.uoguelph.ca (esa-scalar.mail.uoguelph.ca [66.199.40.18]) by mx1.freebsd.org (Postfix) with ESMTP id 57EC58FC12 for ; Mon, 9 Jul 2012 01:09:00 +0000 (UTC) Received: from zcs3.mail.uoguelph.ca (new.mail.uoguelph.ca [131.104.93.37]) by esa-scalar.mail.uoguelph.ca (8.14.1/8.14.1) with ESMTP id q6918sQE009887; Sun, 8 Jul 2012 21:08:55 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DD05B79451; Sun, 8 Jul 2012 21:08:54 -0400 (EDT) Date: Sun, 8 Jul 2012 21:08:54 -0400 (EDT) From: Rick Macklem To: Vincent Hoffman Message-ID: <1458419708.103582.1341796134892.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4FF965BA.90407@unsane.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_103581_1076447948.1341796134891" X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 01:09:00 -0000 ------=_Part_103581_1076447948.1341796134891 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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@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@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" ------=_Part_103581_1076447948.1341796134891 Content-Type: text/x-patch; name=atomic-export2.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=atomic-export2.patch LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHNvY2tldC5jLnNhdgkyMDEyLTA3LTA4IDIwOjMyOjM3 LjAwMDAwMDAwMCAtMDQwMAorKysgZnMvbmZzc2VydmVyL25mc19uZnNkc29ja2V0LmMJMjAxMi0w Ny0wOCAyMDo0MjowMy4wMDAwMDAwMDAgLTA0MDAKQEAgLTM1Miw3ICszNTIsNyBAQCBBUFBMRVNU QVRJQyB2b2lkCiBuZnNydmRfZG9ycGMoc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgaW50IGlz ZGdyYW0sCiAgICAgTkZTUFJPQ19UICpwKQogewotCWludCBlcnJvciA9IDAsIGxrdHlwZTsKKwlp bnQgZXJyb3IgPSAwLCBnb3RyZWYgPSAwLCBsa3R5cGU7CiAJdm5vZGVfdCB2cDsKIAltb3VudF90 IG1wID0gTlVMTDsKIAlzdHJ1Y3QgbmZzcnZmaCBmaDsKQEAgLTM3OCw2ICszNzgsMTEgQEAgbmZz cnZkX2RvcnBjKHN0cnVjdCBuZnNydl9kZXNjcmlwdCAqbmQsIAogCQkJCW5kLT5uZF9yZXBzdGF0 ID0gTkZTRVJSX0dBUkJBR0U7CiAJCQkJZ290byBvdXQ7CiAJCQl9CisJCQlnb3RyZWYgPSAxOwor CQkJTkZTTE9DS1Y0Uk9PVE1VVEVYKCk7CisJCQluZnN2NF9nZXRyZWYoJm5mc3Y0cm9vdGZzX2xv Y2ssIE5VTEwsCisJCQkgICAgTkZTVjRST09UTE9DS01VVEVYUFRSLCBOVUxMKTsKKwkJCU5GU1VO TE9DS1Y0Uk9PVE1VVEVYKCk7CiAJCQlpZiAobmQtPm5kX3Byb2NudW0gPT0gTkZTUFJPQ19SRUFE IHx8CiAJCQkgICAgbmQtPm5kX3Byb2NudW0gPT0gTkZTUFJPQ19SRUFERElSIHx8CiAJCQkgICAg bmQtPm5kX3Byb2NudW0gPT0gTkZTUFJPQ19SRUFETElOSyB8fApAQCAtNDcxLDYgKzQ3NiwxMSBA QCBuZnNydmRfZG9ycGMoc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgCiAJCW5kLT5uZF9mbGFn ICY9IH5ORF9TQVZFUkVQTFk7CiAKIG91dDoKKwlpZiAoZ290cmVmICE9IDApIHsKKwkJTkZTTE9D S1Y0Uk9PVE1VVEVYKCk7CisJCW5mc3Y0X3JlbHJlZigmbmZzdjRyb290ZnNfbG9jayk7CisJCU5G U1VOTE9DS1Y0Uk9PVE1VVEVYKCk7CisJfQogCU5GU0VYSVRDT0RFMigwLCBuZCk7CiB9CiAK ------=_Part_103581_1076447948.1341796134891--