[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1179529845.3768.20.camel@dyn9047017103.beaverton.ibm.com>
Date: Fri, 18 May 2007 16:10:45 -0700
From: Mingming Cao <cmm@...ibm.com>
To: Theodore Tso <tytso@....edu>
Cc: "Amit K. Arora" <aarora@...ux.vnet.ibm.com>,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/5][TAKE2] fallocate() implementation on i86, x86_64
and powerpc
On Fri, 2007-05-18 at 17:36 -0400, Theodore Tso wrote:
> On Tue, May 15, 2007 at 06:53:53PM +0530, Amit K. Arora wrote:
> > I will rebase it to 2.6.22-rc1 and repost the patches soon.
> > Thanks!
>
> I've rebased to 2.6.22-rc1 and put it in the ext4-patch-queue.
>
> Mingming had rebased your previous (take3) set to 2.6.22-rc1, but
> apparently the series file was corrupted, so it referenced an
> incorrect patch filename, and the patch series didn't apply cleanly.
> I've fixed it and confirmed that it builds and boots under UML. Will
> do more testing, but please take a look and confirm that it looks good.
>
Thanks Ted. I am not sure how the series corrupted but I am glad that
you catch that and updated with fallocate patches.:-)
We don't need the ext4-fallocate-1b-fallocate_inode_op_fix.patch as Amit
fixed the ext4_fallocate() return value type to match VFS fallocate() in
takes 4, patch 5/6. I will update the series to reflect this and run
test.
I think Kalpak's patch to remove 32000 subdirs patch can be add to the
ext4 patch queue as well. Agreed?
> Amit, we should probably get you access to repo.or.cz so you can
> update the patches yourself. My normal process is to transfer the
> patches into git using the 'guilt' tool, and then start doing test
> builds from there. After I fix up the patches and do whatever is
> necessary so they build, I copy them back into the ext4-patch-queue
> directly, and then do a git-diff to see what has changed, and make the
> changes to the patches look sane. Can you send me and/or mingming
> your ssh key, and we can give you push access to repo.or.cz?
>
I am not sure Amit can response this before he leave for vacation.(from
May 19 for 10 days).
I will checked the fallocate patches and run auto tests.
> We've missed the -rc1 merge window, so the goal should be to make sure
> that everything in the series file before the "unstable patches" is
> ready for merging.
>
I tend to agree. But there are some bug-fix type or mount option
patches that can try to target for rc2, what do you think?
# New patch to fix whitespace before applying new patches
whitespace.patch
#New patch to remove unnecessary exported symbols
ext4_remove_exported_symbles.patch
# New patch to add mount option to turn off extents
ext4_noextent_mount_opt.patch
# Now Turn on extents feature by default
ext4_extents_on_by_default.patch
#New patch to propagate inode flags
ext4-propagate_flags.patch
#New patch to add extent sanity checks
ext4-extent-sanity-checks.patch
#New patch to free blocks when failed to insert an extent
ext4-free-blocks-on-insert-extent-failure.patch
Cheers,
Mingming
-
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