Now it is "just" a matter of extending EXT2 to handle 64-bit filesizes,
but at least there is no need to do it in a vacuum...
(Sure we need new syscalls to pass in 64-bit offsets and counts at
all those where it matters -- read()/write()/mmap()/...)
...
> Yes. The kernel doesn't prevent you from filling up a disk with data of
> any abitrary type. Therefore it's not a kernel issue at all. Now, if
> the kernel prevented one from accessing every logical block on a
> N-Gigabyte drive (it eventually will as N gets larger), then there is
> a problem that should be addressed. Presently, with 1024 byte blocks,
> we are only 1/1023th of the way there with a 32-bit block value. It
> will be several years before this is a limitation.
Yeah, sure.. kludges...
Considering the ultimate limits on EXT2 after 64-bit file
size feature has been done:
We MAY some day have filesystems/disk volumes with several
terabytes worth of spindles in one filesystem, and with
1k blocks and 32 bit unsigned block offsets it means
a limit of about 4 TB.
If the block-indexing isn't altered into 64-bits on such
monster system, 4 TB will be the ultimate limit on file
size.
A set of RAID5 (5+1 disks) 9 GB spindles, 91 catenated
together (546 disks) gives roughly that 4 TB, and is not
THAT big a system... Building them up from SPARC-Array
boxes yields pretty dense disk system, for example.
(If I calculated correctly, it fits into two 19 inch
full height racks...)
> Cheers,
> Dick Johnson
>
> Richard B. Johnson
> Project Engineer
> Analogic Corporation
/Matti Aarnio <matti.aarnio@tele.fi>