From owner-freebsd-hackers Thu Nov 30 10:50:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA10697 for hackers-outgoing; Thu, 30 Nov 1995 10:50:55 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA10692 ; Thu, 30 Nov 1995 10:50:52 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA01126; Thu, 30 Nov 1995 11:45:48 -0700 From: Terry Lambert Message-Id: <199511301845.LAA01126@phaeton.artisoft.com> Subject: Re: Increasing size of shared memory segmenty To: dyson@FreeBSD.ORG Date: Thu, 30 Nov 1995 11:45:48 -0700 (MST) Cc: terry@lambert.org, taob@io.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199511300010.AAA04609@dyson.iquest.net> from "John S. Dyson" at Nov 30, 95 00:10:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1526 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 32M is smaller than the overall limit, (36 bits? 39 bits?) so you should > > be safe, though if you have several of these, you will probably start > > having problems. > > The limit today is 31 Bits :-(. But the code that I am running today > is 39 Bits with perhaps 40 Bits in the offing. It is unlikely that we > will need to use more than a 31 Bit window on a Pentium :-), but now > at least we will be able to have at least 1Tb files with the merged > VM buffer cache scheme. Any chance for windowed access? I'd like to have a 2^63 sized file. The problem is apparently that the mappings are cached based on the virtual address space, when indirecting them through an offset+range mapping would solve the problem nicely. I realize this means adding a range chain at the top level of the buffer cache in the vnode, but this could be reduced to a single compare and only hit the performance if a bit was set saying that the cache data was indirected, and then only if the file size was greater than the mapping limit (it would let you leave it at 31 bits if you wanted). You'd need to steal a bit in the vnode for this, and set it either on open (put it in the in-core vnode) or steal an inode bit and put it on disk. Obviously, I'd prefer an in-core implementation (I'd like to hang the file locks off the vnode instead of the inode as well, so I have ulterior motives). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.