All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
To: Jes Sorensen <Jes.Sorensen@redhat.com>, shli@kernel.org
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/4] mdadm: bad block support for external metadata - initialization
Date: Thu, 27 Oct 2016 11:26:03 +0200	[thread overview]
Message-ID: <20161027092603.GA13413@proton.igk.intel.com> (raw)
In-Reply-To: <wrfjvawekhn0.fsf@redhat.com>

On Wed, Oct 26, 2016 at 03:57:39PM -0400, Jes Sorensen wrote:
> Shaohua Li <shli@kernel.org> writes:
> > On Wed, Oct 26, 2016 at 02:00:47PM -0400, Jes Sorensen wrote:
> >> Tomasz Majchrzak <tomasz.majchrzak@intel.com> writes:
> >> > I cannot see how badblocks program is related to this patch. It is a generic
> >> > code for bad blocks support in IMSM metadata. It introduces 64-bit value for
> >> > sector address, the same size as in kernel. All it does is syncing
> >> > kernel bad
> >> > block list with raid metadata.
> >> >
> >> > Tomek
> >> 
> >> I was waiting for this response, but you cut me off the CC list so
> >> missed it.
> >> 
> >> In this case I'll go ahead and apply these patches to mdadm.
> >
> > Thomasz,
> >
> > So your original kernel patch to support bad block for external metadata writes
> > '-blocked' to state. We agreed it's not required later and the applied kernel
> > patches don't support that interface. Don't you need change of the mdadm
> > patches?
> 
> Well I'll wait until this is resolved then :)

I have explained the process in detail in the other email. I haven't done any
change to '-blocked' action. It is still requested by mdmon as disk is in
blocked state when bad block is awaiting for confirmation. However my accepted
patch stopped reporting disk as faulty if there are unacknowledged bad blocks.
I have realized that disk should be shown as faulty only for unrecoverable
state. Unacknowledged bad block can still be handled so this state is not
adequate. My first mdadm patch set ignored this flag if all bad blocks have
been successfully acknowledged. It was not fully correct as it would not work
if bad block and unrecoverable error happen at the same time.

I have resent the patches that don't ignore faulty state after acknowledging
bad blocks.

Tomek

  reply	other threads:[~2016-10-27  9:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-20 13:03 [PATCH 1/4] mdadm: bad block support for external metadata - initialization Tomasz Majchrzak
2016-10-20 14:02 ` keld
2016-10-20 14:26   ` Tomasz Majchrzak
2016-10-26 18:00     ` Jes Sorensen
2016-10-26 19:23       ` Shaohua Li
2016-10-26 19:57         ` Jes Sorensen
2016-10-27  9:26           ` Tomasz Majchrzak [this message]
2016-11-28 13:34 [PATCH 1/4 v2] " Jes Sorensen
2016-11-28 14:07 ` [PATCH 1/4] " Tomasz Majchrzak
2016-11-28 22:45   ` Jes Sorensen

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=20161027092603.GA13413@proton.igk.intel.com \
    --to=tomasz.majchrzak@intel.com \
    --cc=Jes.Sorensen@redhat.com \
    --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.