* Fix device too big bug in mainline? @ 2009-07-30 21:53 Valerie Aurora 2009-08-02 0:28 ` Theodore Tso 0 siblings, 1 reply; 19+ messages in thread From: Valerie Aurora @ 2009-07-30 21:53 UTC (permalink / raw) To: linux-ext4; +Cc: Theodore Tso, Eric Sandeen Hi all, Currently, e2fsprogs will fail to create a file system if the underlying device is "too big" - even if we specify a number of blocks to use that is in range: https://bugzilla.redhat.com/show_bug.cgi?id=485236 This is fixed in the current pu branch, but more as a side effect of an enormous 64-bit rewrite. Ted, any plans to pull this into mainline? -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-07-30 21:53 Fix device too big bug in mainline? Valerie Aurora @ 2009-08-02 0:28 ` Theodore Tso 2009-08-02 2:22 ` Theodore Tso 2009-08-03 18:04 ` Valerie Aurora 0 siblings, 2 replies; 19+ messages in thread From: Theodore Tso @ 2009-08-02 0:28 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-ext4, Eric Sandeen On Thu, Jul 30, 2009 at 05:53:02PM -0400, Valerie Aurora wrote: > Hi all, > > Currently, e2fsprogs will fail to create a file system if the > underlying device is "too big" - even if we specify a number of blocks > to use that is in range: > > https://bugzilla.redhat.com/show_bug.cgi?id=485236 > > This is fixed in the current pu branch, but more as a side effect of > an enormous 64-bit rewrite. > > Ted, any plans to pull this into mainline? We have a special case as of v1.41.4 so that if someone creates a 16TB partition, we'll treat it as having 16TB - 1 minus blocks. Yes, I'm working on merging the 64-bit patches into mainline; and so far we have about 25% or so of the patches merged into the master branch. It's been somewhat slow going, since I've many other things on my plate, and because I've wanted to do a lot of QA while doing the merge. I've found more than a few bugs simply by doing code inspection while merging the patches one at a time. How much do we care about this specific bug as something that needs to be fixed ASAP? We already have something for a 16TB logical volume, since that is what is most likely to be created with lvcreate. But do we consider it a common case where someone creates a 32TB logical volume, but intends to create a 16TB (minus 1 block) filesystem, that needs to be urgently fixed? - Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-02 0:28 ` Theodore Tso @ 2009-08-02 2:22 ` Theodore Tso 2009-08-02 3:49 ` Theodore Tso ` (3 more replies) 2009-08-03 18:04 ` Valerie Aurora 1 sibling, 4 replies; 19+ messages in thread From: Theodore Tso @ 2009-08-02 2:22 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler In case people are wondering why it's taking so long to merge the 64-bit patch series, let me show one patch as exhibit 'A' about how not to submit patches to me (or Linus, or any other upstream maintainer): Note the lack of an adequate patch description. Also note how this patch mushes together 2 or 3 semantic changes into a single patch, making it extremely difficult to audit. Even worse are the patches where what should be a single semantic change is spread out across multiple patches. This is why I can't just merge the 64-bit patch series blindly; I'd have no idea whether or not the result would be good or not because it's near-impossible to audit. What I have been doing is gradually extracting out bits and pieces, combining patches where necessary, separate patches where appropriately, and then gradually merging patches into the mainline. But it's slow work that requires meticulous checking, both in terms of checking to make sure the tree builds after each patch and passes "make check", as well as making sure I don't drop anything. In addition, more than once I've found places where not all of the places that needed converting to some new interfaces, such as ext2fs_blocks_count() had been done. Maybe no one had noticed, but I'd prefer to catch such problems at merge-time, not when a user complains about their filesystem getting corrupted and files a bug in Red Hat's or SLES's bugzilla.... I also would greatly prefer it if people who submit patches to me obey basic patch and code formatting guidelines. Things like this are really uncool: - fs->group_desc[i].bg_free_blocks_count = - free_array[i]; + ext2fs_bg_free_blocks_count_set(fs, i, free_array[i]) + ; Please try to keep code lines wrapped at 72-76 characters, and ixnay on a single semicolon or one or two close parathesis on a line with nothing else. Clean patches get merged more quickly; dirty patches that don't get cleaned up mean that either I have to try to ask the original patch submitter to clean them up (and I thought I had made it clear to Val what my expectations were in terms of clean patches), or I have to find the time to clean them up myself. In my experience, cleaning this up *now* will end up costing us less time than trying to find bugs in the merged code later. - Ted temporary checkin; about to do checksum conversion From: Valerie Aurora Henson <vaurora@redhat.com> Signed-off-by: Valerie Aurora Henson <vaurora@redhat.com> --- debugfs/debugfs.c | 38 +++++++++++++++++++----------------- e2fsck/journal.c | 2 +- e2fsck/pass5.c | 12 +++++----- e2fsck/super.c | 47 ++++++++++++++++++++++----------------------- lib/ext2fs/alloc_stats.c | 15 ++++++------- lib/ext2fs/alloc_tables.c | 6 ++-- lib/ext2fs/closefs.c | 12 ++++++---- lib/ext2fs/csum.c | 2 +- lib/ext2fs/ext2fs.h | 2 +- lib/ext2fs/initialize.c | 16 +++++++------- lib/ext2fs/openfs.c | 2 +- lib/ext2fs/swapfs.c | 14 ++++++++++++- misc/mke2fs.c | 2 +- misc/tune2fs.c | 10 ++++---- resize/resize2fs.c | 26 ++++++++++++------------ 15 files changed, 110 insertions(+), 96 deletions(-) diff --git a/debugfs/debugfs.c b/debugfs/debugfs.c index 63b9a44..befbb5b 100644 --- a/debugfs/debugfs.c +++ b/debugfs/debugfs.c @@ -307,7 +307,6 @@ void do_show_super_stats(int argc, char *argv[]) { dgrp_t i; FILE *out; - struct ext2_group_desc *gdp; int c, header_only = 0; int numdirs = 0, first, gdt_csum; @@ -340,27 +339,30 @@ void do_show_super_stats(int argc, char *argv[]) gdt_csum = EXT2_HAS_RO_COMPAT_FEATURE(current_fs->super, EXT4_FEATURE_RO_COMPAT_GDT_CSUM); - gdp = ¤t_fs->group_desc[0]; - for (i = 0; i < current_fs->group_desc_count; i++, gdp++) { - fprintf(out, " Group %2d: block bitmap at %u, " - "inode bitmap at %u, " - "inode table at %u\n" + for (i = 0; i < current_fs->group_desc_count; i++) { + fprintf(out, " Group %2d: block bitmap at %llu, " + "inode bitmap at %llu, " + "inode table at %llu\n" " %d free %s, " "%d free %s, " "%d used %s%s", - i, gdp->bg_block_bitmap, - gdp->bg_inode_bitmap, gdp->bg_inode_table, - gdp->bg_free_blocks_count, - gdp->bg_free_blocks_count != 1 ? "blocks" : "block", - gdp->bg_free_inodes_count, - gdp->bg_free_inodes_count != 1 ? "inodes" : "inode", - gdp->bg_used_dirs_count, - gdp->bg_used_dirs_count != 1 ? "directories" - : "directory", gdt_csum ? ", " : "\n"); + i, ext2fs_block_bitmap_loc(current_fs, i), + ext2fs_inode_bitmap_loc(current_fs, i), + ext2fs_inode_table_loc(current_fs, i), + ext2fs_bg_free_blocks_count(current_fs, i), + ext2fs_bg_free_blocks_count(current_fs, i) != 1 ? + "blocks" : "block", + ext2fs_bg_free_inodes_count(current_fs, i), + ext2fs_bg_free_inodes_count(current_fs, i) != 1 ? + "inodes" : "inode", + ext2fs_bg_used_dirs_count(current_fs, i), + ext2fs_bg_used_dirs_count(current_fs, i) != 1 ? "directories" + : "directory", gdt_csum ? ", " : "\n"); if (gdt_csum) fprintf(out, "%d unused %s\n", - gdp->bg_itable_unused, - gdp->bg_itable_unused != 1 ? "inodes":"inode"); + ext2fs_bg_itable_unused(current_fs, i), + ext2fs_bg_itable_unused(current_fs, i) != 1 ? + "inodes" : "inode"); first = 1; print_bg_opts(current_fs, i, EXT2_BG_INODE_UNINIT, "Inode not init", &first, out); @@ -368,7 +370,7 @@ void do_show_super_stats(int argc, char *argv[]) &first, out); if (gdt_csum) { fprintf(out, "%sChecksum 0x%04x", - first ? " [":", ", gdp->bg_checksum); + first ? " [":", ", ext2fs_bg_checksum(current_fs, i)); first = 0; } if (!first) diff --git a/e2fsck/journal.c b/e2fsck/journal.c index dd56e7a..f5fdef5 100644 --- a/e2fsck/journal.c +++ b/e2fsck/journal.c @@ -1011,7 +1011,7 @@ void e2fsck_move_ext3_journal(e2fsck_t ctx) group = ext2fs_group_of_ino(fs, ino); ext2fs_unmark_inode_bitmap2(fs->inode_map, ino); ext2fs_mark_ib_dirty(fs); - fs->group_desc[group].bg_free_inodes_count++; + ext2fs_bg_free_inodes_count_set(fs, group, ext2fs_bg_free_inodes_count(fs, group) + 1); ext2fs_group_desc_csum_set(fs, group); fs->super->s_free_inodes_count++; return; diff --git a/e2fsck/pass5.c b/e2fsck/pass5.c index 6cdbd6b..9ac4324 100644 --- a/e2fsck/pass5.c +++ b/e2fsck/pass5.c @@ -343,8 +343,8 @@ redo_counts: if (fix_problem(ctx, PR_5_FREE_BLOCK_COUNT_GROUP, &pctx)) { - fs->group_desc[i].bg_free_blocks_count = - free_array[i]; + ext2fs_bg_free_blocks_count_set(fs, i, free_array[i]) + ; ext2fs_mark_super_dirty(fs); } else ext2fs_unmark_valid(fs); @@ -573,8 +573,8 @@ do_counts: pctx.ino2 = free_array[i]; if (fix_problem(ctx, PR_5_FREE_INODE_COUNT_GROUP, &pctx)) { - fs->group_desc[i].bg_free_inodes_count = - free_array[i]; + ext2fs_bg_free_inodes_count_set(fs, i, free_array[i]) + ; ext2fs_mark_super_dirty(fs); } else ext2fs_unmark_valid(fs); @@ -586,8 +586,8 @@ do_counts: if (fix_problem(ctx, PR_5_FREE_DIR_COUNT_GROUP, &pctx)) { - fs->group_desc[i].bg_used_dirs_count = - dir_array[i]; + ext2fs_bg_used_dirs_count_set(fs, i, dir_array[i]) + ; ext2fs_mark_super_dirty(fs); } else ext2fs_unmark_valid(fs); diff --git a/e2fsck/super.c b/e2fsck/super.c index c269b0e..a1fb878 100644 --- a/e2fsck/super.c +++ b/e2fsck/super.c @@ -458,7 +458,6 @@ void check_super_block(e2fsck_t ctx) ext2_filsys fs = ctx->fs; blk64_t first_block, last_block; struct ext2_super_block *sb = fs->super; - struct ext2_group_desc *gd; problem_t problem; blk64_t blocks_per_group = fs->super->s_blocks_per_group; __u32 bpg_max; @@ -587,7 +586,7 @@ void check_super_block(e2fsck_t ctx) csum_flag = EXT2_HAS_RO_COMPAT_FEATURE(fs->super, EXT4_FEATURE_RO_COMPAT_GDT_CSUM); - for (i = 0, gd=fs->group_desc; i < fs->group_desc_count; i++, gd++) { + for (i = 0; i < fs->group_desc_count; i++) { pctx.group = i; if (!EXT2_HAS_INCOMPAT_FEATURE(fs->super, @@ -627,61 +626,61 @@ void check_super_block(e2fsck_t ctx) ctx->invalid_inode_table_flag[i]++; ctx->invalid_bitmaps++; } - free_blocks += gd->bg_free_blocks_count; - free_inodes += gd->bg_free_inodes_count; + free_blocks += ext2fs_bg_free_blocks_count(fs, i); + free_inodes += ext2fs_bg_free_inodes_count(fs, i); - if ((gd->bg_free_blocks_count > sb->s_blocks_per_group) || - (gd->bg_free_inodes_count > sb->s_inodes_per_group) || - (gd->bg_used_dirs_count > sb->s_inodes_per_group)) + if ((ext2fs_bg_free_blocks_count(fs, i) > sb->s_blocks_per_group) || + (ext2fs_bg_free_inodes_count(fs, i) > sb->s_inodes_per_group) || + (ext2fs_bg_used_dirs_count(fs, i) > sb->s_inodes_per_group)) ext2fs_unmark_valid(fs); should_be = 0; if (!ext2fs_group_desc_csum_verify(fs, i)) { if (fix_problem(ctx, PR_0_GDT_CSUM, &pctx)) { - gd->bg_flags &= ~(EXT2_BG_BLOCK_UNINIT | - EXT2_BG_INODE_UNINIT); - gd->bg_itable_unused = 0; + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT); + ext2fs_bg_itable_unused_set(fs, i, 0); should_be = 1; } ext2fs_unmark_valid(fs); } if (!csum_flag && - (gd->bg_flags &(EXT2_BG_BLOCK_UNINIT|EXT2_BG_INODE_UNINIT)|| - gd->bg_itable_unused != 0)){ + (ext2fs_bg_flag_test(fs, i, EXT2_BG_BLOCK_UNINIT) || + ext2fs_bg_flag_test(fs, i, EXT2_BG_INODE_UNINIT) || + ext2fs_bg_itable_unused(fs, i) != 0)){ if (fix_problem(ctx, PR_0_GDT_UNINIT, &pctx)) { - gd->bg_flags &= ~(EXT2_BG_BLOCK_UNINIT | - EXT2_BG_INODE_UNINIT); - gd->bg_itable_unused = 0; + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT); should_be = 1; } ext2fs_unmark_valid(fs); } if (i == fs->group_desc_count - 1 && - gd->bg_flags & EXT2_BG_BLOCK_UNINIT) { + ext2fs_bg_flag_test(fs, i, EXT2_BG_BLOCK_UNINIT)) { if (fix_problem(ctx, PR_0_BB_UNINIT_LAST, &pctx)) { - gd->bg_flags &= ~EXT2_BG_BLOCK_UNINIT; + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); should_be = 1; } ext2fs_unmark_valid(fs); } - if (gd->bg_flags & EXT2_BG_BLOCK_UNINIT && - !(gd->bg_flags & EXT2_BG_INODE_UNINIT)) { + if (ext2fs_bg_flag_test(fs, i, EXT2_BG_BLOCK_UNINIT) && + !ext2fs_bg_flag_test(fs, i, EXT2_BG_INODE_UNINIT)) { if (fix_problem(ctx, PR_0_BB_UNINIT_IB_INIT, &pctx)) { - gd->bg_flags &= ~EXT2_BG_BLOCK_UNINIT; + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); should_be = 1; } ext2fs_unmark_valid(fs); } if (csum_flag && - (gd->bg_itable_unused > gd->bg_free_inodes_count || - gd->bg_itable_unused > sb->s_inodes_per_group)) { - pctx.blk = gd->bg_itable_unused; + (ext2fs_bg_itable_unused(fs, i) > ext2fs_bg_free_inodes_count(fs, i) || + ext2fs_bg_itable_unused(fs, i) > sb->s_inodes_per_group)) { + pctx.blk = ext2fs_bg_itable_unused(fs, i); if (fix_problem(ctx, PR_0_GDT_ITABLE_UNUSED, &pctx)) { - gd->bg_itable_unused = 0; + ext2fs_bg_itable_unused_set(fs, i, 0); should_be = 1; } ext2fs_unmark_valid(fs); diff --git a/lib/ext2fs/alloc_stats.c b/lib/ext2fs/alloc_stats.c index d254998..5423c30 100644 --- a/lib/ext2fs/alloc_stats.c +++ b/lib/ext2fs/alloc_stats.c @@ -31,13 +31,13 @@ void ext2fs_inode_alloc_stats2(ext2_filsys fs, ext2_ino_t ino, ext2fs_mark_inode_bitmap2(fs->inode_map, ino); else ext2fs_unmark_inode_bitmap2(fs->inode_map, ino); - fs->group_desc[group].bg_free_inodes_count -= inuse; + ext2fs_bg_free_inodes_count_set(fs, group, ext2fs_bg_free_inodes_count(fs, group) - inuse); if (isdir) - fs->group_desc[group].bg_used_dirs_count += inuse; + ext2fs_bg_used_dirs_count_set(fs, group, ext2fs_bg_used_dirs_count(fs, group) + inuse); /* We don't strictly need to be clearing the uninit flag if inuse < 0 * (i.e. freeing inodes) but it also means something is bad. */ - fs->group_desc[group].bg_flags &= ~EXT2_BG_INODE_UNINIT; + ext2fs_bg_flag_clear(fs, group, EXT2_BG_INODE_UNINIT); if (EXT2_HAS_RO_COMPAT_FEATURE(fs->super, EXT4_FEATURE_RO_COMPAT_GDT_CSUM)) { ext2_ino_t first_unused_inode = fs->super->s_inodes_per_group - @@ -45,9 +45,8 @@ void ext2fs_inode_alloc_stats2(ext2_filsys fs, ext2_ino_t ino, group * fs->super->s_inodes_per_group + 1; if (ino >= first_unused_inode) - fs->group_desc[group].bg_itable_unused = - group * fs->super->s_inodes_per_group + - fs->super->s_inodes_per_group - ino; + ext2fs_bg_itable_unused_set(fs, group, group * fs->super->s_inodes_per_group + fs->super->s_inodes_per_group - ino) + ; ext2fs_group_desc_csum_set(fs, group); } @@ -76,8 +75,8 @@ void ext2fs_block_alloc_stats2(ext2_filsys fs, blk64_t blk, int inuse) ext2fs_mark_block_bitmap2(fs->block_map, blk); else ext2fs_unmark_block_bitmap2(fs->block_map, blk); - fs->group_desc[group].bg_free_blocks_count -= inuse; - fs->group_desc[group].bg_flags &= ~EXT2_BG_BLOCK_UNINIT; + ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group) - inuse); + ext2fs_bg_flag_clear(fs, group, EXT2_BG_BLOCK_UNINIT); ext2fs_group_desc_csum_set(fs, group); ext2fs_free_blocks_count_add(fs->super, -inuse); diff --git a/lib/ext2fs/alloc_tables.c b/lib/ext2fs/alloc_tables.c index b218e7f..2f691ac 100644 --- a/lib/ext2fs/alloc_tables.c +++ b/lib/ext2fs/alloc_tables.c @@ -141,7 +141,7 @@ errcode_t ext2fs_allocate_group_table(ext2_filsys fs, dgrp_t group, ext2fs_block_bitmap_loc_set(fs, group, new_blk); if (flexbg_size) { dgrp_t gr = ext2fs_group_of_blk2(fs, new_blk); - fs->group_desc[gr].bg_free_blocks_count--; + ext2fs_bg_free_blocks_count_set(fs, gr, ext2fs_bg_free_blocks_count(fs, gr) - 1); ext2fs_free_blocks_count_add(fs->super, -1); ext2fs_bg_flag_clear(fs, gr, EXT2_BG_BLOCK_UNINIT); ext2fs_group_desc_csum_set(fs, gr); @@ -169,7 +169,7 @@ errcode_t ext2fs_allocate_group_table(ext2_filsys fs, dgrp_t group, ext2fs_inode_bitmap_loc_set(fs, group, new_blk); if (flexbg_size) { dgrp_t gr = ext2fs_group_of_blk2(fs, new_blk); - fs->group_desc[gr].bg_free_blocks_count--; + ext2fs_bg_free_blocks_count_set(fs, gr, ext2fs_bg_free_blocks_count(fs, gr) - 1); ext2fs_free_blocks_count_add(fs->super, -1); ext2fs_bg_flag_clear(fs, gr, EXT2_BG_BLOCK_UNINIT); ext2fs_group_desc_csum_set(fs, gr); @@ -203,7 +203,7 @@ errcode_t ext2fs_allocate_group_table(ext2_filsys fs, dgrp_t group, ext2fs_mark_block_bitmap2(bmap, blk); if (flexbg_size) { dgrp_t gr = ext2fs_group_of_blk2(fs, blk); - fs->group_desc[gr].bg_free_blocks_count--; + ext2fs_bg_free_blocks_count_set(fs, gr, ext2fs_bg_free_blocks_count(fs, gr) - 1); ext2fs_free_blocks_count_add(fs->super, -1); ext2fs_bg_flag_clear(fs, gr, EXT2_BG_BLOCK_UNINIT); ext2fs_group_desc_csum_set(fs, gr); diff --git a/lib/ext2fs/closefs.c b/lib/ext2fs/closefs.c index dd24856..e2523c3 100644 --- a/lib/ext2fs/closefs.c +++ b/lib/ext2fs/closefs.c @@ -270,7 +270,7 @@ errcode_t ext2fs_flush_with_progress(ext2_filsys fs, const char *message) struct ext2_super_block *super_shadow = 0; struct ext2_group_desc *group_shadow = 0; #ifdef WORDS_BIGENDIAN - struct ext2_group_desc *s, *t; + char *s, *t; dgrp_t j; #endif char *group_ptr; @@ -297,10 +297,12 @@ errcode_t ext2fs_flush_with_progress(ext2_filsys fs, const char *message) fs->desc_blocks); /* swap the group descriptors */ - for (j=0, s=fs->group_desc, t=group_shadow; - j < fs->group_desc_count; j++, t++, s++) { - *t = *s; - ext2fs_swap_group_desc(t); + t = group_shadow; + for (j=0; j < fs->group_desc_count; j++) { + s = (char *) ext2fs_group_desc(fs, j); + memcpy(t, s, fs->group_desc_size); + ext2fs_swap_group_desc(fs, t); + t += fs->group_desc_size; } #else super_shadow = fs->super; diff --git a/lib/ext2fs/csum.c b/lib/ext2fs/csum.c index 7c79397..5612de1 100644 --- a/lib/ext2fs/csum.c +++ b/lib/ext2fs/csum.c @@ -43,7 +43,7 @@ STATIC __u16 ext2fs_group_desc_csum(ext2_filsys fs, dgrp_t group) struct ext2_group_desc swabdesc = *desc; /* Have to swab back to little-endian to do the checksum */ - ext2fs_swap_group_desc(&swabdesc); + ext2fs_swap_group_desc(fs, &swabdesc); desc = &swabdesc; group = ext2fs_swab32(group); diff --git a/lib/ext2fs/ext2fs.h b/lib/ext2fs/ext2fs.h index 7c6a9d9..a4396a4 100644 --- a/lib/ext2fs/ext2fs.h +++ b/lib/ext2fs/ext2fs.h @@ -1279,7 +1279,7 @@ extern void ext2fs_swap_ext_attr_header(struct ext2_ext_attr_header *to_header, extern void ext2fs_swap_ext_attr_entry(struct ext2_ext_attr_entry *to_entry, struct ext2_ext_attr_entry *from_entry); extern void ext2fs_swap_super(struct ext2_super_block * super); -extern void ext2fs_swap_group_desc(struct ext2_group_desc *gdp); +extern void ext2fs_swap_group_desc(ext2_filsys, struct ext2_group_desc *gdp); extern void ext2fs_swap_inode_full(ext2_filsys fs, struct ext2_inode_large *t, struct ext2_inode_large *f, int hostorder, int bufsize); diff --git a/lib/ext2fs/initialize.c b/lib/ext2fs/initialize.c index 35d076a..c1b3ca9 100644 --- a/lib/ext2fs/initialize.c +++ b/lib/ext2fs/initialize.c @@ -413,13 +413,13 @@ ipg_retry: */ if (csum_flag) { if (i != fs->group_desc_count - 1) - fs->group_desc[i].bg_flags |= - EXT2_BG_BLOCK_UNINIT; - fs->group_desc[i].bg_flags |= EXT2_BG_INODE_UNINIT; + ext2fs_bg_flag_set(fs, i, EXT2_BG_BLOCK_UNINIT) + ; + ext2fs_bg_flag_set(fs, i, EXT2_BG_INODE_UNINIT); numblocks = super->s_inodes_per_group; if (i == 0) numblocks -= super->s_first_ino; - fs->group_desc[i].bg_itable_unused = numblocks; + ext2fs_bg_itable_unused_set(fs, i, numblocks); } numblocks = ext2fs_reserve_super_and_bgd(fs, i, fs->block_map); if (fs->super->s_log_groups_per_flex) @@ -428,10 +428,10 @@ ipg_retry: ext2fs_free_blocks_count_set(super, ext2fs_free_blocks_count(super) + numblocks); - fs->group_desc[i].bg_free_blocks_count = numblocks; - fs->group_desc[i].bg_free_inodes_count = - fs->super->s_inodes_per_group; - fs->group_desc[i].bg_used_dirs_count = 0; + ext2fs_bg_free_blocks_count_set(fs, i, numblocks); + ext2fs_bg_free_inodes_count_set(fs, i, fs->super->s_inodes_per_group) + ; + ext2fs_bg_used_dirs_count_set(fs, i, 0); ext2fs_group_desc_csum_set(fs, i); } diff --git a/lib/ext2fs/openfs.c b/lib/ext2fs/openfs.c index 5e49608..ddb3ede 100644 --- a/lib/ext2fs/openfs.c +++ b/lib/ext2fs/openfs.c @@ -334,7 +334,7 @@ errcode_t ext2fs_open2(const char *name, const char *io_options, #ifdef WORDS_BIGENDIAN gdp = (struct ext2_group_desc *) dest; for (j=0; j < groups_per_block; j++) - ext2fs_swap_group_desc(gdp++); + ext2fs_swap_group_desc(fs, gdp++); #endif dest += fs->blocksize; } diff --git a/lib/ext2fs/swapfs.c b/lib/ext2fs/swapfs.c index 42bc01e..25af281 100644 --- a/lib/ext2fs/swapfs.c +++ b/lib/ext2fs/swapfs.c @@ -78,8 +78,9 @@ void ext2fs_swap_super(struct ext2_super_block * sb) } -void ext2fs_swap_group_desc(struct ext2_group_desc *gdp) +void ext2fs_swap_group_desc(ext2_filsys fs, struct ext2_group_desc *gdp) { + // Do the 32-bit parts first gdp->bg_block_bitmap = ext2fs_swab32(gdp->bg_block_bitmap); gdp->bg_inode_bitmap = ext2fs_swab32(gdp->bg_inode_bitmap); gdp->bg_inode_table = ext2fs_swab32(gdp->bg_inode_table); @@ -89,6 +90,17 @@ void ext2fs_swap_group_desc(struct ext2_group_desc *gdp) gdp->bg_flags = ext2fs_swab16(gdp->bg_flags); gdp->bg_itable_unused = ext2fs_swab16(gdp->bg_itable_unused); gdp->bg_checksum = ext2fs_swab16(gdp->bg_checksum); + // Now do the 64-bit parts if we need 'em + if (fs->super->s_desc_size >= EXT2_MIN_DESC_SIZE_64BIT) { + struct ext4_group_desc *gdp4 = (struct ext4_group_desc *) gdp; + gdp4->bg_block_bitmap_hi = ext2fs_swab32(gdp4->bg_block_bitmap_hi); + gdp4->bg_inode_bitmap_hi = ext2fs_swab32(gdp4->bg_inode_bitmap_hi); + gdp4->bg_inode_table_hi = ext2fs_swab32(gdp4->bg_inode_table_hi); + gdp4->bg_free_blocks_count_hi = ext2fs_swab16(gdp4->bg_free_blocks_count_hi); + gdp4->bg_free_inodes_count_hi = ext2fs_swab16(gdp4->bg_free_inodes_count_hi); + gdp4->bg_used_dirs_count_hi = ext2fs_swab16(gdp4->bg_used_dirs_count_hi); + gdp4->bg_itable_unused_hi = ext2fs_swab16(gdp4->bg_itable_unused_hi); + } } void ext2fs_swap_ext_attr_header(struct ext2_ext_attr_header *to_header, diff --git a/misc/mke2fs.c b/misc/mke2fs.c index 0cbfef3..9f311bd 100644 --- a/misc/mke2fs.c +++ b/misc/mke2fs.c @@ -273,7 +273,7 @@ _("Warning: the backup superblock/group descriptors at block %u contain\n" group_block); group_bad++; group = ext2fs_group_of_blk(fs, group_block+j); - fs->group_desc[group].bg_free_blocks_count++; + ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group) + 1); ext2fs_group_desc_csum_set(fs, group); ext2fs_free_blocks_count_add(fs->super, 1); } diff --git a/misc/tune2fs.c b/misc/tune2fs.c index 24d03d9..de1b2fd 100644 --- a/misc/tune2fs.c +++ b/misc/tune2fs.c @@ -261,7 +261,7 @@ static int release_blocks_proc(ext2_filsys fs, blk_t *blocknr, block = *blocknr; ext2fs_unmark_block_bitmap(fs->block_map, block); group = ext2fs_group_of_blk(fs, block); - fs->group_desc[group].bg_free_blocks_count++; + ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group) + 1); ext2fs_group_desc_csum_set(fs, group); ext2fs_free_blocks_count_add(fs->super, 1); return 0; @@ -1311,8 +1311,8 @@ static errcode_t ext2fs_calculate_summary_stats(ext2_filsys fs) count++; if ((count == fs->super->s_blocks_per_group) || (blk == ext2fs_blocks_count(fs->super)-1)) { - fs->group_desc[group++].bg_free_blocks_count = - group_free; + ext2fs_bg_free_blocks_count_set(fs, group++, group_free) + ; count = 0; group_free = 0; } @@ -1336,8 +1336,8 @@ static errcode_t ext2fs_calculate_summary_stats(ext2_filsys fs) count++; if ((count == fs->super->s_inodes_per_group) || (ino == fs->super->s_inodes_count)) { - fs->group_desc[group++].bg_free_inodes_count = - group_free; + ext2fs_bg_free_inodes_count_set(fs, group++, group_free) + ; count = 0; group_free = 0; } diff --git a/resize/resize2fs.c b/resize/resize2fs.c index 3e2712a..1e84a62 100644 --- a/resize/resize2fs.c +++ b/resize/resize2fs.c @@ -465,7 +465,7 @@ retry: } else numblocks = fs->super->s_blocks_per_group; i = old_fs->group_desc_count - 1; - fs->group_desc[i].bg_free_blocks_count += (numblocks-old_numblocks); + ext2fs_bg_free_blocks_count_set(fs, i, ext2fs_bg_free_blocks_count(fs, i) + (numblocks - old_numblocks)); ext2fs_group_desc_csum_set(fs, i); /* @@ -549,10 +549,10 @@ retry: ext2fs_free_blocks_count(fs->super) - adjblocks); fs->super->s_free_inodes_count += fs->super->s_inodes_per_group; - fs->group_desc[i].bg_free_blocks_count = numblocks; - fs->group_desc[i].bg_free_inodes_count = - fs->super->s_inodes_per_group; - fs->group_desc[i].bg_used_dirs_count = 0; + ext2fs_bg_free_blocks_count_set(fs, i, numblocks); + ext2fs_bg_free_inodes_count_set(fs, i, fs->super->s_inodes_per_group) + ; + ext2fs_bg_used_dirs_count_set(fs, i, 0); ext2fs_group_desc_csum_set(fs, i); retval = ext2fs_allocate_group_table(fs, i, 0); @@ -1828,14 +1828,14 @@ static errcode_t ext2fs_calculate_summary_stats(ext2_filsys fs) count++; if ((count == fs->super->s_blocks_per_group) || (blk == ext2fs_blocks_count(fs->super)-1)) { - fs->group_desc[group].bg_free_blocks_count = - group_free; + ext2fs_bg_free_blocks_count_set(fs, group, group_free) + ; ext2fs_group_desc_csum_set(fs, group); group++; count = 0; group_free = 0; - uninit = (fs->group_desc[group].bg_flags & - EXT2_BG_BLOCK_UNINIT); + uninit = (ext2fs_bg_flag_test(fs, group, EXT2_BG_BLOCK_UNINIT) + ); ext2fs_super_and_bgd_loc(fs, group, &super_blk, &old_desc_blk, &new_desc_blk, 0); @@ -1868,14 +1868,14 @@ static errcode_t ext2fs_calculate_summary_stats(ext2_filsys fs) count++; if ((count == fs->super->s_inodes_per_group) || (ino == fs->super->s_inodes_count)) { - fs->group_desc[group].bg_free_inodes_count = - group_free; + ext2fs_bg_free_inodes_count_set(fs, group, group_free) + ; ext2fs_group_desc_csum_set(fs, group); group++; count = 0; group_free = 0; - uninit = (fs->group_desc[group].bg_flags & - EXT2_BG_INODE_UNINIT); + uninit = (ext2fs_bg_flag_test(fs, group, EXT2_BG_INODE_UNINIT) + ); } } fs->super->s_free_inodes_count = total_free; ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-02 2:22 ` Theodore Tso @ 2009-08-02 3:49 ` Theodore Tso 2009-08-03 20:11 ` Valerie Aurora ` (2 subsequent siblings) 3 siblings, 0 replies; 19+ messages in thread From: Theodore Tso @ 2009-08-02 3:49 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > temporary checkin; about to do checksum conversion > > From: Valerie Aurora Henson <vaurora@redhat.com> > > Signed-off-by: Valerie Aurora Henson <vaurora@redhat.com> BTW, while I was painstakingly picking apart this patch, separating it into its constiuent pieces, I found the following bug in it: diff --git a/e2fsck/super.c b/e2fsck/super.c index c269b0e..a1fb878 100644 --- a/e2fsck/super.c +++ b/e2fsck/super.c .... if (fix_problem(ctx, PR_0_GDT_UNINIT, &pctx)) { - gd->bg_flags &= ~(EXT2_BG_BLOCK_UNINIT | - EXT2_BG_INODE_UNINIT); - gd->bg_itable_unused = 0; + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT); should_be = 1; } This patch hunk (buried deep within the 800+ lines of the "temporary checkin; about to do checksum conversion" patch) removed this line: gd->bg_itable_unused = 0; ... but failed to replace it with this line: ext2fs_bg_itable_unused_set(fs, i, 0); This is *why* I insist on auditable patches, and why I can't just blindly merge the 64-bit branch. When multiple semantic changes are mushed up all together in one gigundo patch, it's really easy to miss omissions like this, and since we don't have a regression test to test this specific repair, we would have never noticed. And no, it's no fun for me to be picking through this patch set at on a Saturday evening on a Summer evening; I'd rather be in Lenox, enjoying a concert at Tanglewood. But someone has got to do it... - Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-02 2:22 ` Theodore Tso 2009-08-02 3:49 ` Theodore Tso @ 2009-08-03 20:11 ` Valerie Aurora 2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora 2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora 3 siblings, 0 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-03 20:11 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > In case people are wondering why it's taking so long to merge the > 64-bit patch series, let me show one patch as exhibit 'A' about how > not to submit patches to me (or Linus, or any other upstream > maintainer): I apologize for the misunderstanding! These patches have (clearly) never been reviewed and were not intended for merging into mainline without a thorough reorganization. It's simply unfortunate that we are all busy and no one has had time to review them in the last several months. I am very grateful you have time to review them now! The main difficulty with the 64-bit patch set is choosing patch boundaries and granularity. I'll try to summarize the issues I ran into as briefly as possible. The straightforward approach goes like so: 1. Add 64-bit version function foo2() (foo() is the 32-bit) (make check should pass here) 2. Convert all instances of foo() to foo2() (make check should pass here) 3. Repeat for bar(), baz(), etc. In the ideal world, every patch would represent a single semantic change, and every patch would result in a correct, compilable, testable code change. Two major problems with this scheme arise in the e2fsprogs code base: 1. The foo2() and bar() interfaces are incompatible, requiring a non-trivial amount of glue code to convert between the output of foo2() and the input of bar() and vice versa. By "non-trivial" I mean that the number of lines of glue code may exceed the number of lines of code of the foo() -> foo2() transition itself. 2. While the code passes "make check" on 32-bit test cases at each patch boundary, we can't check correctness of the 64-bit case until the transition is complete for each testable binary unit. Thus, we currently have to rely on code inspection alone to track down bugs that only affect the 64-bit case. For example, Jose's first 64-bit patch was posted around March 2008; it was not (and could not be) tested above 32 bits until I ran the first 64-bit mke2fs sometime in the fall of 2008. The result is that the straightforward approach requires a great deal more effort than usual to convert a semantic patch boundary to a "make check" boundary. Someone who knows the e2fsprogs code base very well (such as yourself) might be able to write the necessary glue code fairly swiftly and with few bugs. However, every other developer in the world (including myself) might spend as much time writing and debugging glue code as the original patches themselves - only to find that they chose the wrong patch boundary and must throw away that code. Hence, my decision to wait for your review and comments before even the most trivial reorganization of the patch set. I apologize if I chose wrongly! Some notes on improving 64-bit debugging at patch boundaries: Currently, the "make check" test suite doesn't include any infrastructure for 64-bit test devices. This is particularly painful to implement because many file systems (including ext4) don't support files with > 2^32 blocks. During development, I hacked together a test system using loop devices backed by sparse files on an XFS file system - clearly not a long-term solution. Eric has suggested using md to build 64-bit devices out of multiple 32-bit files backing loop devices. Some 64-bit tests require 64-bit userland and take many gigabytes of memory (I had to get another 4GB to bring my test machine up to 8GB before I could test > 2^32 block file systems). Compressed bitmap support would certainly help. Overall, creating a 64-bit test infrastructure is a significant project and should definitely get your input before going forward. Thanks for your time, -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-02 2:22 ` Theodore Tso 2009-08-02 3:49 ` Theodore Tso 2009-08-03 20:11 ` Valerie Aurora @ 2009-08-03 20:27 ` Valerie Aurora 2009-08-03 22:56 ` Valerie Aurora ` (2 more replies) 2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora 3 siblings, 3 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-03 20:27 UTC (permalink / raw) To: Theodore Tso, Julia Lawall; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > > I also would greatly prefer it if people who submit patches to me obey > basic patch and code formatting guidelines. Things like this are > really uncool: > > - fs->group_desc[i].bg_free_blocks_count = > - free_array[i]; > + ext2fs_bg_free_blocks_count_set(fs, i, free_array[i]) > + ; Ah, that's left over from an spatch bug that Julia Lawall (cc'd) kindly fixed immediately after I reported it. It won't happen if you use the current spatch. My apologies for missing this one during review! I think spatch could probably also wrap lines automatically when making semantic patches - Julia? I'm curious what you think of this proposal: Redo all the foo() -> foo2() patches in the entire 64-bit series as a semantic patches. This would also fix this kind of cut and paste bug: + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT); I fixed several of these in the existing 64-bit code when I took it over, so I assume more lurk undiscovered and would be revealed if we redid them with spatch. Julia, would you and/or your students be interested in helping? I think you're running out of bugs in the kernel and e2fsprogs would be another excellent showcase for spatch/Coccinelle. :) -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora @ 2009-08-03 22:56 ` Valerie Aurora 2009-08-04 6:40 ` Julia Lawall 2009-08-04 14:48 ` Theodore Tso 2 siblings, 0 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-03 22:56 UTC (permalink / raw) To: Theodore Tso, Julia Lawall; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Mon, Aug 03, 2009 at 04:27:40PM -0400, Valerie Aurora wrote: > On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > > > > I also would greatly prefer it if people who submit patches to me obey > > basic patch and code formatting guidelines. Things like this are > > really uncool: > > > > - fs->group_desc[i].bg_free_blocks_count = > > - free_array[i]; > > + ext2fs_bg_free_blocks_count_set(fs, i, free_array[i]) > > + ; > > Ah, that's left over from an spatch bug that Julia Lawall (cc'd) > kindly fixed immediately after I reported it. It won't happen if you > use the current spatch. My apologies for missing this one during > review! > > I think spatch could probably also wrap lines automatically when > making semantic patches - Julia? > > I'm curious what you think of this proposal: Redo all the foo() -> > foo2() patches in the entire 64-bit series as a semantic patches. > This would also fix this kind of cut and paste bug: > > + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); > + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT); > > I fixed several of these in the existing 64-bit code when I took it > over, so I assume more lurk undiscovered and would be revealed if we > redid them with spatch. > > Julia, would you and/or your students be interested in helping? I > think you're running out of bugs in the kernel and e2fsprogs would be > another excellent showcase for spatch/Coccinelle. :) I just remembered another reason to convert to spatch: For various reasons, I ignored several parts of e2fsprogs while doing the 64-bit conversion. Some of those should remain unconverted (dead code or 32-bit only code) but others should be converted. For example, I found some unconverted block group descriptor references in resize2fs last week - I remember having some reason for doing it at the time but I don't recall what it was now since it's been a few months. Sorry! -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora 2009-08-03 22:56 ` Valerie Aurora @ 2009-08-04 6:40 ` Julia Lawall 2009-08-04 14:48 ` Theodore Tso 2 siblings, 0 replies; 19+ messages in thread From: Julia Lawall @ 2009-08-04 6:40 UTC (permalink / raw) To: Valerie Aurora Cc: Theodore Tso, linux-ext4, Eric Sandeen, Ric Wheeler, Jesper Andersen On Mon, 3 Aug 2009, Valerie Aurora wrote: > On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > > > > I also would greatly prefer it if people who submit patches to me obey > > basic patch and code formatting guidelines. Things like this are > > really uncool: > > > > - fs->group_desc[i].bg_free_blocks_count = > > - free_array[i]; > > + ext2fs_bg_free_blocks_count_set(fs, i, free_array[i]) > > + ; > > Ah, that's left over from an spatch bug that Julia Lawall (cc'd) > kindly fixed immediately after I reported it. It won't happen if you > use the current spatch. My apologies for missing this one during > review! > > I think spatch could probably also wrap lines automatically when > making semantic patches - Julia? It doesn't now, but it is a good point that it probably could. The pretty printing works at the token level, and thus one knows the size of everything. I will look into it. > I'm curious what you think of this proposal: Redo all the foo() -> > foo2() patches in the entire 64-bit series as a semantic patches. > This would also fix this kind of cut and paste bug: > > + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT); > + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT); > > I fixed several of these in the existing 64-bit code when I took it > over, so I assume more lurk undiscovered and would be revealed if we > redid them with spatch. > > Julia, would you and/or your students be interested in helping? I > think you're running out of bugs in the kernel and e2fsprogs would be > another excellent showcase for spatch/Coccinelle. :) Actually, my PhD student Jesper (added to CC list) could generate semantic patches for such things automatically. Where can he find the normal patches? julia ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora 2009-08-03 22:56 ` Valerie Aurora 2009-08-04 6:40 ` Julia Lawall @ 2009-08-04 14:48 ` Theodore Tso 2009-08-04 18:18 ` Valerie Aurora 2 siblings, 1 reply; 19+ messages in thread From: Theodore Tso @ 2009-08-04 14:48 UTC (permalink / raw) To: Valerie Aurora; +Cc: Julia Lawall, linux-ext4, Eric Sandeen, Ric Wheeler On Mon, Aug 03, 2009 at 04:27:40PM -0400, Valerie Aurora wrote: > I'm curious what you think of this proposal: Redo all the foo() -> > foo2() patches in the entire 64-bit series as a semantic patches. Well, certainly assembling all of the 64-bit changes into a single patch is a good thing; I'm currently doing it by hand, by rearranging patches and transplanting patch hunks around. The reason why I hesitate about automating things is that when then have to follow up the patch with one that fixes up the types of various variables, and also printf format statements, etc. In addition, one challenge that has to be taken into account is that once we start making wholesale changes, we start breaking the rest of the patches in the patch queue. So there are probably some changes that we probably want to do by hand, and merge them into the tree first. This includes the bitmap changes (which I've simplified to the point where we don't need make the *_bitmap -> *_bitmap64 type changes any more), the filesystem swap code (which I think has an ABI change and I want to fix slightly differently), the 64-bit dblist code (which I want to look at more closely) and the progress meter code (which again I want to clean up their API first). So we probably need to merge some patches by hand before we get to the changes that can be done via spatch. Otherwise, if we start making redoing thesemantic patch changes right away, the concern is that we'll miss some of the more subtle changes that are contained within the patch series. If you want to start preparing for the semantic patches by preparing and testing the receipes, and then helping to flag those patches that contain some changes that contain some changes that can't be applied via spatch, that would be helpful. Does that sound like a plan? -Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-04 14:48 ` Theodore Tso @ 2009-08-04 18:18 ` Valerie Aurora 2009-08-04 19:24 ` Andreas Dilger 2009-08-04 20:32 ` Theodore Tso 0 siblings, 2 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-04 18:18 UTC (permalink / raw) To: Theodore Tso Cc: Julia Lawall, linux-ext4, Eric Sandeen, Ric Wheeler, Jesper Andersen [-- Attachment #1: Type: text/plain, Size: 1354 bytes --] On Tue, Aug 04, 2009 at 10:48:46AM -0400, Theodore Tso wrote: > > If you want to start preparing for the semantic patches by preparing > and testing the receipes, and then helping to flag those patches that > contain some changes that contain some changes that can't be applied > via spatch, that would be helpful. > > Does that sound like a plan? That sounds great. We won't be able to automate everything, but after this exercise, I bet spatch will be able to automate most of it. Jesper, the patches you'll be interested in can be found in the shared-64bit branch of: git://git.kernel.org/pub/scm/fs/ext2/val/e2fsprogs.git If getting these out of git is at any trouble at all, please ask and I'll send them as plain patches. The obvious candidates are things like: Author: Valerie Aurora Henson <vaurora@redhat.com> Date: Tue Feb 3 13:15:19 2009 -0800 parse_num_blocks() -> parse_num_blocks2() More difficult and interesting projects include: Author: Valerie Aurora Henson <vaurora@redhat.com> Date: Tue Feb 3 13:15:19 2009 -0800 New accessor functions for block group descriptor variables. And the following three patches. I attached a (huge) .cocci script that I used to do part of that conversion. I'm looking forward to your professional version of it. :) This is a good patch for testing newline fixup features. -VAL [-- Attachment #2: group_desc.cocci --] [-- Type: text/plain, Size: 5190 bytes --] // Checksum @@ ext2_filsys fs; expression group, flag; @@ -fs->group_desc[group].bg_checksum +ext2fs_bg_checksum(fs, group) // Get/set block/inode counts @@ ext2_filsys fs; expression group; identifier blk; expression E; @@ ( // Free blocks -blk = fs->group_desc[group].bg_free_blocks_count +blk = ext2fs_bg_free_blocks_count(fs, group) | -fs->group_desc[group].bg_free_blocks_count = E +ext2fs_bg_free_blocks_count_set(fs, group, E) | // Free inodes -blk = fs->group_desc[group].bg_free_inodes_count +blk = ext2fs_bg_free_inodes_count(fs, group) | -fs->group_desc[group].bg_free_inodes_count = E +ext2fs_bg_free_inodes_count_set(fs, group, E) | // Used dirs -blk = fs->group_desc[group].bg_used_dirs_count +blk = ext2fs_bg_used_dirs_count(fs, group) | -fs->group_desc[group].bg_used_dirs_count = E +ext2fs_bg_used_dirs_count_set(fs, group, E) | // Unused inode table blocks -blk = fs->group_desc[group].bg_itable_unused +blk = ext2fs_bg_itable_unused(fs, group) | -fs->group_desc[group].bg_itable_unused = E +ext2fs_bg_itable_unused_set(fs, group, E) ) // Increment/decrement block/inode counts // I tried to create an isomorphism for this, but I failed. @@ ext2_filsys fs; expression group, i; @@ ( // Free blocks -fs->group_desc[group].bg_free_blocks_count++ +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)+1) | -fs->group_desc[group].bg_free_blocks_count-- +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)-1) | -fs->group_desc[group].bg_free_blocks_count += i +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)+i) | -fs->group_desc[group].bg_free_blocks_count -= i +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)-i) | // Free inodes -fs->group_desc[group].bg_free_inodes_count++ +ext2fs_bg_free_inodes_count_set(fs, group, ext2fs_bg_free_inodes_count(fs, group)+1) | -fs->group_desc[group].bg_free_inodes_count-- +ext2fs_bg_free_inodes_count_set(fs, group, ext2fs_bg_free_inodes_count(fs, group)-1) | -fs->group_desc[group].bg_free_inodes_count += i +ext2fs_bg_free_inodes_count_set(fs, group, ext2fs_bg_free_inodes_count(fs, group)+i) | -fs->group_desc[group].bg_free_inodes_count -= i +ext2fs_bg_free_inodes_count_set(fs, group, ext2fs_bg_free_inodes_count(fs, group)-i) | // Used dirs -fs->group_desc[group].bg_used_dirs_count++ +ext2fs_bg_used_dirs_count_set(fs, group, ext2fs_bg_used_dirs_count(fs, group)+1) | -fs->group_desc[group].bg_used_dirs_count-- +ext2fs_bg_used_dirs_count_set(fs, group, ext2fs_bg_used_dirs_count(fs, group)-1) | -fs->group_desc[group].bg_used_dirs_count += i +ext2fs_bg_used_dirs_count_set(fs, group, ext2fs_bg_used_dirs_count(fs, group)+i) | -fs->group_desc[group].bg_used_dirs_count -= i +ext2fs_bg_used_dirs_count_set(fs, group, ext2fs_bg_used_dirs_count(fs, group)-i) | // Unused inode table blocks -fs->group_desc[group].bg_itable_unused++ +ext2fs_bg_itable_unused_set(fs, group, ext2fs_bg_itable_unused(fs, group)+1) | -fs->group_desc[group].bg_itable_unused-- +ext2fs_bg_itable_unused_set(fs, group, ext2fs_bg_itable_unused(fs, group)-1) | -fs->group_desc[group].bg_itable_unused += i +ext2fs_bg_itable_unused_set(fs, group, ext2fs_bg_itable_unused(fs, group)+i) | -fs->group_desc[group].bg_itable_unused -= i +ext2fs_bg_itable_unused_set(fs, group, ext2fs_bg_itable_unused(fs, group)-i) ) // Get a pointer to a whole dang descriptor @@ ext2_filsys fs; expression group; @@ -&fs->group_desc[group] +ext2fs_group_desc(fs, fs->group_desc, group) // Block group flags @@ ext2_filsys fs; expression group, flag; @@ ( -fs->group_desc[group].bg_flags & flag +ext2fs_bg_flag_test(fs, group, flag) | -fs->group_desc[group].bg_flags &= ~flag +ext2fs_bg_flag_clear(fs, group, flag) | -fs->group_desc[group].bg_flags |= flag +ext2fs_bg_flag_set(fs, group, flag) | -fs->group_desc[group].bg_flags = 0 +ext2fs_bg_flags_clear(fs, group, 0) ) // Block group bitmap/table locations @@ ext2_filsys fs; expression group, E; @@ ( -fs->group_desc[group].bg_block_bitmap = E +ext2fs_block_bitmap_loc_set(fs, group, E) | -fs->group_desc[group].bg_block_bitmap +ext2fs_block_bitmap_loc(fs, group) | -fs->group_desc[group].bg_inode_bitmap = E +ext2fs_inode_bitmap_loc_set(fs, group, E) | -fs->group_desc[group].bg_inode_bitmap +ext2fs_inode_bitmap_loc(fs, group) | -fs->group_desc[group].bg_inode_table = E +ext2fs_inode_table_loc_set(fs, group, E) | -fs->group_desc[group].bg_inode_table +ext2fs_inode_table_loc(fs, group) | -fs->group_desc[group].bg_free_blocks = E +ext2fs_bg_free_blocks_count_set(fs, group, E) | -fs->group_desc[group].bg_free_blocks_count +ext2fs_bg_free_blocks_count(fs, group) | -fs->group_desc[group].bg_free_inodes_count = E +ext2fs_bg_free_inodes_count_set(fs, group, E) | -fs->group_desc[group].bg_free_inodes_count +ext2fs_bg_free_inodes_count(fs, group) | -fs->group_desc[group].bg_used_dirs_count = E +ext2fs_bg_used_dirs_count_set(fs, group, E) | -fs->group_desc[group].bg_used_dirs_count +ext2fs_bg_used_dirs_count(fs, group) | -fs->group_desc[group].bg_itable_unused = E +ext2fs_bg_itable_unused_set(fs, group, E) | -fs->group_desc[group].bg_itable_unused +ext2fs_bg_itable_unused(fs, group) ) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-04 18:18 ` Valerie Aurora @ 2009-08-04 19:24 ` Andreas Dilger 2009-08-04 19:58 ` Valerie Aurora 2009-08-04 20:32 ` Theodore Tso 1 sibling, 1 reply; 19+ messages in thread From: Andreas Dilger @ 2009-08-04 19:24 UTC (permalink / raw) To: Valerie Aurora Cc: Theodore Tso, Julia Lawall, linux-ext4, Eric Sandeen, Ric Wheeler, Jesper Andersen Semantic patches... a very interesting idea. On Aug 04, 2009 14:18 -0400, Valerie Aurora wrote: > // Free blocks > -fs->group_desc[group].bg_free_blocks_count++ > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)+1) > | > -fs->group_desc[group].bg_free_blocks_count-- > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)-1) > | > -fs->group_desc[group].bg_free_blocks_count += i > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)+i) > | > -fs->group_desc[group].bg_free_blocks_count -= i > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)-i) I wonder if it makes more sense for ext2fs to export functions like ext2fs_bg_free_blocks_count_add() and ext2fs_bg_free_blocks_count_sub()? > -fs->group_desc[group].bg_flags & flag > +ext2fs_bg_flag_test(fs, group, flag) > | > -fs->group_desc[group].bg_flags &= ~flag > +ext2fs_bg_flag_clear(fs, group, flag) > | > -fs->group_desc[group].bg_flags |= flag > +ext2fs_bg_flag_set(fs, group, flag) > | > -fs->group_desc[group].bg_flags = 0 > +ext2fs_bg_flags_clear(fs, group, 0) This last one looks like an error. To clear the flags you should use ext2fs_bg_flags_set(fs, group, 0), otherwise you are "clearing no flags". Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-04 19:24 ` Andreas Dilger @ 2009-08-04 19:58 ` Valerie Aurora 0 siblings, 0 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-04 19:58 UTC (permalink / raw) To: Andreas Dilger Cc: Theodore Tso, Julia Lawall, linux-ext4, Eric Sandeen, Ric Wheeler, Jesper Andersen On Tue, Aug 04, 2009 at 01:24:08PM -0600, Andreas Dilger wrote: > Semantic patches... a very interesting idea. > > On Aug 04, 2009 14:18 -0400, Valerie Aurora wrote: > > // Free blocks > > -fs->group_desc[group].bg_free_blocks_count++ > > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)+1) > > | > > -fs->group_desc[group].bg_free_blocks_count-- > > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)-1) > > | > > -fs->group_desc[group].bg_free_blocks_count += i > > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)+i) > > | > > -fs->group_desc[group].bg_free_blocks_count -= i > > +ext2fs_bg_free_blocks_count_set(fs, group, ext2fs_bg_free_blocks_count(fs, group)-i) > > I wonder if it makes more sense for ext2fs to export functions like > ext2fs_bg_free_blocks_count_add() and ext2fs_bg_free_blocks_count_sub()? I am agnostic. > > -fs->group_desc[group].bg_flags = 0 > > +ext2fs_bg_flags_clear(fs, group, 0) > > This last one looks like an error. To clear the flags you should > use ext2fs_bg_flags_set(fs, group, 0), otherwise you are "clearing > no flags". The code does the right thing: void ext2fs_bg_flags_clear(ext2_filsys fs, dgrp_t group, __u16 bg_flags) { if (fs->super->s_desc_size >= EXT2_MIN_DESC_SIZE_64BIT) { struct ext4_group_desc *gdp; gdp = (struct ext4_group_desc *) (fs->group_desc) + group; gdp->bg_flags = 0; return; } fs->group_desc[group].bg_flags = 0; } The problem is that this function is stupidly named: ext2fs_bg_flag_clear() - does what you think ext2fs_bg_flags_clear() - does above ^ It should be removed and replaced by ext2fs_bg_flags_set(), I agree. -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) 2009-08-04 18:18 ` Valerie Aurora 2009-08-04 19:24 ` Andreas Dilger @ 2009-08-04 20:32 ` Theodore Tso 1 sibling, 0 replies; 19+ messages in thread From: Theodore Tso @ 2009-08-04 20:32 UTC (permalink / raw) To: Valerie Aurora Cc: Julia Lawall, linux-ext4, Eric Sandeen, Ric Wheeler, Jesper Andersen On Tue, Aug 04, 2009 at 02:18:51PM -0400, Valerie Aurora wrote: > On Tue, Aug 04, 2009 at 10:48:46AM -0400, Theodore Tso wrote: > > > > If you want to start preparing for the semantic patches by preparing > > and testing the receipes, and then helping to flag those patches that > > contain some changes that contain some changes that can't be applied > > via spatch, that would be helpful. > > > > Does that sound like a plan? > > That sounds great. We won't be able to automate everything, but after > this exercise, I bet spatch will be able to automate most of it. > > Jesper, the patches you'll be interested in can be found in the > shared-64bit branch of: > > git://git.kernel.org/pub/scm/fs/ext2/val/e2fsprogs.git This is actually *very* out of date. It's based off of e2fsprogs 1.41.4, and doesn't have the latest bug fixes or my efforts to clean up the patches. Please use either the pu branch of e2fsprogs: git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git or, the e2fsprogs 64-bit patch queue, which can be found here: http://github.com/tytso/e2fsprogs-64bit/tree/master git://github.com/tytso/e2fsprogs-64bit.git Val, I had offered you write access into this patch queue back when I first rebased the e2fsprogs patches to 1.41.4, and you declined, saying you preferred not to work that way. The offer is still open; I find that patch queue to be a **far** better way of working, especially if the goal is to refactor and clean up the patches. Simply using a git branch doesn't work at all; I provide the pu branch as a convenience, but it is constantly getting rewound as I clean up, refactor, reorder, and gradually merge patches into mainline. Currently I have merged around third of the changes into the e2fsprogs master branch, and the patches have been significantly improved. The new bitmap code has been cleaned up significantly, and is almost ready for mainline. - Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-02 2:22 ` Theodore Tso ` (2 preceding siblings ...) 2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora @ 2009-08-04 18:28 ` Valerie Aurora 2009-08-04 20:41 ` Theodore Tso 2009-08-04 23:56 ` Theodore Tso 3 siblings, 2 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-04 18:28 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > In case people are wondering why it's taking so long to merge the > 64-bit patch series, let me show one patch as exhibit 'A' about how > not to submit patches to me (or Linus, or any other upstream > maintainer): Oh, geez, those are an old patch set! I did go back and fix the temporary commits and dangly semi-colons, plus reimplemented progress meters the way you wanted: http://osdir.com/ml/linux-ext4/2009-02/msg00591.html I just forgot because I sent it back in February. :( I hope you can merge those changes without a lot of trouble. -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora @ 2009-08-04 20:41 ` Theodore Tso 2009-08-04 21:29 ` Valerie Aurora 2009-08-04 23:56 ` Theodore Tso 1 sibling, 1 reply; 19+ messages in thread From: Theodore Tso @ 2009-08-04 20:41 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Tue, Aug 04, 2009 at 02:28:11PM -0400, Valerie Aurora wrote: > On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > > In case people are wondering why it's taking so long to merge the > > 64-bit patch series, let me show one patch as exhibit 'A' about how > > not to submit patches to me (or Linus, or any other upstream > > maintainer): > > Oh, geez, those are an old patch set! I did go back and fix the > temporary commits and dangly semi-colons, plus reimplemented progress > meters the way you wanted: > > http://osdir.com/ml/linux-ext4/2009-02/msg00591.html Oh, I see what happened. It looks like you fixed some of that up in the "shared-64bit-handover" branch, but I didn't see that one, since you checked in the bug fixes and patches which Nick Dokus submitted into the "shared-64bit" branch. Hence, the shared-64bit branch had commits in it dating from May, 2009, while the shared-64bit-handover branch had commits dating from February, 2009. Hence, I started work using the shared-64bit branch instead of the shared-64bit-handover branch. This is, by the way, why I believe using a patch queue is a ****much**** better way of working, instead of using multiple git branches. I'm guessing that when Nick started submitting patches, you got confused and applied his patches onto the wrong branch, and so of course I used the latest, new version of the 64-bit branch --- which meant that I got Nick's fixes, but not your cleanups. Argh.... I wish I had figured this out much earlier, since at this point, I've done so much work using the non-cleaned-up patches, including merging around a third of the patches into e2fsprogs mainline, that it's probably not worth it to go back. - Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-04 20:41 ` Theodore Tso @ 2009-08-04 21:29 ` Valerie Aurora 2009-08-04 22:12 ` Theodore Tso 0 siblings, 1 reply; 19+ messages in thread From: Valerie Aurora @ 2009-08-04 21:29 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Tue, Aug 04, 2009 at 04:41:22PM -0400, Theodore Tso wrote: > On Tue, Aug 04, 2009 at 02:28:11PM -0400, Valerie Aurora wrote: > > On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote: > > > In case people are wondering why it's taking so long to merge the > > > 64-bit patch series, let me show one patch as exhibit 'A' about how > > > not to submit patches to me (or Linus, or any other upstream > > > maintainer): > > > > Oh, geez, those are an old patch set! I did go back and fix the > > temporary commits and dangly semi-colons, plus reimplemented progress > > meters the way you wanted: > > > > http://osdir.com/ml/linux-ext4/2009-02/msg00591.html > > Oh, I see what happened. It looks like you fixed some of that up in > the "shared-64bit-handover" branch, but I didn't see that one, since > you checked in the bug fixes and patches which Nick Dokus submitted > into the "shared-64bit" branch. Hence, the shared-64bit branch had > commits in it dating from May, 2009, while the shared-64bit-handover > branch had commits dating from February, 2009. Hence, I started work > using the shared-64bit branch instead of the shared-64bit-handover > branch. Yeah, it's pretty hard to keep track of which branch does what after several months go by. Maybe next time we can sync up first if it's been a while since the last review/pull request. -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-04 21:29 ` Valerie Aurora @ 2009-08-04 22:12 ` Theodore Tso 0 siblings, 0 replies; 19+ messages in thread From: Theodore Tso @ 2009-08-04 22:12 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Tue, Aug 04, 2009 at 05:29:37PM -0400, Valerie Aurora wrote: > > Yeah, it's pretty hard to keep track of which branch does what after > several months go by. Maybe next time we can sync up first if it's > been a while since the last review/pull request. > Well, if you are planning on doing more e2fsprogs work, why not work against a shared patch queue which is under git control? That way we don't need to do explicit sync ups. Once we have more than one person with write access into the patch queue, if someone plans to make changes that involve reorganizing or refactoring patches, they should send e-mail to take a "lock" on the patch queue. I normally work on the patch queue in concentrated bursts, usually in the evenings or on the weekends, so if you're going to "take the lock" to work on the patch queue during the day, we're not likely to collide with each other. I believe this will be a far more efficient way of working together, which won't require massive "sync up" efforts. - Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora 2009-08-04 20:41 ` Theodore Tso @ 2009-08-04 23:56 ` Theodore Tso 1 sibling, 0 replies; 19+ messages in thread From: Theodore Tso @ 2009-08-04 23:56 UTC (permalink / raw) To: Valerie Aurora; +Cc: linux-ext4, Eric Sandeen, Ric Wheeler On Tue, Aug 04, 2009 at 02:28:11PM -0400, Valerie Aurora wrote: > Oh, geez, those are an old patch set! I did go back and fix the > temporary commits and dangly semi-colons, plus reimplemented progress > meters the way you wanted: I just pulled in the reimplemented progress meter from the shared-64bits-handover patches and merged it into e2fsprogs patch queue. While I was testing it, I noticed that it was buggy; it was printing progress reports of the form: Allocating group tables: 3/ 0 This was because the printf format being used was %d/%d, but the arguments being printed were unsigned long long's. Now fixed. - Ted ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix device too big bug in mainline? 2009-08-02 0:28 ` Theodore Tso 2009-08-02 2:22 ` Theodore Tso @ 2009-08-03 18:04 ` Valerie Aurora 1 sibling, 0 replies; 19+ messages in thread From: Valerie Aurora @ 2009-08-03 18:04 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-ext4, Eric Sandeen On Sat, Aug 01, 2009 at 08:28:33PM -0400, Theodore Tso wrote: > On Thu, Jul 30, 2009 at 05:53:02PM -0400, Valerie Aurora wrote: > > Hi all, > > > > Currently, e2fsprogs will fail to create a file system if the > > underlying device is "too big" - even if we specify a number of blocks > > to use that is in range: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=485236 > > > > This is fixed in the current pu branch, but more as a side effect of > > an enormous 64-bit rewrite. > > > > Ted, any plans to pull this into mainline? > > We have a special case as of v1.41.4 so that if someone creates a 16TB > partition, we'll treat it as having 16TB - 1 minus blocks. > > Yes, I'm working on merging the 64-bit patches into mainline; and so > far we have about 25% or so of the patches merged into the master > branch. It's been somewhat slow going, since I've many other things > on my plate, and because I've wanted to do a lot of QA while doing the > merge. I've found more than a few bugs simply by doing code > inspection while merging the patches one at a time. > > How much do we care about this specific bug as something that needs to > be fixed ASAP? We already have something for a 16TB logical volume, > since that is what is most likely to be created with lvcreate. But do > we consider it a common case where someone creates a 32TB logical > volume, but intends to create a 16TB (minus 1 block) filesystem, that > needs to be urgently fixed? I've only talked to one customer who ran into this problem, and they were testing, not doing anything in production. The bug is pretty easy to workaround - just partition your device or shrink your logical volume. Obviously, there's no point in having a partition larger than 16TB without the 64-bit feature since you can't grow the file system to larger than that. On the other hand, it offends my sensibilities to have a known bug in a release. To me, it seems reasonable to wait to fix this bug until the 64-bit stuff goes in, especially since you'd have to write a fix from scratch, since you can't backport the 64-bit version. However, you are the maintainer; if you think it should be fixed sooner then I'll go ahead and write it. -VAL ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2009-08-04 23:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-07-30 21:53 Fix device too big bug in mainline? Valerie Aurora 2009-08-02 0:28 ` Theodore Tso 2009-08-02 2:22 ` Theodore Tso 2009-08-02 3:49 ` Theodore Tso 2009-08-03 20:11 ` Valerie Aurora 2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora 2009-08-03 22:56 ` Valerie Aurora 2009-08-04 6:40 ` Julia Lawall 2009-08-04 14:48 ` Theodore Tso 2009-08-04 18:18 ` Valerie Aurora 2009-08-04 19:24 ` Andreas Dilger 2009-08-04 19:58 ` Valerie Aurora 2009-08-04 20:32 ` Theodore Tso 2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora 2009-08-04 20:41 ` Theodore Tso 2009-08-04 21:29 ` Valerie Aurora 2009-08-04 22:12 ` Theodore Tso 2009-08-04 23:56 ` Theodore Tso 2009-08-03 18:04 ` Valerie Aurora
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).