From: Dmitry Monakhov <dmonakhov@openvz.org>
To: tytso@mit.edu
Cc: Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@redhat.com>,
ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/3] ext4: don't use quota reservation for speculative metadata blocks
Date: Mon, 12 Apr 2010 17:52:53 +0400 [thread overview]
Message-ID: <87633whj62.fsf@openvz.org> (raw)
In-Reply-To: <20100412134228.GL1849@thunk.org> (tytso@mit.edu's message of "Mon, 12 Apr 2010 09:42:28 -0400")
tytso@mit.edu writes:
> On Mon, Apr 12, 2010 at 05:33:14PM +0400, Dmitry Monakhov wrote:
>> BTW I'm too familiar with cross-devel-tree process
>> If tytso@ will get the patchset will you get an quota-related patches
>> to linux-fs tree too? Otherwise everybody have to wait for ext4-tree
>> push to linus's tree and when to linux-fs.
>
> I've already asked Jan if he would mind my carrying the quota patches
> in the ext4 tree, since I believe there's less chance of patch
> collisions with upcoming changes in the quota tree than if they were
> carried in the quota tree and we had to worry about changes to the
> ext4 tree.
Yess. i do understand that both interesting in common quota-related peace.
>
> These patches are also low-risk enough (they'll either work or they
> won't, and it's not hard to desk-check them for correctness) that we
> could push them to Linus now before the merge window, and see if he's
> willing to take them. I have some data corruption bugfixes I need to
> push to Linus anyway.... I dunno if Linus will be willing to take
> them, but that's the other approach.
>
> - Ted
Both options is too complex (as least for my tiny brain)
Is is possible to accept quota related patches in both(linux-fs and
ext4) tires at least in for-next branches. Seems that git is able to
detect equivalent patches via cherry-picking-like mechanisms.
next prev parent reply other threads:[~2010-04-12 13:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-07 21:45 [PATCH 0/3] ext4: don't use quota reservation for speculative metadata blocks Eric Sandeen
2010-04-07 21:49 ` [PATCH 1/3] quota: use flags interface for dquot alloc/free space Eric Sandeen
2010-04-12 13:22 ` Jan Kara
2010-05-20 22:29 ` tytso
2010-04-07 21:52 ` [PATCH 2/3] quota: add the option to not fail with EDQUOT in block allocation Eric Sandeen
2010-04-12 13:23 ` Jan Kara
2010-05-20 22:32 ` tytso
2010-04-07 21:55 ` [PATCH 3/3] ext4: don't use quota reservation for speculative metadata blocks Eric Sandeen
2010-04-12 13:36 ` Jan Kara
2010-05-20 23:10 ` tytso
2010-04-08 8:20 ` [PATCH 0/3] " Dmitry Monakhov
2010-04-08 15:28 ` Eric Sandeen
2010-04-11 9:37 ` Dmitry Monakhov
2010-04-12 13:15 ` Jan Kara
2010-04-12 13:22 ` Jan Kara
2010-04-12 13:40 ` Dmitry Monakhov
2010-04-12 13:33 ` Dmitry Monakhov
2010-04-12 13:37 ` Dmitry Monakhov
2010-04-12 13:42 ` tytso
2010-04-12 13:52 ` Dmitry Monakhov [this message]
2010-04-12 13:55 ` Jan Kara
2010-04-12 14:08 ` Dmitry Monakhov
2010-04-12 14:24 ` Jan Kara
2010-04-12 15:50 ` Eric Sandeen
2010-04-12 2:20 ` tytso
2010-04-12 14:03 ` Jan Kara
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=87633whj62.fsf@openvz.org \
--to=dmonakhov@openvz.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).