On Fri, 14 Dec 2007 10:01:06 -0700
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> Well, I can imagine in some cases that the flexbg will not be completely
> contiguous on disk (e.g. after a filesystem resize, if there are bad
> blocks, etc). As long as the group descriptors themselves are correct
> (
On Dec 13, 2007 20:36 -0600, Jose R. Santos wrote:
> ... if the value in the super block is corrupted and
> does not represent the actual flexbg size, the inode allocation will
> behave in weird unexpected ways. Just as we check that the bitmaps are
> within the block group range (when not using
On Thu, 13 Dec 2007 15:58:57 -0700
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> On Dec 13, 2007 09:51 -0600, Jose R. Santos wrote:
> > Now, storing the bits only guaranties that the flexbg size is always a
> > power-of-two and does not guarantee that the super block flexbg size
> > represents the
On Dec 13, 2007 09:51 -0600, Jose R. Santos wrote:
> Now, storing the bits only guaranties that the flexbg size is always a
> power-of-two and does not guarantee that the super block flexbg size
> represents the actual meta-data grouping on disk. For this we need to
> verify that the bitmap offse
On Tue, 11 Dec 2007 16:15:28 -0700
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> On Dec 11, 2007 10:08 -0600, Jose R. Santos wrote:
> > > I'd think being able to avoid the divide for every inode allocation is
> > > more
> > > important than 8 bits in the superblock.
> >
> > We already avoid the d
On Dec 11, 2007 10:08 -0600, Jose R. Santos wrote:
> > I'd think being able to avoid the divide for every inode allocation is more
> > important than 8 bits in the superblock.
>
> We already avoid the divide since what we store in the sbi IS the bits
> which are calculated at mount time for each
On Tue, 11 Dec 2007 04:00:33 -0700
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> On Dec 07, 2007 09:52 -0600, Jose R. Santos wrote:
> > Andreas Dilger <[EMAIL PROTECTED]> wrote:
> > > There is no particular reason that this ratio needs to be "*100", it could
> > > just as easily be a fraction of 25
On Dec 07, 2007 09:52 -0600, Jose R. Santos wrote:
> Andreas Dilger <[EMAIL PROTECTED]> wrote:
> > There is no particular reason that this ratio needs to be "*100", it could
> > just as easily be a fraction of 256 and make the multiply into a shift.
> > The free_block_ratio would be 26 in that cas
On Fri, 7 Dec 2007 03:14:28 -0700
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> On Dec 06, 2007 16:10 -0600, Jose R. Santos wrote:
> > @@ -600,6 +600,7 @@ void ext4_free_blocks_sb(handle_t *handle, struct
> > super_block *sb,
> > struct ext4_sb_info *sbi;
> > int err = 0, ret;
> > ext4
On Dec 06, 2007 16:10 -0600, Jose R. Santos wrote:
> @@ -600,6 +600,7 @@ void ext4_free_blocks_sb(handle_t *handle, struct
> super_block *sb,
> struct ext4_sb_info *sbi;
> int err = 0, ret;
> ext4_grpblk_t group_freed;
> + ext4_group_t flex_group;
>
> *pdquot_freed_b
Hi folks,
New version of the Flex_BG ialloc allocation patch.
Changes from the last version:
- Size of the FLEX_BG in now written to the super block at mke2fs time
instead of calculating at mount time (testing patch for e2fsprog's
next branch attached).
- Rename a lots of the confusing "met
11 matches
Mail list logo
