From: Yuri Tikhonov <yur@emcraft.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid@vger.kernel.org, linuxppc-dev@ozlabs.org, dzu@denx.de,
wd@denx.de, yanok@emcraft.com
Subject: Re[2]: [PATCH 07/11] md: rewrite handle_stripe_dirtying6 in asynchronous way
Date: Fri, 16 Jan 2009 17:24:03 +0300 [thread overview]
Message-ID: <1141743016.20090116172403@emcraft.com> (raw)
In-Reply-To: <e9c3a7c20901151421o69522f71rfe6d7d9621de47eb@mail.gmail.com>
On Friday, January 16, 2009 you wrote:
> On Thu, Jan 15, 2009 at 2:51 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>> On Mon, Dec 8, 2008 at 2:57 PM, Yuri Tikhonov <yur@emcraft.com> wrote:
>> What's the reasoning behind changing the logic here, i.e. removing
>> must_compute and such? I'd feel more comfortable seeing copy and
>> paste where possible with cleanups separated out into their own patch.
>>
> Ok, I now see why this change was made. Please make this changelog
> more descriptive than "Rewrite handle_stripe_dirtying6 function to
> work asynchronously."
Sure, how about the following:
"
md: rewrite handle_stripe_dirtying6 in asynchronous way
Processing stripe dirtying in asynchronous way requires some changes
to the handle_stripe_dirtying6() algorithm.
In the synchronous implementation of the stripe dirtying we processed
dirtying of a degraded stripe (with partially changed strip(s) located
on the failed drive(s)) inside one handle_stripe_dirtying6() call:
- we computed the missed strips from the old parities, and thus got
the fully up-to-date stripe, then
- we did reconstruction using the new data to write.
In the asynchronous case of handle_stripe_dirtying6() we don't
process anything right inside this function (since we under the lock),
but only schedule the necessary operations with flags. Thus, if
handle_stripe_dirtying6() is performed on the top of a degraded array
we should schedule the reconstruction operation when the failed strips
are marked (by previously called fetch_block6()) as to be computed
(with the R5_Wantcompute flag), and all the other strips of the stripe
are UPTODATE. The schedule_reconstruction() function will set the
STRIPE_OP_POSTXOR flag [for new parity calculation], which is then
handled in raid_run_ops() after the STRIPE_OP_COMPUTE_BLK one [which
causes computing of the data missed].
"
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
WARNING: multiple messages have this Message-ID (diff)
From: Yuri Tikhonov <yur@emcraft.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid@vger.kernel.org, linuxppc-dev@ozlabs.org, wd@denx.de,
dzu@denx.de, yanok@emcraft.com
Subject: Re[2]: [PATCH 07/11] md: rewrite handle_stripe_dirtying6 in asynchronous way
Date: Fri, 16 Jan 2009 17:24:03 +0300 [thread overview]
Message-ID: <1141743016.20090116172403@emcraft.com> (raw)
In-Reply-To: <e9c3a7c20901151421o69522f71rfe6d7d9621de47eb@mail.gmail.com>
On Friday, January 16, 2009 you wrote:
> On Thu, Jan 15, 2009 at 2:51 PM, Dan Williams <dan.j.williams@intel.com> =
wrote:
>> On Mon, Dec 8, 2008 at 2:57 PM, Yuri Tikhonov <yur@emcraft.com> wrote:
>> What's the reasoning behind changing the logic here, i.e. removing
>> must_compute and such? I'd feel more comfortable seeing copy and
>> paste where possible with cleanups separated out into their own patch.
>>
> Ok, I now see why this change was made. Please make this changelog
> more descriptive than "Rewrite handle_stripe_dirtying6 function to
> work asynchronously."
Sure, how about the following:
"
md: rewrite handle_stripe_dirtying6 in asynchronous way
Processing stripe dirtying in asynchronous way requires some changes=20
to the handle_stripe_dirtying6() algorithm.
In the synchronous implementation of the stripe dirtying we processed=20
dirtying of a degraded stripe (with partially changed strip(s) located=20
on the failed drive(s)) inside one handle_stripe_dirtying6() call:
- we computed the missed strips from the old parities, and thus got=20
the fully up-to-date stripe, then
- we did reconstruction using the new data to write.
In the asynchronous case of handle_stripe_dirtying6() we don't=20
process anything right inside this function (since we under the lock),=20
but only schedule the necessary operations with flags. Thus, if=20
handle_stripe_dirtying6() is performed on the top of a degraded array=20
we should schedule the reconstruction operation when the failed strips=20
are marked (by previously called fetch_block6()) as to be computed=20
(with the R5_Wantcompute flag), and all the other strips of the stripe=20
are UPTODATE. The schedule_reconstruction() function will set the=20
STRIPE_OP_POSTXOR flag [for new parity calculation], which is then=20
handled in raid_run_ops() after the STRIPE_OP_COMPUTE_BLK one [which=20
causes computing of the data missed].
"
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
next prev parent reply other threads:[~2009-01-16 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-08 21:57 [PATCH 07/11] md: rewrite handle_stripe_dirtying6 in asynchronous way Yuri Tikhonov
2008-12-08 21:57 ` Yuri Tikhonov
2009-01-15 21:51 ` Dan Williams
2009-01-15 21:51 ` Dan Williams
2009-01-15 21:51 ` Dan Williams
2009-01-15 22:21 ` Dan Williams
2009-01-15 22:21 ` Dan Williams
2009-01-16 1:07 ` Cheng Renquan
2009-01-16 1:07 ` Cheng Renquan
2009-01-16 14:46 ` Re[2]: " Yuri Tikhonov
2009-01-16 14:46 ` Yuri Tikhonov
2009-01-16 14:24 ` Yuri Tikhonov [this message]
2009-01-16 14:24 ` Yuri Tikhonov
2009-01-16 18:39 ` Dan Williams
2009-01-16 18:39 ` Dan Williams
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=1141743016.20090116172403@emcraft.com \
--to=yur@emcraft.com \
--cc=dan.j.williams@intel.com \
--cc=dzu@denx.de \
--cc=linux-raid@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=wd@denx.de \
--cc=yanok@emcraft.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 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.