I presume you are using 32-bit system, that PLATFORM
has inherent limitation of allowing only up to signed
32-bit interger value space for offsets, and that is
what is happening inside the kernel..
Therefore, before of larger rework of file offset management
the answer is: No, changeing filesystem block size does NOT
change the largest file offset (which is counsidered roughly
same as "file size", unless your files are sparse..) you can
use. That thing is expected to enter 2.3 series kernels soon.
If you have 64-bit system, then things are different.
At Alpha systems I have used 16 GB maximum offsets at 1k block
sized EXT2 filesystems since 1.2 series kernels.
What the blocksize affects is triple indirection mechanism
addressable maximum block offsets. "Some math necessary";
below is an extract from one demo program comments:
* In case the local filesystem is EXT2 or UFS, the triply-
* indirection scheme can support up to following sizes per
* filesystem basic block size:
*
* 512 2 GB + epsilon
* 1k 16 GB + epsilon
* 2k 128 GB + epsilon
* 4k 1024 GB + epsilon
* 8k 8192 GB + epsilon ( not without PAGE_SIZE >= 8 kB )
*
* However, the basic block device layer can support only up to
* 4G blocks of 512 bytes; being at safe side, lets say 2G blocks
* of 512 bytes: 1024 GB without epsilon.
*
* The basic filesystem block size supportable at given system is
* currently dependent on what the system page cache page size is.
* If the filesystem basic block exceeds of the system page size,
* the system does not work currently. (2.2.* series kernels.)
*
*
* bb = sizeof(basic block)
* B = bb / 4
* MaxSize = bb * (B^3 + B^2 + B + 10 +1) -1
* = bb^4 / 4^3 + bb^3 / 4^2 + bb^2 / 4^1 + 10 * bb + bb -1
* = bb^4 / 64 + bb^3 / 16 + bb^2 / 4 + 10 * bb + bb -1
*
* The primary term (bb^4/64) yields that 16 GB for bb=1k
* The 'epsilon' is all the rest, and is less than 1/250 of
* the primary term for 1kB, even less for larger bb values.
*
*
* The EXT2 (and UFS) can address up to 4G of "basic blocks", however
* that limit will likely to be beyond of other limitations from other
* parts of the system.
> Thanks.
> Thiago Lima
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/