On Thu, Aug 31, 2000 at 01:13:09PM -0700, Linda Walsh wrote:
> Ooops....the time frame is closer to today on part of this.
> While it may be a while before we hit the 1T limit on 1 single device,
> things like readpage, do so based of the inode -- which on a metadisk
> could have a filesize much larger than current physical device limits.
> So it seems that at least at the vnode level this is something that may
> have to go into the 2.4 series fairly soon, or am I missing something?
> Why are blocks int's vs. unsigned's ? Was it to pass back errno's in
> some cases?
It is propably from reasoning of:
"there is really no point in it, as at 32bit systems
int and long are same size, thus same limit comes
with both types."
At 64-bit machines there is, of course, definite difference.
Now our page-cache subsystem is based on the page cluster
size (2^n times machine page size, where n is non negative
integer), thus at i386 the page-cache can support up to
PAGE_SIZE*2^32 -1 file offsets. (4k*4G = 16 T, larger page
clusters drive the adressability higher -- and 64-bit machines
drive it into cosmic magnitudes..)
Some underlying block device subsystems can address that
currently, some others have inherent 512 byte "page_size"
with signed indexes... I think SCSI is in the first camp,
while IDE is in second. (And Ingo has assured us that RAID
code should handle this just fine too.)
That part of the system needs to be verified/revised.
(Verification to determine which need revision can be done
now with document writing regarding the status, actual
revisions are 2.5 issue.)
> --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:28 EST