All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Whitehouse <steve@chygwyn.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
	npiggin@suse.de, Andrew Morton <akpm@linux-foundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [patch 4/8] mm: write_cache_pages type overflow fix
Date: Fri, 10 Oct 2008 14:48:02 +0100	[thread overview]
Message-ID: <1223646482.25004.13.camel@quoit> (raw)
In-Reply-To: <20081010133719.GC16353@mit.edu>

Hi,

On Fri, 2008-10-10 at 09:37 -0400, Theodore Tso wrote:
> On Fri, Oct 10, 2008 at 09:13:25AM -0400, Christoph Hellwig wrote:
> > On Fri, Oct 10, 2008 at 09:10:30AM -0400, Theodore Tso wrote:
> > > > Aneesh has a patch to kill the range_cont flag, which is queued up for
> > > > 2.6.28.
> > > 
> > > Which tree is this queued up in?  It's not in ext4 or the mm tree...
> > 
> > Oh, it' not queued up yet?  It's part of the patch that switches ext4
> > to it's own copy of write_cache_pages to fix the buffer write issues.
> > 
> 
> I held off queing it up since the version Aneesh did created ext4's
> own copy of write_cache_pages, and given that Nick has a bunch of
> fixes and improvements for write_cache_pages, it confirmed my fears
> that queueing a patch which copied ~100 lines of code into ext4 was
> probably not the best way to go.
> 
I've not looked at ext4's copy of write_cache_pages, but there is also a
copy in GFS2. Its used only for journaled data, and it is pretty much a
direct copy of write_cache_pages except that its split into two so that
a transaction can be opened in the "middle".

Perhaps it would be possible to make some changes so that we can both
share the "core" version of write_cache_pages. My plan was to wait until
Nick's patches have made it to Linus, and then to look into what might
be done,

Steve.



WARNING: multiple messages have this Message-ID (diff)
From: Steven Whitehouse <steve@chygwyn.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
	npiggin@suse.de, Andrew Morton <akpm@linux-foundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [patch 4/8] mm: write_cache_pages type overflow fix
Date: Fri, 10 Oct 2008 14:48:02 +0100	[thread overview]
Message-ID: <1223646482.25004.13.camel@quoit> (raw)
In-Reply-To: <20081010133719.GC16353@mit.edu>

Hi,

On Fri, 2008-10-10 at 09:37 -0400, Theodore Tso wrote:
> On Fri, Oct 10, 2008 at 09:13:25AM -0400, Christoph Hellwig wrote:
> > On Fri, Oct 10, 2008 at 09:10:30AM -0400, Theodore Tso wrote:
> > > > Aneesh has a patch to kill the range_cont flag, which is queued up for
> > > > 2.6.28.
> > > 
> > > Which tree is this queued up in?  It's not in ext4 or the mm tree...
> > 
> > Oh, it' not queued up yet?  It's part of the patch that switches ext4
> > to it's own copy of write_cache_pages to fix the buffer write issues.
> > 
> 
> I held off queing it up since the version Aneesh did created ext4's
> own copy of write_cache_pages, and given that Nick has a bunch of
> fixes and improvements for write_cache_pages, it confirmed my fears
> that queueing a patch which copied ~100 lines of code into ext4 was
> probably not the best way to go.
> 
I've not looked at ext4's copy of write_cache_pages, but there is also a
copy in GFS2. Its used only for journaled data, and it is pretty much a
direct copy of write_cache_pages except that its split into two so that
a transaction can be opened in the "middle".

Perhaps it would be possible to make some changes so that we can both
share the "core" version of write_cache_pages. My plan was to wait until
Nick's patches have made it to Linus, and then to look into what might
be done,

