From: Allison Henderson <achender@linux.vnet.ibm.com>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
Lukas Czerner <lczerner@redhat.com>, "Ted Ts'o" <tytso@mit.edu>,
Mingming Cao <cmm@linux.vnet.ibm.com>
Subject: Re: delayed extent tree test cases
Date: Thu, 08 Mar 2012 23:39:21 -0700 [thread overview]
Message-ID: <4F59A599.4050400@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAGBYx2Y8mJJ05=XcTYUVK07deS2GFUCrTVJoZy9Jaj7958OsEA@mail.gmail.com>
On 03/08/2012 10:36 PM, Yongqiang Yang wrote:
> On Fri, Mar 9, 2012 at 1:18 PM, Allison Henderson
> <achender@linux.vnet.ibm.com> wrote:
>> Hi Yongqiang,
> Hi Allison,
>
>
>>
>> I am looking for test cases to exercise your delayed extent tree patch set.
>> I am working on expanding your solution for extent locks, and it would be
>> nice to have some sanity checks as I go along to make sure I have not broken
>> it :) Are there any tests in particular that you used while you were
>> developing it? Thx!
>
> There is no particular tests for delayed extents tree on my hand.
> I just tested the patch set with xfstests. If there is any help I
> can provide, please tell me.
>
> Yongqiang.
>
>>
>> Allison Henderson
>>
>
>
>
Alrighty, I'll give it a run through xfstests tonight, and then maybe I
can show you what I've got so far. My first few patches are pretty much
just renaming things from delayed_extent to status_extent, sense it's
doing a lot more than delayed extents now. I figured those patches we
could just merge together sense I dont think your set has been merged yet.
The next step that I am working on now is getting it to track allocated
extents. So any pointers for doing that would be helpful :) It looks
like the current code is optimized for merging extents as much as
possible, and that makes sense for delayed extents, but for allocated
extents, we need to get it to mirror the existing extents. That way we
will know what extents there are to lock before we start doing things
with the current extent tree.
When I think about all the ins and outs of trying to keep the trees in
sync, I realize it may get complex, but I dont think we would want to
deal with the odd things that might come out of allowing tasks to lock a
partial extent either. Suggestions for simplifications are certainly
welcome though :)
Thx!
Allison Henderson
next prev parent reply other threads:[~2012-03-09 6:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 5:18 delayed extent tree test cases Allison Henderson
2012-03-09 5:36 ` Yongqiang Yang
2012-03-09 6:39 ` Allison Henderson [this message]
2012-03-09 9:19 ` Yongqiang Yang
2012-03-09 16:40 ` Allison Henderson
2012-03-11 14:12 ` Yongqiang Yang
2012-03-13 0:04 ` Allison Henderson
2012-03-13 3:39 ` Yongqiang Yang
2012-03-14 6:34 ` Allison Henderson
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=4F59A599.4050400@linux.vnet.ibm.com \
--to=achender@linux.vnet.ibm.com \
--cc=cmm@linux.vnet.ibm.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xiaoqiangnk@gmail.com \
/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).