From owner-freebsd-current Thu May 25 19:14:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA29709 for current-outgoing; Thu, 25 May 1995 19:14:16 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA29682 for ; Thu, 25 May 1995 19:13:54 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA16119; Fri, 26 May 1995 12:08:16 +1000 Date: Fri, 26 May 1995 12:08:16 +1000 From: Bruce Evans Message-Id: <199505260208.MAA16119@godzilla.zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Subject: Re: newfs weirdness... Cc: current@FreeBSD.org 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. The `size_t len' arg limits the size of objects that can be mapped. This limit is fundamental - it would be hard to map objects larger than the address space (no segments please). This limit will expand automatically when integer sizes and/or address spaces expand, but so will some of the other limits. Bruce