public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] jbd2: We shouldnot cap writeback when we are doing a journal commit
@ 2008-06-27 18:07 Aneesh Kumar K.V
  2008-06-27 18:11 ` Eric Sandeen
  0 siblings, 1 reply; 4+ messages in thread
From: Aneesh Kumar K.V @ 2008-06-27 18:07 UTC (permalink / raw)
  To: cmm, tytso, sandeen, jack; +Cc: linux-ext4, Aneesh Kumar K.V

A journal commit need to make sure we submit data buffers before
we submit the meta-data buffers in ordered mode. We should
not be looking at BDI_CAP_NO_WRITEBACK when doing a journal commit.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
 fs/jbd2/commit.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index 32ca3c3..f8b3be8 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -203,9 +203,6 @@ static int journal_submit_inode_data_buffers(struct address_space *mapping)
 		.for_writepages = 1,
 	};
 
-	if (!mapping_cap_writeback_dirty(mapping))
-		return 0;

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] jbd2: We shouldnot cap writeback when we are doing a journal commit
  2008-06-27 18:07 [PATCH] jbd2: We shouldnot cap writeback when we are doing a journal commit Aneesh Kumar K.V
@ 2008-06-27 18:11 ` Eric Sandeen
  2008-06-27 21:04   ` Jan Kara
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Sandeen @ 2008-06-27 18:11 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: cmm, tytso, jack, linux-ext4

Aneesh Kumar K.V wrote:
> A journal commit need to make sure we submit data buffers before
> we submit the meta-data buffers in ordered mode. We should
> not be looking at BDI_CAP_NO_WRITEBACK when doing a journal commit.
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

and I don't think we'll ever even see that flag set...

Acked-by: Eric Sandeen <sandeen@redhat.com>

> ---
>  fs/jbd2/commit.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> index 32ca3c3..f8b3be8 100644
> --- a/fs/jbd2/commit.c
> +++ b/fs/jbd2/commit.c
> @@ -203,9 +203,6 @@ static int journal_submit_inode_data_buffers(struct address_space *mapping)
>  		.for_writepages = 1,
>  	};
>  
> -	if (!mapping_cap_writeback_dirty(mapping))
> -		return 0;
> -
>  	ret = generic_writepages(mapping, &wbc);
>  	return ret;
>  }


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] jbd2: We shouldnot cap writeback when we are doing a journal commit
  2008-06-27 18:11 ` Eric Sandeen
@ 2008-06-27 21:04   ` Jan Kara
  2008-06-27 23:52     ` Mingming Cao
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2008-06-27 21:04 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: Aneesh Kumar K.V, cmm, tytso, jack, linux-ext4

On Fri 27-06-08 13:11:25, Eric Sandeen wrote:
> Aneesh Kumar K.V wrote:
> > A journal commit need to make sure we submit data buffers before
> > we submit the meta-data buffers in ordered mode. We should
> > not be looking at BDI_CAP_NO_WRITEBACK when doing a journal commit.
> > 
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> 
> and I don't think we'll ever even see that flag set...
> 
> Acked-by: Eric Sandeen <sandeen@redhat.com>
  Yes, I also don't think it really matters :). So feel free to remove that
check.

								Honza
> 
> > ---
> >  fs/jbd2/commit.c |    3 ---
> >  1 files changed, 0 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> > index 32ca3c3..f8b3be8 100644
> > --- a/fs/jbd2/commit.c
> > +++ b/fs/jbd2/commit.c
> > @@ -203,9 +203,6 @@ static int journal_submit_inode_data_buffers(struct address_space *mapping)
> >  		.for_writepages = 1,
> >  	};
> >  
> > -	if (!mapping_cap_writeback_dirty(mapping))
> > -		return 0;
> > -
> >  	ret = generic_writepages(mapping, &wbc);
> >  	return ret;
> >  }
> 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] jbd2: We shouldnot cap writeback when we are doing a journal commit
  2008-06-27 21:04   ` Jan Kara
@ 2008-06-27 23:52     ` Mingming Cao
  0 siblings, 0 replies; 4+ messages in thread
From: Mingming Cao @ 2008-06-27 23:52 UTC (permalink / raw)
  To: Jan Kara; +Cc: Eric Sandeen, Aneesh Kumar K.V, tytso, linux-ext4

I fold this change to the parent patch: delalloc-new-ordered-mode.patch
in patch queue

Mingming
On Fri, 2008-06-27 at 23:04 +0200, Jan Kara wrote:
> On Fri 27-06-08 13:11:25, Eric Sandeen wrote:
> > Aneesh Kumar K.V wrote:
> > > A journal commit need to make sure we submit data buffers before
> > > we submit the meta-data buffers in ordered mode. We should
> > > not be looking at BDI_CAP_NO_WRITEBACK when doing a journal commit.
> > > 
> > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > 
> > and I don't think we'll ever even see that flag set...
> > 
> > Acked-by: Eric Sandeen <sandeen@redhat.com>
>   Yes, I also don't think it really matters :). So feel free to remove that
> check.
> 
> 								Honza
> > 
> > > ---
> > >  fs/jbd2/commit.c |    3 ---
> > >  1 files changed, 0 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> > > index 32ca3c3..f8b3be8 100644
> > > --- a/fs/jbd2/commit.c
> > > +++ b/fs/jbd2/commit.c
> > > @@ -203,9 +203,6 @@ static int journal_submit_inode_data_buffers(struct address_space *mapping)
> > >  		.for_writepages = 1,
> > >  	};
> > >  
> > > -	if (!mapping_cap_writeback_dirty(mapping))
> > > -		return 0;
> > > -
> > >  	ret = generic_writepages(mapping, &wbc);
> > >  	return ret;
> > >  }
> > 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-06-27 23:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-27 18:07 [PATCH] jbd2: We shouldnot cap writeback when we are doing a journal commit Aneesh Kumar K.V
2008-06-27 18:11 ` Eric Sandeen
2008-06-27 21:04   ` Jan Kara
2008-06-27 23:52     ` Mingming Cao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox