[ext2resize] Re: [Ext2-devel] Re: [patch] ext2fs_allocate_group_table cleanup
Status: Inactive
Brought to you by:
adilger
From: Andreas D. <ad...@cl...> - 2006-03-17 08:12:47
|
On Mar 17, 2006 14:54 +0800, Coywolf Qi Hunt wrote: > 2006/3/17, Andreas Dilger <ad...@us...>: > > On Mar 17, 2006 10:45 +0800, Coywolf Qi Hunt wrote: > > > Cleanup the fake 'if' statement because of (a % b) <= (b - 1). > > > Conceptually, this fix classifies that with stride, BM < IT impossible. > > > It is for ext2resize bug fix. > > > > > > Signed-off-by: Coywolf Qi Hunt <qi...@fc...> > > > --- > > > > > > diff -r 8991ece34224 lib/ext2fs/alloc_tables.c > > > --- a/lib/ext2fs/alloc_tables.c Fri Mar 10 21:39:40 2006 -0500 > > > +++ b/lib/ext2fs/alloc_tables.c Fri Mar 17 10:30:33 2006 +0800 > > > @@ -51,8 +51,6 @@ errcode_t ext2fs_allocate_group_table(ex > > > start_blk = group_blk + fs->inode_blocks_per_group; > > > start_blk += ((fs->stride * group) % > > > (last_blk - start_blk)); > > > - if (start_blk > last_blk) > > > - start_blk = group_blk; > > > } else > > > start_blk = group_blk; > > > > Hi, > > could you please explain a bit more about this? My thought would be that > > you are correct in saying that this is a "fake 'if' statement", because > > we know the start_blk will always be less than last_blk in any case. > > > > I'm a bit confused about how it relates to a bug in ext2resize however. > > Currently in ext2resize the IT offset is no correct. In order to fix it, > I'd first make sure that in any case, with stride, mke2fs will never > put BM before IT in a group. While good in theory, I don't think any such guarantee can be made. There is no restriction on bitmap placement, and things like resize2fs can change the location of the bitmaps after mke2fs has been run. I think ext2resize needs to do its best with whatever it finds, and if the last group is not the same as the others then it just needs to be handled as well as possible. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. |