Re: [PATCH 1/5][TAKE2] fallocate() implementation on i86, x86_64 and powerpc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux