From: NeilBrown <neilb@suse.de>
To: Shaohua Li <shli@kernel.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: [RFC 1/2]raid1: only write mismatch sectors in sync
Date: Thu, 18 Oct 2012 12:29:59 +1100 [thread overview]
Message-ID: <20121018122959.10bb6c87@notabene.brown> (raw)
In-Reply-To: <20121018011735.GA1448@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]
On Thu, 18 Oct 2012 09:17:35 +0800 Shaohua Li <shli@kernel.org> wrote:
> > > Neil,
> > > any further comments on this? This is a usable feature, I hope we can have some
> > > agreements.
> >
> > You still haven't answered my main question, which possibly means I haven't
> > asked it very clearly.
> >
> > You are saying that this new behaviour should not be the default and I think
> > I agree.
> > So the question is: how it is selected?
> >
> > You cannot expect the user to explicitly enable it any time a resync or
> > recovery starts that should use this new feature. You must have some
> > automatic, or semi-automatic, way for the feature to be activated, otherwise
> > it will never be used.
> >
> > I'm not asking "when should the feature be used" - you've answered that
> > question a few time and it really isn't an issue.
> > The question it "What it the exact process by which the feature is turned on
> > for any particular resync or recovery?"
>
> So you worried about users don't know how to correctly select the feature. An
> experienced user knows this, the usage scenario I mentioned describes how to do
> the decision. For example, a resync after system crash should enable the
> feature. I admit an inexperienced user doesn't know how to select it, but this
> isn't a big problem to me. There are a lot of tunables in the kernel (even MD),
> which can significantly impact kernel behavior. These tunables are just for
> experienced users.
>
> Thanks,
> Shaohua
You still aren't answering my question.
What exactly, precisely, specifically, will an "experienced user" do?
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-10-18 1:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 8:01 [RFC 1/2]raid1: only write mismatch sectors in sync Shaohua Li
2012-07-27 16:01 ` Jan Ceuleers
2012-07-30 0:39 ` Shaohua Li
2012-07-30 1:07 ` Roberto Spadim
2012-07-31 5:53 ` NeilBrown
2012-07-31 8:12 ` Shaohua Li
2012-09-11 0:59 ` NeilBrown
2012-09-12 5:29 ` Shaohua Li
2012-09-18 4:57 ` NeilBrown
2012-09-19 5:51 ` Shaohua Li
2012-09-19 7:16 ` NeilBrown
2012-09-20 1:56 ` Shaohua Li
2012-10-17 5:11 ` Shaohua Li
2012-10-17 22:56 ` NeilBrown
2012-10-18 1:17 ` Shaohua Li
2012-10-18 1:29 ` NeilBrown [this message]
2012-10-18 2:01 ` Shaohua Li
2012-10-18 2:36 ` NeilBrown
2012-10-21 17:14 ` Michael Tokarev
2012-10-31 3:25 ` Shaohua Li
2012-10-31 5:43 ` NeilBrown
2012-10-31 6:05 ` Shaohua Li
2012-10-18 1:30 ` kedacomkernel
2012-11-20 17:00 ` Joseph Glanville
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=20121018122959.10bb6c87@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=shli@kernel.org \
/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.