Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Jan 1996 13:23:13 -0800
From:      David Greenman <davidg@Root.COM>
To:        Terry Lambert <terry@lambert.org>
Cc:        gpalmer@westhill.cdrom.com, wosch@cs.tu-berlin.de, hackers@freebsd.org
Subject:   Re: large files 
Message-ID:  <199601082123.NAA01772@corbin.Root.COM>
In-Reply-To: Your message of "Mon, 08 Jan 96 13:08:42 MST." <199601082008.NAA10273@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> Because of various restrictions in the kernel, files >>2Gb aren't
>> supported anyhow. I believe John Dyson has commited fixes to -current
>> to increase this limit. (AFAIR, the file offset is kept as a signed
>> int in the kernel, and the negative offsets are used to keep file
>> metadata. If you look through the mail list archives, you may find
>> discussions on this - I know that when we first fixed the code to
>> support 1Tb FS's there was a discussion about file sizes).
>
>I believe the restriction is based on mmap'ed files taking a portion
>of the kernel address space equal to their size.  This is arguably
>a design flaw in the mmap implementation.
>
>Really, mmap wants to operate on a demand paged window and arrange
>the vnode as the mappable entity so that it can be shared between
>various processes without taking kernel address space to do it.

   This is absolutely, 100% wrong. It does NOT work like that.

>You need to talk to the VM guys about fixing this.

   Right, and you should look at the code someday.

>> Writing to a file past the 2Gb point would have rather unpredictable
>> results as you could probably understand, which is why the mmap()
>> restriction is there also.
>
>I see no real basis for this statement.  The 2G limit is imposed as a
>result of VM restrictions (see the code in /sys/ufs/ffs/ffs_vfsops.c
>in the routine ffs_vmlimits() for details).

   The limit is imposed for a variety of reasons. Most of them have to do with
us not wanting to use 64 bit offsets in the VM system due to the extreme
performance penalty. So we use 32bit page indexes and this gives us a maximum
of 8TB filesizes. I think that is adequate. It's actually bugs in the
filesystem code that causes the limit to be further restricted to 1TB (loss of
precision when doing blockno calculations).
   2.1 does not use page indexes in VM objects (it uses byte offsets), and the
result is that the filesize is restricted to 2GB.

-DG

David Greenman
Core Team/Principal Architect, The FreeBSD Project



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601082123.NAA01772>