The ext2 inode contains an unsigned 32 bit integer field for
file size, thus the ultimate limit is 4 GB, but to access over
2 GB, you need to use llseek() and friends with 64-bit offsets.
At the moment I am not sure if the internal infrastructure in
the kernel is pure 64-bit when it comes to current file locations
and read counts, but 2.1 is working on that.
It will be another problem to extend the EXT2 to over 32-bit file
sizes, though.
> we have a need to use files larger than 2G (ugh, dont ask - we also need
> to bump our machine up from 512M to 1G or more of memory...), so i have a
> couple of questions:
>
> - why is there a 2G limit?
> - can the 2G limit be _safely_ increased (to, say, about 5G)?
> - if so, what changes are needed in the ext2 code to do it?
Numerous... Among them 4-layer indirection system in
addition to the current scheme of:
12 direct block pointers
1 singly indirect block pointer
1 doubly indirect block pointer
1 triply indirect block pointer
(I presume people here have background knowledge of the classical
UNIX filesystem block indirection scheme, so I won't explain it.)
That needs alterations into the inode structure, which is not
trivial thing to do, and maintain your sanity.
The ultimate limit is 4G blocks of 512 bytes each, or 4 TB.
Beyond that the EXT2 can't be extended without major resurgery
in which case we might call it something else.
> the machine in question is running a pre-something version of 2.0.31. i
> wouldn't mind moving to a newer 2.0.x kernel, if need be.
With 2.1.78 you propably can do up to 4 GB.
> thanks a lot.
> -matt
> -----------------------------------------------------------------------------
> Matthew Nelson
> Dynamics Technology, Inc.
> 21311 Hawthorne Blvd., Suite 300, Torrance, CA 90503-5610
> Voice: (310) 543-5433 FAX: (310) 543-2117 Email: mnelson@dynatec.com
/Matti Aarnio <matti.aarnio@tele.fi>