From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 13 23:38:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7986106566C for ; Thu, 13 Jan 2011 23:38:35 +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 A88718FC15 for ; Thu, 13 Jan 2011 23:38:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC8bL02DaFvO/2dsb2JhbACECKE4rnKNZoEhgzd0BIRohiiLMw X-IronPort-AV: E=Sophos;i="4.60,320,1291611600"; d="scan'208";a="107012597" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 13 Jan 2011 18:38:34 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0459AB3FA2; Thu, 13 Jan 2011 18:38:34 -0500 (EST) Date: Thu, 13 Jan 2011 18:38:34 -0500 (EST) From: Rick Macklem To: Daniel Braniss Message-ID: <1620435629.209827.1294961913954.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: NFS: file too large X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:38:36 -0000 > > > I'm getting 'File too large' when copying via NFS(v3, tcp/udp) a > > > file > > > that is larger than 1T. The server is ZFS which has no problem > > > with > > > large > > > files. > > > > > > Is this fixable? > > > > > As I understand it, there is no FreeBSD VFSop that returns the > > maximum > > file size supported. As such, the NFS servers just take a guess. > > > > You can either switch to the experimental NFS server, which guesses > > the > > largest size expressed in 64bits. > > OR > > You can edit sys/nfsserver/nfs_serv.c and change the assignment of a > > value to > > maxfsize = XXX; > > at around line #3671 to a larger value. > > > > I didn't check to see if there are additional restrictions in the > > clients. (They should believe what the server says it can support.) > > > > rick > > well, after some more experimentation, it sees to be a FreeBSD client > issue. > if the client is linux there is no problem. > Try editting line #1226 of sys/nfsclient/nfs_vfsops.c, where it sets nm_maxfilesize = (u_int64_t)0x80000000 * DEV_BSIZE - 1; and make it something larger. I have no idea why the limit is set that way? (I'm guessing it was the limit for UFS.) Hopefully not some weird buffer cache restriction or similar, but you'll find out when you try increasing it.:-) I think I'll ask freebsd-fs@ about increasing this for NFSv3 and 4, since the server does provide a limit. (The client currently only reduces nm_maxfilesize from the above initial value using the server's limit.) Just "grep nm_maxfilesize *.c" in sys/nfsclient and you'll see it. > BTW, I 'think' I'm using the experimental server, but how can I be > sure? > I have the -e set for both nfs_server and mountd, I don't have option > NFSD, > but the nfsd.ko gets loaded. You can check by: # nfsstat -s # nfsstat -e -s and see which one reports non-zero RPC counts. If you happen to be running the regular server (probably not, given the above), you need to edit the server code as well as the client side. Good luck with it, rick