mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Theodore Tso <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	npiggin@suse.de, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/11] Fix page_mkwrite() for blocksize < pagesize
Date: Wed, 27 May 2009 16:59:11 +0200	[thread overview]
Message-ID: <20090527145911.GH16006@duck.suse.cz> (raw)
In-Reply-To: <20090527142332.GB10842@mit.edu>

On Wed 27-05-09 10:23:32, Theodore Tso wrote:
> On Wed, May 27, 2009 at 03:00:57PM +0200, Jan Kara wrote:
> > 
> > The series is against 2.6.30-rc7. The first two patches are just
> > small cleanup and should be merged separately (Ted should have the
> > ext4 cleanup rebased on top of current ext4 tree). 
> 
> So I can take the cleanup (which will be different given the changes
> that are ready to get merged once the merge window opens), but it
  I sent you yesterday the version of the cleanup which should apply to the
latest patch queue. I think you can merge it right away.
 In fact, this series should not depend on the cleanup in ext4 at all, I've
just included it for completeness along with ext3 cleanup of the same
problem (and the patch series depends on ext3 cleanup).

> looks like the the second ext4 patch can't go in until we get
> agreement that changes to the VFS layer should go in, correct?  So
> we'll have a merge order dependency here.
  Yes, we have to agree on VFS changes before ext4 changes make sense.

> (And this one will be the 2nd merge order dependency we have in the
> ext4 tree, since I also have some patches in the unstable portion of
> the tree which are waiting for some tracing patches to go in.)
> 
> OK, what I'll probably do is to merge the core VFS patch plus the 2nd
> ext4 patch into the ext4 patch queue in the unstable portion of the
> queue for testing purposes, but I won't actually push the VFS core
> changes.  We can figure out later who actually pushes the ext4 patch
> which utilizes the new VFS infrastructure.
  Yes, that would be fine. Thanks. Luckily, the dependence is just one way
(ext4 change has to go after the VFS patch) so it's just enough to merge
that ext4 change some time after VFS changes go in.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2009-05-27 14:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27 13:00 Jan Kara
2009-05-27 13:00 ` [PATCH 01/11] ext3: Get rid of extenddisksize parameter of ext3_get_blocks_handle() Jan Kara
2009-05-27 13:00 ` [PATCH 02/11] ext4: Get rid of extend_disksize parameter of ext4_get_blocks_handle() Jan Kara
2009-05-27 13:01 ` [PATCH 03/11] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize Jan Kara
2009-05-27 16:00   ` Josef Bacik
2009-05-27 16:45     ` Aneesh Kumar K.V
2009-05-27 17:06       ` Josef Bacik
2009-05-28 13:03   ` Josef Bacik
2009-05-28 13:10     ` Aneesh Kumar K.V
2009-05-30 11:23   ` Pavel Machek
2009-06-01  9:44     ` Jan Kara
2009-06-01 11:33       ` Goswin von Brederlow
2009-06-01 14:00         ` Jan Kara
2009-06-01 14:46           ` Goswin von Brederlow
2009-06-01 15:02             ` Jan Kara
2009-06-01 15:35               ` Goswin von Brederlow
2009-05-27 13:01 ` [PATCH 04/11] ext2: Allocate space for mmaped file on page fault Jan Kara
2009-05-27 13:01 ` [PATCH 05/11] ext4: Make sure blocks are properly allocated under mmaped page even when blocksize < pagesize Jan Kara
2009-05-27 14:30   ` Theodore Tso
2009-05-27 14:52     ` Jan Kara
2009-06-04 14:09   ` Theodore Tso
2009-05-27 13:01 ` [PATCH 06/11] ext3: Allocate space for mmaped file on page fault Jan Kara
2009-05-27 13:01 ` [PATCH 07/11] vfs: Implement generic per-cpu counters for delayed allocation Jan Kara
2009-05-27 13:01 ` [PATCH 08/11] vfs: Unmap underlying metadata of new data buffers only when buffer is mapped Jan Kara
2009-05-27 15:35   ` Aneesh Kumar K.V
2009-05-28  9:44     ` Jan Kara
2009-05-28 10:15       ` Aneesh Kumar K.V
2009-05-28 13:50         ` Jan Kara
2009-05-27 13:01 ` [PATCH 09/11] fs: Don't clear dirty bits in block_write_full_page() Jan Kara
2009-05-27 13:01 ` [PATCH 10/11] vfs: Export wakeup_pdflush Jan Kara
2009-05-27 13:01 ` [PATCH 11/11] ext3: Implement delayed allocation on page_mkwrite time Jan Kara
2009-05-27 14:23 ` [PATCH 0/11] Fix page_mkwrite() for blocksize < pagesize Theodore Tso
2009-05-27 14:59   ` Jan Kara [this message]
2009-06-04 17:11     ` Theodore Tso
2009-06-05 23:23       ` Jan Kara
2009-05-27 15:33 ` Aneesh Kumar K.V
2009-05-28  9:36   ` Jan Kara

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=20090527145911.GH16006@duck.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®