Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 May 1995 12:08:16 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, davidg@Root.COM
Cc:        current@FreeBSD.org
Subject:   Re: newfs weirdness...
Message-ID:  <199505260208.MAA16119@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505260208.MAA16119>