Steve.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-10-10 13:50 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 15:50 [patch 0/8] write_cache_pages fixes npiggin
2008-10-09 15:50 ` npiggin
2008-10-09 15:50 ` [patch 1/8] mm: write_cache_pages cyclic fix npiggin
2008-10-09 15:50   ` npiggin
2008-10-09 15:50 ` [patch 2/8] mm: write_cache_pages AOP_WRITEPAGE_ACTIVATE fix npiggin
2008-10-09 15:50   ` npiggin
2008-10-10 16:00   ` Miklos Szeredi
2008-10-10 16:00     ` Miklos Szeredi
2008-10-10 18:29     ` Hugh Dickins
2008-10-11  4:05       ` Nick Piggin
2008-10-11  4:05         ` Nick Piggin
2008-10-09 15:50 ` [patch 3/8] mm: write_cache_pages writepage error fix npiggin
2008-10-09 15:50   ` npiggin
2008-10-09 15:50 ` [patch 4/8] mm: write_cache_pages type overflow fix npiggin
2008-10-09 15:50   ` npiggin
2008-10-09  8:23   ` Christoph Hellwig
2008-10-09  8:23     ` Christoph Hellwig
2008-10-09  8:33     ` Nick Piggin
2008-10-09  8:33       ` Nick Piggin
2008-10-10 13:10     ` Theodore Tso
2008-10-10 13:10       ` Theodore Tso
2008-10-10 13:13       ` Christoph Hellwig
2008-10-10 13:13         ` Christoph Hellwig
2008-10-10 13:37         ` Theodore Tso
2008-10-10 13:37           ` Theodore Tso
2008-10-10 13:48           ` Steven Whitehouse [this message]
2008-10-10 13:48             ` Steven Whitehouse
2008-10-10 14:05             ` Theodore Tso
2008-10-10 14:05               ` Theodore Tso
2008-10-10 14:08               ` Christoph Hellwig
2008-10-10 14:08                 ` Christoph Hellwig
2008-10-10 15:54                 ` Aneesh Kumar K.V
2008-10-10 15:54                   ` Aneesh Kumar K.V
2008-10-10 15:59                   ` Chris Mason
2008-10-10 16:10                   ` Theodore Tso
2008-10-10 16:10                     ` Theodore Tso
2008-10-10 16:34                   ` Christoph Hellwig
2008-10-10 16:34                     ` Christoph Hellwig
2008-10-10 13:56           ` Chris Mason
2008-10-09 15:50 ` [patch 5/8] mm: write_cache_pages integrity fix npiggin
2008-10-09 15:50   ` npiggin
2008-10-09 12:52   ` Chris Mason
2008-10-09 13:27     ` Nick Piggin
2008-10-09 13:27       ` Nick Piggin
2008-10-09 13:35       ` Chris Mason
2008-10-09 13:55         ` Nick Piggin
2008-10-09 13:55           ` Nick Piggin
2008-10-09 14:12           ` Chris Mason
2008-10-09 14:12             ` Chris Mason
2008-10-09 14:21             ` Nick Piggin
2008-10-09 14:21               ` Nick Piggin
2008-10-09 14:39               ` Chris Mason
2008-10-09 14:39                 ` Chris Mason
2008-10-09 14:50                 ` Nick Piggin
2008-10-09 14:50                   ` Nick Piggin
2008-10-09 15:16                   ` Chris Mason
2008-10-09 15:16                     ` Chris Mason
2008-10-10  2:40                     ` Nick Piggin
2008-10-10  2:40                       ` Nick Piggin
2008-10-09 15:50 ` [patch 6/8] mm: write_cache_pages cleanups npiggin
2008-10-09 15:50   ` npiggin
2008-10-09 14:37   ` Artem Bityutskiy
2008-10-09 14:37     ` Artem Bityutskiy
2008-10-09 15:50 ` [patch 7/8] mm: write_cache_pages optimise page cleaning npiggin
2008-10-09 15:50   ` npiggin
2008-10-09 15:50 ` [patch 8/8] mm: write_cache_pages terminate quickly npiggin
2008-10-09 15:50   ` npiggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1223646482.25004.13.camel@quoit \
    --to=steve@chygwyn.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpatocka@redhat.com \
    --cc=npiggin@suse.de \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.