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]>
Index: linux-2.6.21-rc5/fs/ext2/balloc.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/ext2/balloc.c
+++ linux-2.6.21-rc5/fs/ext2/balloc.c
@@ -323,7 +323,7 @@ got_it:
* bitmap, and then for any free bit if that fails.
* This function also updates quota and i_blocks field.
*/
-int ext2_new_block(struct inode *inode, unsigned long goal,
+unsigned long ext2_new_block(struct inode *inode, unsigned long goal,
u32 *prealloc_count, u32 *prealloc_block, int *err)
{
struct buffer_head *bitmap_bh = NULL;
@@ -332,8 +332,8 @@ int ext2_new_block(struct inode *inode,
int group_no; /* i */
int ret_block; /* j */
int group_idx; /* k */
- int target_block; /* tmp */
- int block = 0;
+ unsigned long target_block; /* tmp */
+ unsigned long block = 0;
struct super_block *sb = inode->i_sb;
struct ext2_sb_info *sbi = EXT2_SB(sb);
struct ext2_super_block *es = sbi->s_es;
@@ -460,7 +460,7 @@ got_block:
sbi->s_itb_per_group))
ext2_error (sb, "ext2_new_block",
"Allocating block in system zone - "
- "block = %u", target_block);
+ "block = %lu", target_block);
if (target_block >= le32_to_cpu(es->s_blocks_count)) {
ext2_error (sb, "ext2_new_block",
Index: linux-2.6.21-rc5/fs/ext2/ext2.h
===================================================================
--- linux-2.6.21-rc5.orig/fs/ext2/ext2.h
+++ linux-2.6.21-rc5/fs/ext2/ext2.h
@@ -91,7 +91,7 @@ static inline struct ext2_inode_info *EX
/* balloc.c */
extern int ext2_bg_has_super(struct super_block *sb, int group);
extern unsigned long ext2_bg_num_gdb(struct super_block *sb, int group);
-extern int ext2_new_block (struct inode *, unsigned long,
+extern unsigned long ext2_new_block (struct inode *, unsigned long,
__u32 *, __u32 *, int *);
extern void ext2_free_blocks (struct inode *, unsigned long,
unsigned long);
Index: linux-2.6.21-rc5/fs/ext2/inode.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/ext2/inode.c
+++ linux-2.6.21-rc5/fs/ext2/inode.c
@@ -107,7 +107,7 @@ void ext2_discard_prealloc (struct inode
#endif
}
-static int ext2_alloc_block (struct inode * inode, unsigned long goal, int *err)
+static unsigned long ext2_alloc_block (struct inode * inode, unsigned long goal, int *err)
{
#ifdef EXT2FS_DEBUG
static unsigned long alloc_hits, alloc_attempts;
@@ -425,13 +425,13 @@ static int ext2_alloc_branch(struct inod
int n = 0;
int err;
int i;
- int parent = ext2_alloc_block(inode, goal, &err);
+ unsigned long parent = ext2_alloc_block(inode, goal, &err);
branch[0].key = cpu_to_le32(parent);
if (parent) for (n = 1; n < num; n++) {
struct buffer_head *bh;
/* Allocate the next block */
- int nr = ext2_alloc_block(inode, parent, &err);
+ unsigned long nr = ext2_alloc_block(inode, parent, &err);
if (!nr)
break;
branch[n].key = cpu_to_le32(nr);
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 imposed for the sake of usability.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
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
> needs to be some limits imposed for the sake of usability.
I figure this is in the fine tradition of "enough rope to hang oneself"
If you have 16T of filesystem you probably know enough to not hang
yourself this way.
*shrug*
It's a bug, today. If we need another change to limit ext2 to 500G or
something, fine by me. :)
-Eric
On Fri, 2007-04-20 at 18:14 -0500, Eric Sandeen wrote:
> 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
> > needs to be some limits imposed for the sake of usability.
>
> I figure this is in the fine tradition of "enough rope to hang oneself"
>
> If you have 16T of filesystem you probably know enough to not hang
> yourself this way.
>
> *shrug*
>
> 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()). Maybe need
a round of thorough review to see if anything left, but I think what in
mm tree looks good.
And those patches in mm tree also backports the ext3 best-effort
allocates multiple blocks code (allocate multiple blocks within the
block reservation window as much as possible), FYI.
Mingming
> If we need another change to limit ext2 to 500G or
> something, fine by me. :)
>
> -Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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()). Maybe need
> a round of thorough review to see if anything left, but I think what in
> mm tree looks good.
Oh... oops. I didn't think to check mm, didn't expect to find those
changes on ext2. Ok, I will double-check that against what I did.
> And those patches in mm tree also backports the ext3 best-effort
> allocates multiple blocks code (allocate multiple blocks within the
> block reservation window as much as possible), FYI.
Ok, thanks Mingming!
-Eric