From owner-freebsd-stable@FreeBSD.ORG Mon May 6 23:15:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2FC04B98 for ; Mon, 6 May 2013 23:15:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EE789EC1 for ; Mon, 6 May 2013 23:15:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAEk4iFGDaFvO/2dsb2JhbABGCoM+gzy7TIEcdIIfAQEBBAEBASArIAsFFg4KAgINGQIpAQkmBggHBAEcBIdrDK96kHCBJIxRCn40B4JAgRMDlGyCQoEmkA6DKSAygQQ1 X-IronPort-AV: E=Sophos;i="4.87,624,1363147200"; d="scan'208";a="28613059" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 06 May 2013 19:15:57 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C5580B3F47; Mon, 6 May 2013 19:15:57 -0400 (EDT) Date: Mon, 6 May 2013 19:15:57 -0400 (EDT) From: Rick Macklem To: Andrew Romanenko Message-ID: <1312928719.161414.1367882157754.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51843432.6060401@gmail.com> Subject: Re: /usr/src over NFS: buildworld fail MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Jeremy Chadwick , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 23:15:59 -0000 Andrew Romanenko wrote: > On 05/02/2013 01:30 AM, Rick Macklem wrote: > > Andrew Romanenko wrote: > >> On 04/30/2013 02:51 AM, Jeremy Chadwick wrote: > >>> On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote: > >>>> Hi everyone! > >>>> /usr/src imported via NFS > >>>> make buildworld is always fails in the same place with error: > >>>> "make: result too large". > >>>> Localy its works fine > >>>> Does anybody know how to fix it? > >>>> > >>>> i386 FreeBSD 9-STABLE (r250044) > >>> Actual output would have been more useful than a paraphrased > >>> response. > >>> The same goes for actual NFS server and client details (OS, > >>> backing > >>> filesystems, make.conf, src.conf, rc.conf, loader.conf, > >>> sysctl.conf, > >>> etc.). > >>> > >>> "Result too large" is error ERANGE (see /usr/include/errno.h), > >>> errno > >>> 34, > >>> assuming that it has a capital "R" ("Result", not "result"). > >>> > >>> I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is > >>> returned directly. > >>> > >>> I do not believe NFS returns ERANGE either. > >>> > >>> There may be cases where the backing filesystem (i.e. the > >>> filesystem > >>> used on the NFS server) could return ERANGE. I know ZFS does, but > >>> only > >>> in one specific case (only if the compression property is > >>> enabled). > >>> I do see some other cases in the ZFS code pertaining to UTF-8 > >>> support > >>> that can return ERANGE but did not look at what those cases may > >>> be. > >>> > >>> You may end up having to do the following: > >>> > >>> rm -fr /usr/obj/* > >>> cd /usr/src > >>> ktrace -t+ -f /tmp/ktrace.out make buildworld > >>> {wait until the failure} > >>> cd /tmp > >>> kdump > >>> > >>> Then look to see what syscall/operation returns this. You may have > >>> to > >>> put this file up on the web somewhere (it should gzip quite well), > >>> and > >>> be aware there may be personal information in it (environment > >>> variables, > >>> contents of files, etc.), so choose wisely. > >>> > >>> Good luck. > >>> > >> Fixed. Trouble was in Linux NFS-server. > >> Also, thx Jeremy for the tip (ktrace + kdump) > >> thanks, everyone > >> > > Coule you please provide more information on the Linux NFS-server > > issue? > > It might be useful if/when others run into interoperability > > problems against a Linux NFS server. > > > > Thanks, rick > > > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to > >> "freebsd-stable-unsubscribe@freebsd.org" > Server: Linux Sabayon > (Linux localhost.localdomain 3.8.0-sabayon #1 SMP Fri Mar 29 13:54:24 > UTC 2013 i686 Genuine Intel(R) CPU T2080 @ 1.73GHz GenuineIntel > GNU/Linux) > Package: net-fs/nfs-utils-1.2.7 > > /etc/exports > /home/bsd/src > 192.168.56.1/24(rw,async,no_subtree_check,root_squash,anonuid=1000,anongid=1001,fsid=1000) > > Client: Freebsd 9-STABLE > (FreeBSD ion.uabsd.org 9.1-STABLE FreeBSD 9.1-STABLE #0 r250121: Wed > May 1 23:38:36 EEST 2013 > root@ion.uabsd.org:/usr/obj/usr/src/sys/GENERIC i386) > > mount command: > mount -t nfs -o ro,nfsv3,tcp 192.168.56.1:/home/bsd/src /usr/src > > Fix: add option fsid=(1000 or any number) to /etc/exports . I don't > understand, Why fsid is so important? Sounds like a question for the Linux NFS mailing list. All I can mention is that most NFS servers use an fsid to uniquely identify a file system on the server. It is often a part of the file handle. Anyhow, thanks for letting us know. If someone reports a similar problem, we can suggest trying adding fsid= to their Linux server's export line. Thanks, rick > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org"