On Wed, 06 Sep 2006 20:04:27 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> > I've been unable to reproduce this crash, btw. Is there some magic
> > incantation apat from running `fsx-linux'?
> >
> All I do is on a single 1k filesystem, run 4 copies of fsx (on 4
> different files, ofcour
Andrew Morton wrote:
On Wed, 6 Sep 2006 19:27:33 +0200
Jan Kara <[EMAIL PROTECTED]> wrote:
Ugh! Are you sure? For this path the buffer must be attached (only) to
the running transaction. But then how the commit code comes to it?
Somebody would have to even manage to refile the buffer from
On Wed, 6 Sep 2006 19:27:33 +0200
Jan Kara <[EMAIL PROTECTED]> wrote:
> Ugh! Are you sure? For this path the buffer must be attached (only) to
> the running transaction. But then how the commit code comes to it?
> Somebody would have to even manage to refile the buffer from the
> committing tran
Disclaimer: I didn't take notes during the call and every time I get
back to these minutes, I get interrupted by something else, so forgive
me if I leave anything important out.
- Mingming is working on rebasing the ext4 patches on the -mm tree,
which should closely resemble the ext3 code that wi
On Wed, 2006-09-06 at 10:39 -0700, Badari Pulavarty wrote:
> Index: linux-2.6.18-rc5/fs/ext3/inode.c
> ===
> --- linux-2.6.18-rc5.orig/fs/ext3/inode.c 2006-08-27 20:41:48.0
> -0700
> +++ linux-2.6.18-rc5/fs/ext3/inode.c
Hi Andrew,
Its been reported that ext3_getblk() is not doing the right thing
and triggering following WARN():
BUG: warning at fs/ext3/inode.c:1016/ext3_getblk()
ext3_getblk+0x98/0x2a6 md_wakeup_thread
+0x26/0x2a
ext3_bread+0x1f/0x88 ext3_quota_read+0x136/0x1ae
v1_read_dqblk+0x61/0xac
> On Wed, 2006-09-06 at 18:27 +0200, Jan Kara wrote:
> > > But my debug clearly shows that we are clearing the buffer, while
> > > we haven't actually submitted to ll_rw_block() code. (I added "track"
> > > flag to bh and set it in journal_commit_transaction() when we add
> > > them to wbuf[] and c
On Wed, 2006-09-06 at 18:27 +0200, Jan Kara wrote:
> > On Wed, 2006-09-06 at 17:34 +0200, Jan Kara wrote:
> > > > On Wed, 2006-09-06 at 14:47 +0200, Jan Kara wrote:
> > > >
> > > > > > Andrew, what should we do ? Do you suggest handling this in jbd
> > > > > > itself (like this patch) ?
> > > > >
> On Wed, 2006-09-06 at 18:27 +0200, Jan Kara wrote:
> > >
> > > But my debug clearly shows that we are clearing the buffer, while
> > > we haven't actually submitted to ll_rw_block() code. (I added "track"
> > > flag to bh and set it in journal_commit_transaction() when we add
> > > them to wbuf[
On Wed, 2006-09-06 at 18:27 +0200, Jan Kara wrote:
> > On Wed, 2006-09-06 at 17:34 +0200, Jan Kara wrote:
> > > > On Wed, 2006-09-06 at 14:47 +0200, Jan Kara wrote:
> > > >
> > > > > > Andrew, what should we do ? Do you suggest handling this in jbd
> > > > > > itself (like this patch) ?
> > > > >
> On Wed, 2006-09-06 at 17:34 +0200, Jan Kara wrote:
> > > On Wed, 2006-09-06 at 14:47 +0200, Jan Kara wrote:
> > >
> > > > > Andrew, what should we do ? Do you suggest handling this in jbd
> > > > > itself (like this patch) ?
> > > > Actually that part of commit code needs rewrite anyway (and a
On Wed, 2006-09-06 at 17:34 +0200, Jan Kara wrote:
> > On Wed, 2006-09-06 at 14:47 +0200, Jan Kara wrote:
> >
> > > > Andrew, what should we do ? Do you suggest handling this in jbd
> > > > itself (like this patch) ?
> > > Actually that part of commit code needs rewrite anyway (and after that
>
> On Wed, 2006-09-06 at 14:47 +0200, Jan Kara wrote:
>
> > > Andrew, what should we do ? Do you suggest handling this in jbd
> > > itself (like this patch) ?
> > Actually that part of commit code needs rewrite anyway (and after that
> > rewrite you get rid of ll_rw_block()) because of other prob
On Wed, 2006-09-06 at 14:47 +0200, Jan Kara wrote:
> Hi,
>
> > On Fri, 2006-09-01 at 10:18 -0700, Andrew Morton wrote:
> > > > > > Kernel BUG at fs/buffer.c:2791
> > > > > > invalid opcode: [1] SMP
> > > > > >
> > > > > > Its complaining about BUG_ON(!buffer_mapped(bh)).
> >
> > Here is t
Hi,
> On Fri, 2006-09-01 at 10:18 -0700, Andrew Morton wrote:
> > > > > Kernel BUG at fs/buffer.c:2791
> > > > > invalid opcode: [1] SMP
> > > > >
> > > > > Its complaining about BUG_ON(!buffer_mapped(bh)).
>
> Here is the change that seems to cause the problem. Jana Kara
> introduced a n
On Sep 04, 2006 16:59 +0200, Alexandre Ratchov wrote:
> in order tu use 48bit adressing, we have to use larger block groups (because
> all group descriptors must fit in one block group). So we'll need 16bit
> "_hi" bits for blocks_count, inodes_count and perhaps used_dirs_count. And
> this leaves
16 matches
Mail list logo
