From owner-freebsd-hackers Mon Jan 8 14:40:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA14739 for hackers-outgoing; Mon, 8 Jan 1996 14:40:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA14704 for ; Mon, 8 Jan 1996 14:40:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA10623; Mon, 8 Jan 1996 15:35:46 -0700 From: Terry Lambert Message-Id: <199601082235.PAA10623@phaeton.artisoft.com> Subject: Re: large files To: dyson@freefall.freebsd.org (John Dyson) Date: Mon, 8 Jan 1996 15:35:46 -0700 (MST) Cc: terry@lambert.org, gpalmer@westhill.cdrom.com, wosch@cs.tu-berlin.de, hackers@FreeBSD.org In-Reply-To: <199601082123.NAA09107@freefall.freebsd.org> from "John Dyson" at Jan 8, 96 01:23:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. Oh, duh, pass the hat! I was thinking SHLIB (mmap), but writing about SHMEM. It is, indeed, the SHMEM, not the mmap() stuff that is bogus! > > 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!!! It is. I was reading the code when I wrote that. I just misattributed the code to the wrong subsystem. 8-(. > 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. Yes. He should go to -current if he really needs this. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.