From: Neil Brown <neilb@suse.de>
To: "Czarnowska, Anna" <anna.czarnowska@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"Neubauer, Wojciech" <Wojciech.Neubauer@intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
"Labun, Marcin" <Marcin.Labun@intel.com>,
"Hawrylewicz Czarnowski,
Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
Subject: Re: [Patch 00/17] Autorebuild
Date: Mon, 22 Nov 2010 13:16:44 +1100 [thread overview]
Message-ID: <20101122131644.6ba971f2@notabene.brown> (raw)
In-Reply-To: <A9DE54D0CD747C4CB06DCE5B6FA2246F010BE8FD35@irsmsx504.ger.corp.intel.com>
On Thu, 18 Nov 2010 23:14:49 +0000
"Czarnowska, Anna" <anna.czarnowska@intel.com> wrote:
> Hi Neil,
> I started testing new code today. Just the Incremental part.
>
> There are few problems:
> 1. Cookie file is cleared before it is read so spare-same-slot can't work. It should be just open for reading. (probably a typo)
Yes, just a typo. Fixed.
> 2. Container uuid instead of subarray uuid is written in cookie file, so for ddf it may not be clear which subarray used the slot.
This is deliberate. It is really up to the ddf spare-assignment handler (in
super-ddf ... though it isn't written yet) to decide which sub array gets
which part of the new disk. If an admin wants more control they need to do
it at a different level - probably having separate ddf containers in separate
domains.
> 3. Incremental fail does not work for external metadata. Przemek's original patch did fail the disk in subarrays. Now Manage_subdevs tries to fail a disk in container while subarray is expected. Do you intend to change Manage_subdevs to take a container?
Yes... I didn't notice that change in the patch. This is one of the reasons
I like each patch to just make one change.
I have added a new patch which fails all the contained arrays before removing
from the container (though I haven't tested it yet).
> 4. With spare-same-slot when there is a cookie and disk has no metadata then we probably shouldn't look at domains. Just add.
>
I disagree. We must always check domains.
Why do you think we should ignore domains in that case?
Thanks for the testing. I'll push a new devel-3.2 out later today.
NeilBrown
next prev parent reply other threads:[~2010-11-22 2:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-29 14:13 [Patch 00/17] Autorebuild Czarnowska, Anna
2010-11-17 10:22 ` Neil Brown
2010-11-17 16:04 ` Labun, Marcin
2010-11-18 23:14 ` Czarnowska, Anna
2010-11-19 12:43 ` Devel 3.2 branch issues Czarnowska, Anna
2010-11-22 3:29 ` Neil Brown
2010-11-22 17:18 ` Labun, Marcin
2010-11-22 18:47 ` Dan Williams
2010-11-23 17:34 ` Labun, Marcin
2010-11-19 15:12 ` Autorebuild, new dynamic udev rules for hot-plugs Hawrylewicz Czarnowski, Przemyslaw
2010-11-22 5:02 ` Neil Brown
2010-11-22 23:50 ` Hawrylewicz Czarnowski, Przemyslaw
2010-11-23 0:11 ` Dan Williams
2010-11-23 1:17 ` Neil Brown
2010-11-23 5:04 ` Dan Williams
2010-11-23 5:27 ` Neil Brown
2010-11-23 6:17 ` Dan Williams
2010-11-23 17:01 ` Hawrylewicz Czarnowski, Przemyslaw
2010-12-23 15:44 ` Hawrylewicz Czarnowski, Przemyslaw
2010-11-22 2:16 ` Neil Brown [this message]
2010-11-22 15:08 ` [Patch 00/17] Autorebuild Czarnowska, Anna
2010-11-23 1:34 ` Neil Brown
2010-11-23 18:20 ` Labun, Marcin
2010-12-09 11:40 ` Czarnowska, Anna
2010-12-13 0:21 ` Neil Brown
2010-12-14 14:47 ` [PATCH] fix: Monitor doesn't return after starting daemon Czarnowska, Anna
2010-12-14 21:58 ` Neil Brown
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=20101122131644.6ba971f2@notabene.brown \
--to=neilb@suse.de \
--cc=Marcin.Labun@intel.com \
--cc=Wojciech.Neubauer@intel.com \
--cc=anna.czarnowska@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ed.ciechanowski@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=przemyslaw.hawrylewicz.czarnowski@intel.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).