On 17:03, Andreas Dilger wrote:
> On Oct 30, 2006 10:55 +0100, Andre Noll wrote:
> > Note that the patch does not address the EXT3_FEATURE_INCOMPAT_META_BG
> > case yet. I'll have to look at this in more detail.
>
> See more below... Basically, the patch looks good enough to submit for
> inclus
On Oct 30, 2006 10:55 +0100, Andre Noll wrote:
> Note that the patch does not address the EXT3_FEATURE_INCOMPAT_META_BG
> case yet. I'll have to look at this in more detail.
See more below... Basically, the patch looks good enough to submit for
inclusion. Can you CC it to Andrew on the next ite
On 22:24, Andreas Dilger wrote:
> Well, it needs to also handle backup superblock, bitmaps, inode table:
>
> if (ext3_bg_has_super())
> ext3_set_bit(0, gdp_bh->b_data);
> gdblocks = ext3_bg_num_gdb(sb, group);
> for (i = 0, bit = 1; i < gdblocks; i++, bit++)
>
On Oct 27, 2006 17:34 +0200, Andre Noll wrote:
> On 12:01, Andreas Dilger wrote:
> > Well, since we know at least one bit needs fixing and results in the block
> > being written to disk then setting the bits for all of the other metadata
> > blocks in this group has no extra IO cost (only a tiny a
On 12:01, Andreas Dilger wrote:
> On Oct 26, 2006 18:02 +0200, Andre Noll wrote:
> > On 03:36, Andreas Dilger wrote:
> > > The other issue is that you need to potentially set "num" bits in the
> > > bitmap here, if those all overlap metadata. In fact, it might just
> > > make more sense at this s
On Oct 26, 2006 18:02 +0200, Andre Noll wrote:
> On 03:36, Andreas Dilger wrote:
> > The other issue is that you need to potentially set "num" bits in the
> > bitmap here, if those all overlap metadata. In fact, it might just
> > make more sense at this stage to walk all of the bits in the bitmap
On 03:36, Andreas Dilger wrote:
> On Oct 25, 2006 11:44 +0200, Andre Noll wrote:
> > Are you saying that ext3_set_bit() should simply be called with
> > "ret_block" as its first argument? If yes, that is what the revised
> > patch below does.
>
> You might need to call ext3_set_bit_atomic() (as
On Oct 25, 2006 11:44 +0200, Andre Noll wrote:
> Are you saying that ext3_set_bit() should simply be called with
> "ret_block" as its first argument? If yes, that is what the revised
> patch below does.
You might need to call ext3_set_bit_atomic() (as claim_block() does,
not sure.
> @@ -1372,12
On 14:27, Andreas Dilger wrote:
> > + j = find_next_usable_block(-1, gdp, EXT3_BLOCKS_PER_GROUP(sb));
>
> I'm not sure why the "find_next_usable_block()" part is in here? At this
> point we KNOW that ret_block is not a block we should be allocating, yet
> it is marked free in the bitma
On Oct 24, 2006 11:14 +0200, Andre Noll wrote:
> On 14:02, Andreas Dilger wrote:
> Something like the this? (only compile tested). And no, I do _not_ know,
> what I'm doing ;)
Don't worry, everyone starts out not knowing what they are doing.
The ext3_free_blocks() part looks OK from a cursory rev
On 14:02, Andreas Dilger wrote:
> I found a URL for the 2.4 version of this patch, if some kind soul would
> update it for 2.6 it might save someone's data in the future.
Something like the this? (only compile tested). And no, I do _not_ know,
what I'm doing ;)
Thanks
Andre
diff --git a/fs/ext
On Oct 23, 2006 10:44 -0600, Andreas Dilger wrote:
> Hmm, this would appear to be a buglet in error handling. If the block just
> allocated above is in the system zone it should be marked in-use in the
> bitmap but otherwise ignored. We definitely should NOT be freeing it on
> error.
>
> Yikes!
On Oct 23, 2006 16:45 +0200, Andre Noll wrote:
> stress tests on a 6.3T ext3 filesystem which runs on top of software
> raid 6 revealed the following:
>
> [663594.224641] init_special_inode: bogus i_mode (4412)
> [663596.355652] init_special_inode: bogus i_mode (5123)
> [663596.355832] init_speci
13 matches
Mail list logo
