From owner-freebsd-hackers@FreeBSD.ORG  Fri Jan 14 04:55:50 2011
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 A6677106566B
	for <freebsd-hackers@freebsd.org>; Fri, 14 Jan 2011 04:55:50 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.freebsd.org (Postfix) with ESMTP id 71DAE8FC08
	for <freebsd-hackers@freebsd.org>; Fri, 14 Jan 2011 04:55:50 +0000 (UTC)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id p0E4tNoH067766;
	Thu, 13 Jan 2011 20:55:23 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.14.4/8.13.4/Submit) id p0E4tMvG067765;
	Thu, 13 Jan 2011 20:55:22 -0800 (PST)
Date: Thu, 13 Jan 2011 20:55:22 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <201101140455.p0E4tMvG067765@apollo.backplane.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
References: <1620435629.209827.1294961913954.JavaMail.root@erie.cs.uoguelph.ca>
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
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jan 2011 04:55:50 -0000

: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.:-)

    This is a throwback to when the buffer cache used 32 bit block numbers,
    hence 0x7FFFFFFF was the maximum 'safe' block number multiplied by
    the lowest supported block size (DEV_BSIZE), that could be handled by
    the buffer cache.

    That limit is completely irrelevant now and should probably be set to
    0x7FFFFFFFFFFFFFFFLLU (since seek offsets are signed).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>