Date:	Wed, 11 May 2011 21:59:06 +0300
From:	Amir Goldstein <amir73il@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: The new ext4 git tree re-org

On Tue, May 10, 2011 at 4:56 PM, Theodore Ts'o <tytso@....edu> wrote:
>
> I've uploaded an updated dev branch to the ext4 tree.  Compared to the
> previous version of dev branch, I've removed my modified version of
> Allison's "NULL pointer when make_indexed_dir returns -ENOSPC" patch,
> and I've added Amir's alloc_semp removal patches.  I'm still in the
> process of reviewing those patches; I've included them to make it easier
> for I and others to test them.
>

I have a general question regarding testing for next merge window.
What kernel do you usually use when testing the dev branch?
I started writing an xfstest to test online resize and filesystem
filling in parallel, based on test 224 (Delayed allocation at ENOSPC test).
I started running test 224 on a kernel built from ext4/master
and it seemed to run too slow. looking at the waiting tasks
it looked like it could be related to I/O less throttling.
Since ext4/master is based on 2.6.39-rc3, I figured maybe I am running
a buggy kernel, so I merged 2.6.39-rc7 to ext4/master to build a new kernel.

Am I going in the right direction at all?
I have a dedicated server for tests (X64_64 quad core), so it you would
like me to run some xfstest runs with specific configuration, or certain
patches applied, please let me know.



> For those folks who aren't regular attendees of the weekly ext4
> conference call[1], and so would have missed the announcement, we've
> made a change in how the branchs of the ext4 tree are organized.  The
> master branch of the ext4 tree is now non-rewinding, so it should be
> considered a stable place to do patch development, or as a starting
> point to start git branches.  The dev branch is backed by the ext4 patch
> queue, and is subject to being rewound, mainly when a patch gets yanked
> because testing or further review has discovered problems.  Please feel
> free to test the dev branch, but if you use it as a base for
> development, especially using git, please be aware that the dev branch
> is subject to being rewound and rebased.
>
> [1] If you want to attent the conference call, please talk to me or
> Mingming Cao.
>
> Stephen, could you change the linux-next tree so that it pulls from the
> ext4.git's "dev" branch, instead of the "next" branch?   Many thanks!!
>
> Here are some convenient URL's (use the http://.. URL for web browsing,
> and the git://... URL for git pull or git clone commands):
>
> * The ext4 tree:
>        http://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
>        git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
>
> * The ext4 patch queue (note: new URL):
>        https://github.com/tytso/ext4-patch-queue/commits/master
>        git://github.com/tytso/ext4-patch-queue.git
>
> * The e2fsprogs git tree (note in particular the maint, next, and master
>  branches):
>        http://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
>        git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
>
> The next patch series that are scheduled to land in dev are Allison's
> "punch" patches, which has made several rounds on the ext4 list.  My
> intentions are to start reviewing and integrating those patches into the
> dev tree on Wednesday.  If other people have any concerns, I'd
> appreciate any reviews or comments before then.
>
>                                                - Ted
>
> % git shortlog master..dev
> Amerigo Wang (1):
>      ext4: remove redundant #ifdef in super.c
>
> Amir Goldstein (5):
>      ext4: move ext4_add_groupblocks() to mballoc.c
>      ext4: implement ext4_add_groupblocks() by freeing blocks
>      ext4: synchronize ext4_mb_init_group() with buddy page lock
>      ext4: teach ext4_mb_init_cache() to skip uptodate buddy caches
>      ext4: remove alloc_semp
>
> Jan Kara (1):
>      jbd2: Fix forever sleeping process in do_get_write_access()
>
> Tao Ma (3):
>      ext4: use EXT4FS_DEBUG instead of EXT4_DEBUG in fsync.c
>      ext4: use s_inodes_per_block directly in __ext4_get_inode_loc
>      ext4: remove redundant check for first_not_zeroed in ext4_register_li_requ
>
> Theodore Ts'o (2):
>      jbd2: only print the debugging information for tid wraparound once
>      ext4: remove unneeded ext4_journal_get_undo_access
>
> % git shortlog origin..master
> Curt Wohlgemuth (1):
>      ext4: don't set PageUptodate in ext4_end_bio()
>
> Jan Kara (2):
>      ext4: Fix fs corruption when make_indexed_dir() fails
>      ext4: fix deadlock in ext4_symlink() in ENOSPC conditions
>
> Shaohua Li (1):
>      ext4: remove dead code in ext4_has_free_blocks()
>
> Theodore Ts'o (5):
>      ext4: check for ext[23] file system features when mounting as ext[23]
>      ext4: ignore errors when issuing discards
>      ext4: remove obsolete mount options from ext4's documentation
>      jbd2: fix fsync() tid wraparound bug
>      ext4: set extents flag when migrating file to use extents
>
> Yang Ruirui (1):
>      ext4: release page cache in ext4_mb_load_buddy error path
>
> Yongqiang Yang (3):
>      ext4: add a function merging extents right and left
>      ext4: add ext4_split_extent_at() and ext4_split_extent()
>      ext4: reimplement convert and split_unwritten
>
> --
> 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
>
--
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