Andrew Morton wrote:
> On Wed, 13 Sep 2006 15:25:19 -0500
> Dave Kleikamp <[EMAIL PROTECTED]> wrote:
>
>>> +void journal_do_submit_data(struct buffer_head **wbuf, int bufs)
>> Is there any reason this couldn't be static?
>
> Nope.
With this change, journal_brelse_array can also be made static in
On Wed, 13 Sep 2006 15:25:19 -0500
Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> > +void journal_do_submit_data(struct buffer_head **wbuf, int bufs)
>
> Is there any reason this couldn't be static?
Nope.
> > +{
> > + int i;
> > +
> > + for (i = 0; i < bufs; i++) {
> > + w
On Fri, 2006-09-08 at 00:30 +0200, Jan Kara wrote:
> diff -rupX /home/jack/.kerndiffexclude
> linux-2.6.18-rc6/fs/jbd/commit.c
> linux-2.6.18-rc6-1-orderedwrite/fs/jbd/commit.c
> --- linux-2.6.18-rc6/fs/jbd/commit.c2006-09-06 18:20:48.0
> +0200
> +++ linux-2.6.18-rc6-1-orderedwrite/fs/j
> On Mon, 2006-09-11 at 11:46 +0200, Jan Kara wrote:
> ...
> > >
> > > I don't have any performance tests handy. We have some automated tests I
> > > can schedule to run to verify the stability aspects.
> > OK. I've run IOZONE rewrite throughput test on my computer with
> > iozone -t 10 -i 0 -s
On Mon, 2006-09-11 at 11:46 +0200, Jan Kara wrote:
...
> >
> > I don't have any performance tests handy. We have some automated tests I
> > can schedule to run to verify the stability aspects.
> OK. I've run IOZONE rewrite throughput test on my computer with
> iozone -t 10 -i 0 -s 10M -e
> 2.
Hi,
> >>>Original commit code assumes, that when a buffer on BJ_SyncData list is
> >>>locked,
> >>>it is being written to disk. But this is not true and hence it can lead
> >>>to a
> >>>potential data loss on crash. Also the code didn't count with the fact
> >>>that
> >>>journal_dirty_data()
Jan Kara wrote:
Hi,
Jan Kara wrote:
I've been looking more at the code and I have revived my patch fixing
this part of the code. I've mildly tested the patch. Could you also give
it a try? Thanks.
Honza
-
Hi,
> Jan Kara wrote:
> > I've been looking more at the code and I have revived my patch fixing
> >this part of the code. I've mildly tested the patch. Could you also give
> >it a try? Thanks.
> >
> > Honza
> >
> >---
Jan Kara 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 transaction to the running one while the buffer is in wbuf[].
Cou
>
> > 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 transaction to the running one while the buffer is in wbuf[].
>
Hi,
> > 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 transaction to the running one while the buffer is in wbuf[]
> 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 transaction to the running one while the buffer is in wbuf[].
> Could you
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
> 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 Fri, 2006-09-01 at 10:18 -0700, Andrew Morton wrote:
> On Fri, 01 Sep 2006 09:32:22 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > > > Kernel BUG at fs/buffer.c:2791
> > > > invalid opcode: [1] SMP
> > > >
> > > > Its complaining about BUG_ON(!buffer_mapped(bh)).
>
> I need to
Andrew Morton wrote:
On Fri, 01 Sep 2006 09:32:22 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
Kernel BUG at fs/buffer.c:2791
invalid opcode: [1] SMP
Its complaining about BUG_ON(!buffer_mapped(bh)).
I need to have a little think about this, remember what _should_ be
ha
On Fri, 2006-09-01 at 10:18 -0700, Andrew Morton wrote:
> On Fri, 01 Sep 2006 09:32:22 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > > > Kernel BUG at fs/buffer.c:2791
> > > > invalid opcode: [1] SMP
> > > >
> > > > Its complaining about BUG_ON(!buffer_mapped(bh)).
>
> I need to
On Fri, 01 Sep 2006 09:32:22 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> > > Kernel BUG at fs/buffer.c:2791
> > > invalid opcode: [1] SMP
> > >
> > > Its complaining about BUG_ON(!buffer_mapped(bh)).
I need to have a little think about this, remember what _should_ be
happening in th
On Fri, 2006-09-01 at 17:12 +0100, Anton Altaparmakov wrote:
> Hi,
>
> On Fri, 1 Sep 2006, Badari Pulavarty wrote:
> >
> > I have been running into following bug while running fsx
> > tests on 1k (ext3) filesystem all the time.
> >
> > --- [cut here ] - [please bite here ] -
Hi,
On Fri, 1 Sep 2006, Badari Pulavarty wrote:
>
> I have been running into following bug while running fsx
> tests on 1k (ext3) filesystem all the time.
>
> --- [cut here ] - [please bite here ] -
> Kernel BUG at fs/buffer.c:2791
> invalid opcode: [1] SMP
>
> Its
Hi Andrew,
I have been running into following bug while running fsx
tests on 1k (ext3) filesystem all the time.
--- [cut here ] - [please bite here ] -
Kernel BUG at fs/buffer.c:2791
invalid opcode: [1] SMP
Its complaining about BUG_ON(!buffer_mapped(bh)).
It was h
31 matches
Mail list logo
