[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130213150841.GA17431@thunk.org>
Date: Wed, 13 Feb 2013 10:08:41 -0500
From: Theodore Ts'o <tytso@....edu>
To: Dmitry Monakhov <dmonakhov@...nvz.org>
Cc: Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
Zheng Liu <gnehzuil.liu@...il.com>
Subject: Merge window planning for ext4 and Ted's vacation
On Wed, Feb 13, 2013 at 11:26:40AM +0400, Dmitry Monakhov wrote:
> This helps us to spot several hidden issues (number is still unknown)
> so may be it is reasonable to split first patch in two parts:
> 1) disable uninitialized extents merging itself.
> 2) Print warning if split is required inside end_io(so only warning will
> be printed, but w/o data corruption)
> 3) Get rid of extent split machinery from end_io (because it is not
> longer valid situation)
>
> (1) and (2) should be accepted ASAP and will help us to spot and fix
> other hidden issues. And we fix all related issues it will be safe
> to apply (3)'rd one.
> I'll send patches soon.
That seems like reasonable approach; I'm not sure we'll be able to get
to (3) by the time the merge window opens, but getting (1) and (2) in
would be great; if the warning is getting triggered a lot, we might
need to only enable it under CONFIG_EXT4_DEBUG, though.
If you could you base the patches off of tip of the dev branch (which
I just updated), I'd really appreciate it. The last commit on the
newly updated dev branch is:
7eedefe ext4: support simple conversion of extent-mapped inodes to use i_blocks
In this updated dev branch, I've moved the extent status patches to
the unstable portion of the tree due to the bigalloc regressions. So
the plan for the merge window is that currently, the extent status
patches and the uninitialized extent merging patches are currently on
the unstable portion of the tree here:
http://repo.or.cz/w/ext4-patch-queue.git
git://repo.or.cz/ext4-patch-queue.git
That way we can do intensive testing on the rest of the ext4 tree.
Once the rest of the patches have been validated, I'll push the master
branch on the ext4 git tree to point at the fully validated set of
patches, and then we can try to push the rest of the patches that have
been moved past the stable-boundary in the ext4 patch queue back onto
the dev branch, and see if we can shake out the rest of the problems
before the merge window opens.
I will be leaving for Hawaii tomorrow, so the amount of time I will
have to do a development/debugging work will be limited. On the other
hand, it's easy to let regression tests run in the hotel room while
I'm visiting volcano craters, so please do send me updated patches,
and I'll review and test them as I have time. The joys of having the
pre-merge window crunch coincide with your vacation... :-)
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists