From: Andrew Morton <akpm@linux-foundation.org>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>, Mingming Cao <cmm@us.ibm.com>,
linux-ext4@vger.kernel.org
Subject: Re: Patch collision: 64-bit quota changes and ext4 delalloc quota changs
Date: Wed, 5 Nov 2008 08:43:03 -0800 [thread overview]
Message-ID: <20081105084303.ed0c53d5.akpm@linux-foundation.org> (raw)
In-Reply-To: <E1Kxkwt-0007Np-O4@closure.thunk.org>
On Wed, 05 Nov 2008 11:09:39 -0500 "Theodore Ts'o" <tytso@mit.edu> 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.
next prev parent reply other threads:[~2008-11-05 16:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-05 16:09 Patch collision: 64-bit quota changes and ext4 delalloc quota changs Theodore Ts'o
2008-11-05 16:43 ` Andrew Morton [this message]
2008-11-05 17:40 ` Theodore Tso
2008-11-05 18:59 ` Mingming Cao
2008-11-05 19:16 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081105084303.ed0c53d5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cmm@us.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.