From owner-freebsd-hackers  Mon Jan  8 13:23:40 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA09135
          for hackers-outgoing; Mon, 8 Jan 1996 13:23:40 -0800 (PST)
Received: (from dyson@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA09107
          Mon, 8 Jan 1996 13:23:33 -0800 (PST)
From: John Dyson <dyson>
Message-Id: <199601082123.NAA09107@freefall.freebsd.org>
Subject: Re: large files
To: terry@lambert.org (Terry Lambert)
Date: Mon, 8 Jan 1996 13:23:31 -0800 (PST)
Cc: gpalmer@westhill.cdrom.com, wosch@cs.tu-berlin.de, hackers@FreeBSD.org
In-Reply-To: <199601082008.NAA10273@phaeton.artisoft.com> from "Terry Lambert" at Jan 8, 96 01:08:42 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

> 
> 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.
> 
Actually, mmap takes almost no kernel VM space.  It is our bogus
SYSVSHM stuff that takes kernel VM space.
>
> 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.
> 
> You need to talk to the VM guys about fixing this.
> 
Hmm...  That sounds how it actually works!!!

The problem with stuff earlier than current as of about Nov '95 was
that a VM object could not be larger than 4GB, and page offsets were
represented by a long.  We have changed that and now represent the
page location inside of an object as a page index.  The reason for the
2G limit is that filesystem metadata can reside at negative offsets.
We now support a 1Tb limit -- but the retrofit to 2.1 would be very
complicated.

John Dyson
dyson@freebsd.org