Date: Fri, 14 Jan 2011 11:26:29 +0200 From: Daniel Braniss <danny@cs.huji.ac.il> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-hackers@freebsd.org, Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: NFS: file too large Message-ID: <E1PdfvR-000LQE-PM@kabab.cs.huji.ac.il> In-Reply-To: <201101140455.p0E4tMvG067765@apollo.backplane.com> References: <1620435629.209827.1294961913954.JavaMail.root@erie.cs.uoguelph.ca> <201101140455.p0E4tMvG067765@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :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). I just did that and it fixes the problem. BTW, why not make away with the test altogether? Cheers and thanks, danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1PdfvR-000LQE-PM>