Hi,
Mingming has been working on some changes to support better support
quotas when ext4's delayed allocation is enabled. Unfortunately, they
conflict with Jan's 64-bit quota changes. The first two patches in
mingming's series change core quota handling code; the last one is ext4
specific.
Andrew has commented on the patches and I assume Mingming will be
addressing his comments. In the meantime, there is the question of
where the patches should live while they cook.
Mingming has dropped her patches, followed by Jan's 64-bit quota
patches, into the ext4 patch queue tree. This was for her convenience,
and also so she could modify Jan's patches so they would apply after
making the changes she needed. That makes sense, but it means that we
have the quota patches in the ext4 tree, which isn't so great,
especially if Jan wants/needs/plans to make any further changes.
Andrew has I see sucked up the Mingming's quota changes into the mm
tree. Given that 2 out of the 3 patches affect core code, that also
makes sense, although the last patch is ext4 specific, and some changes
to that patch might be needed as we make other changes to ext4. (For
example, my latest patch to reduce stack space on x86_64 systems by
fixing inappropriate use of "unsigned long" required some minor fix ups
to Mingming's last patch.
So what to do... I *think* the thing which makes the most sense is for
me to drop all of the quota related changes from the ext4 patch queue,
since in reality 95% of the changes are are all outside of the ext4
tree, and let Andrew carry the changes in -mm. Mingming, if you like we
can save the patches off to a subdirectory in the ext4 patch queue, and
make it easier for you to do your development.
Does that make sense to everyone?
- Ted
On Wed, 05 Nov 2008 11:09:39 -0500 "Theodore Ts'o" <[email protected]> wrote:
> Hi,
>
> Mingming has been working on some changes to support better support
> quotas when ext4's delayed allocation is enabled. Unfortunately, they
> conflict with Jan's 64-bit quota changes. The first two patches in
> mingming's series change core quota handling code; the last one is ext4
> specific.
>
> Andrew has commented on the patches and I assume Mingming will be
> addressing his comments. In the meantime, there is the question of
> where the patches should live while they cook.
>
> Mingming has dropped her patches, followed by Jan's 64-bit quota
> patches, into the ext4 patch queue tree. This was for her convenience,
> and also so she could modify Jan's patches so they would apply after
> making the changes she needed. That makes sense, but it means that we
> have the quota patches in the ext4 tree, which isn't so great,
> especially if Jan wants/needs/plans to make any further changes.
>
> Andrew has I see sucked up the Mingming's quota changes into the mm
> tree. Given that 2 out of the 3 patches affect core code, that also
> makes sense, although the last patch is ext4 specific, and some changes
> to that patch might be needed as we make other changes to ext4. (For
> example, my latest patch to reduce stack space on x86_64 systems by
> fixing inappropriate use of "unsigned long" required some minor fix ups
> to Mingming's last patch.
>
> So what to do... I *think* the thing which makes the most sense is for
> me to drop all of the quota related changes from the ext4 patch queue,
> since in reality 95% of the changes are are all outside of the ext4
> tree, and let Andrew carry the changes in -mm. Mingming, if you like we
> can save the patches off to a subdirectory in the ext4 patch queue, and
> make it easier for you to do your development.
>
> Does that make sense to everyone?
>
It works for me. I really need to get off my butt and get -mm into
linux-next.
I can merge ext4-quota-handling-for-delayed-allocation.patch if you
like, or you can merge it once te quota changes have gone in.
On Wed, Nov 05, 2008 at 08:43:03AM -0800, Andrew Morton wrote:
>
> It works for me. I really need to get off my butt and get -mm into
> linux-next.
>
> I can merge ext4-quota-handling-for-delayed-allocation.patch if you
> like, or you can merge it once te quota changes have gone in.
>
If you are willing to carry the
ext4-quota-handling-for-delayed-allocation.patch, that would be great.
Mingming, what I'll do is create a branch of the ext4 patch queue
(since it's being maintained in git anyway), that basically reflects
the patch queue as it currently exists today. You can do your
development in that branch so it won't impact you terribly, but I'll
then set master branch of the ext4 patch queue to be a version that
drops all of the quota related changes. You should be able to
periodically pull from the master branch to the quota branch, so you
can keep up with other changes, but then what we'll need to do is to
make sure that the version of the patches that you are developing
against in your branch corresponds with what Andrew has in mmotm, and
if it doesn't, we'll have to manually send updates to Andrew to keep
his tree in sync with yours, since it is his tree that will ultimately
be pushing the patches to Linus.
If it weren't for the fact that Jan is on vacation until November
18th, what I would have suggested instead was for Jan to create his
own quota git tree, drop the ext4 delalloc quota patches into a
separate git tree, called the quota-ext4-postmerge tree, and then tell
Steve to pull into next first the ext4 tree, then the quota tree, and
then the quota-ext4-postmerge tree. (And then we could easily do
testing/development by creating a throw-away integration tree that
merged the ext4, quota, and post-merge trees.)
But keeping this stuff all in -mm should work, although depending on
how many more cleanup patches flow into ext4, this might cause some
minor patch conflicts on that last quota dellaloc patch that actually
touches ext4 core code.
- Ted
On Wed, 2008-11-05 at 12:40 -0500, Theodore Tso wrote:
> On Wed, Nov 05, 2008 at 08:43:03AM -0800, Andrew Morton wrote:
> >
> > It works for me. I really need to get off my butt and get -mm into
> > linux-next.
> >
> > I can merge ext4-quota-handling-for-delayed-allocation.patch if you
> > like, or you can merge it once te quota changes have gone in.
> >
>
> If you are willing to carry the
> ext4-quota-handling-for-delayed-allocation.patch, that would be great.
>
I saw Andrew already picked up the ext4 quota changes. I will address
Andrew's comments soon. I assume I will working on incremental fixes to
address the comments? Or should I send new version of the series?
> Mingming, what I'll do is create a branch of the ext4 patch queue
> (since it's being maintained in git anyway), that basically reflects
> the patch queue as it currently exists today. You can do your
> development in that branch so it won't impact you terribly, but I'll
> then set master branch of the ext4 patch queue to be a version that
> drops all of the quota related changes.
Sure, that works for me.
> But keeping this stuff all in -mm should work, although depending on
> how many more cleanup patches flow into ext4, this might cause some
> minor patch conflicts on that last quota dellaloc patch that actually
> touches ext4 core code.
>
Since Andrew already picked up the ext4 quota changes, I will work
against mm tree then.
Mingming
On Wed, 05 Nov 2008 10:59:38 -0800
Mingming Cao <[email protected]> wrote:
> > If you are willing to carry the
> > ext4-quota-handling-for-delayed-allocation.patch, that would be great.
> >
>
> I saw Andrew already picked up the ext4 quota changes. I will address
> Andrew's comments soon. I assume I will working on incremental fixes to
> address the comments? Or should I send new version of the series?
A new series would probably be easier for reviewers. I'd turn them
into incrementals here so I can eyeball what changed, but that's pretty
quick.