From owner-freebsd-current Thu May 25 18:30:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA27170 for current-outgoing; Thu, 25 May 1995 18:30:45 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA27164 for ; Thu, 25 May 1995 18:30:42 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id SAA29303; Thu, 25 May 1995 18:33:43 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id SAA00562; Thu, 25 May 1995 18:30:47 -0700 Message-Id: <199505260130.SAA00562@corbin.Root.COM> To: Bruce Evans cc: current@FreeBSD.org Subject: Re: newfs weirdness... In-reply-to: Your message of "Fri, 26 May 95 10:59:22 +1000." <199505260059.KAA14119@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 25 May 1995 18:30:46 -0700 Sender: current-owner@FreeBSD.org Precedence: bulk >FreeBSD only supports 63 bit file system offsets. Files larger than 2GB >and mmapping at offsets larger than 2GB are currently broken. mmapping >of objects larger than 4G cannot work with the current interfaces. Ummm, the filesystem layer supports 40 bit file system offsets (the amount of a blkno that can be stored in 31 bits). The VM system, however, is currently limited to 31 bit file offsets which is why it can't deal with files larger than 2GB. We're going to fix this limit in the VM system, however, for FreeBSD 2.2 to be 43 bits by changing the 'offset' to be a page offset rather than a byte offset. Once we do this, the limit will be imposed by bugs in the FS that store blkno in an int (the limit will then be 40 bits == 1TB). If we fix the FS bugs, then the limit will again be imposed by the VM system at 43 bits (8TB). I think limits in the terabyte range will be adequate for the medium term. -DG