If ext3 can do 16T, ext2 probably should be able to as well.
There are still int block containers in the block allocation path
that need to be fixed up.
Perhaps ext2 should get the ext2_fsblk_t/ext2_grpblk_t treatment
as ext3 did, for clarity...
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
On Apr 20, 2007 12:10 -0500, Eric Sandeen wrote:
If ext3 can do 16T, ext2 probably should be able to as well.
There are still int block containers in the block allocation path
that need to be fixed up.
Yeah, but who wants to do 16TB e2fsck on every boot? I think there
needs to be some limits
Andreas Dilger wrote:
On Apr 20, 2007 12:10 -0500, Eric Sandeen wrote:
If ext3 can do 16T, ext2 probably should be able to as well.
There are still int block containers in the block allocation path
that need to be fixed up.
Yeah, but who wants to do 16TB e2fsck on every boot? I think there
Mingming Cao wrote:
On Fri, 2007-04-20 at 18:14 -0500, Eric Sandeen wrote:
It's a bug, today.
They are fixed in mm tree, as part of the patches which backports ext3
block reservation code to ext2. filesystem block numbers are all
ext2_fsblk_t type(i.e. unsigned long)(see ext2_new_blocks()).
