All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sami Tolvanen <samitolvanen@google.com>
To: Will Drewry <wad@chromium.org>
Cc: Mandeep Baines <msb@chromium.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@redhat.com
Subject: Re: [PATCH] dm-verity: Add error handling modes for corrupted blocks
Date: Tue, 17 Mar 2015 10:23:34 +0000	[thread overview]
Message-ID: <20150317102334.GA35360@google.com> (raw)
In-Reply-To: <CABqD9hak_3uhczdpj70WDH9A2FfgT69zdvV8+xDH8omFEhPvSA@mail.gmail.com>

On Mon, Mar 16, 2015 at 05:13:10PM -0500, Will Drewry wrote:
> > +       if (v->corrupted_errs >= DM_VERITY_MAX_CORRUPTED_ERRS)
> > +               goto out;
> > +
> > +       ++v->corrupted_errs;
> > +
> 
> The conditional and increment should be moved below the DMERR_LIMIT().
> Otherwise, no logging will occur in non-logging modes.

This only limits the maximum number of logged errors, but until it's reached,
it does log them in all modes.

> This would be a change from how the default "eio" mode behaves today.

The only difference is that it will stop logging after reaching the maximum.

> > +       DMERR_LIMIT("%s: %s block %llu is corrupted", v->data_dev->name,
> > +               type_str, block);
> 
> Perhaps it'd make sense to consider whether to use DMERR_LIMIT or not
> depending on if the mode is logging.  Otherwise you may get weird
> interactions from having two different limits.

My intention was initially to use DMERR_LIMIT to handle error bursts, but you
are correct, it's not needed. I'll change this to DMERR in v2.

> >                         v->hash_failed = 1;
> 
> Should the dm status reflect the failure even if logging mode isn't
> returning EIOs? I think it makes sense still, but it might be good to
> note that it is intentionally kept this way.

Yes, I think it makes sense. We should be able to check the device status and
see if there have been corrupted blocks even in logging mode. I will move this
to the error handling function and add a note about it.

Sami

  parent reply	other threads:[~2015-03-17 10:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 15:55 [PATCH] dm-verity: Add error handling modes for corrupted blocks Sami Tolvanen
2015-03-16 22:13 ` Will Drewry
2015-03-17  0:45   ` Alasdair G Kergon
2015-03-17 10:35     ` Sami Tolvanen
2015-03-17 10:23   ` Sami Tolvanen [this message]
2015-03-17  0:37 ` Alasdair G Kergon
2015-03-17 10:36   ` Sami Tolvanen
2015-03-17 15:27 ` Vivek Goyal
2015-03-17 16:06   ` Sami Tolvanen
2015-03-17 18:03     ` Vivek Goyal
2015-03-18 13:24       ` Sami Tolvanen
2015-03-18 15:42         ` Mikulas Patocka
2015-03-18 15:49           ` Sami Tolvanen
2015-03-17 16:37 ` [PATCHv2] " Sami Tolvanen
2015-03-17 18:50   ` Alasdair G Kergon
2015-03-18 13:26     ` Sami Tolvanen
2015-03-18 15:52 ` [PATCHv3] " Sami Tolvanen
2015-03-19 22:18   ` Mike Snitzer

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=20150317102334.GA35360@google.com \
    --to=samitolvanen@google.com \
    --cc=dm-devel@redhat.com \
    --cc=mpatocka@redhat.com \
    --cc=msb@chromium.org \
    --cc=wad@chromium.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.